For smaller companies they can get Claude team plan for $20/month/seat and the plans give a lot of usage. We rarely hit limits. Codex plans used to have more usage and those were the go-to. Before that, GitHub Copilot CLI was the service with insane usage limits for $10-$20/month.
So it's about staying nimble enough so you can easily switch over. Don't tie yourself down to a single product/harness.
The Claude Team plan is subsidized, and pricing for them is significantly less than what enterprises pay with API pricing. For example, your $20/month plan would cost the equivalent of $400/month if they charged you using API pricing.
That's why those plans are only available to small companies with 150 employees or less.
> That's why those plans are only available to small companies with 150 employees or less.
As far as I can tell, that's not the limit. A team plan may not have more than 150 members but the size of the company doesn't matter. I you have 150 people who need to use it inside an organization of 200, 500, 5,000, whatever, that's fine.
> they heavily use custom headers, hidden flags, and undocumented API features that affect models' behavior;
This is exactly why you'd want to use Pi. All these flags and updates to claude code break so many workflows and give a different experience every time you use it. It's highly inconsistent and very annoying.
Comments like this show that Claude devs are so disconnected from how Claude or harnesses in general are used in the real world.
Claude Code doesn't even have a basic 'enqueue' prompt feature. Even though Copilot CLI, Codex and many other harnesses have had this for a long time now. And the GitHub feature request for this was closed, by you, referencing a completely unrelated feature.
Incredible that we’re now at the point of needing to say “without all the negative connotations” when comparing against any sort Google product. LOL. I see this often.
Note, 6 of the last 10 had "fix" in the commit message. Most of the rest were patches to fix incorrect behavior/exploits, but without "fix" in the name. Fixing things is not the result of AI, it's the result of software development. Sometimes people hide this fact by either refraining from committing, or merging all those fix commits into one commit.
It's been well known for the last 5-10 years that Samsung has degraded into one of the worst consumer device manufacturers, whether it's all this tracking, or forcing you to watch ads on the home screen of your expensive tv etc.
No idea why you'd even consider anything Samsung related.
Why in this world of yours is the only option Android TV?
Even with that, there are plenty of safer distros, or you can even get a cheap mini pc and throw one of the many awesome Linux distros on that have zero tracking and are far more capable/performant.
>All the popular streaming services throttle or block open devices.
This just isn't true. Have never encountered this.
Its effectively impossible to get some streaming services to stream content >720p to a linux device. I know I tried several years ago to use Disney+ and could not find any way to get 1080p content, even on a windows machine. I think now they have an official windows store app, but still refuse to stream full HD or 4k content to a web browser.
More recently I've tried hbo max and it does the same thing. Could not get higher than 720p, even with chrome and whatever DRM options theoretically fix the problem.
"DeepSeek implementation" in this context means a third-party product that uses a DeepSeek product, e.g. the DeepSeek API. This does not apply to open data running on a non-affiliated third-party inference provider.
So it's about staying nimble enough so you can easily switch over. Don't tie yourself down to a single product/harness.
reply