Article is mistaken these subs are not available to businesses. Companies are paying much closer to API prices. The strategy is to get you accustomed to infinite tokens on your personal sub and bet that behavior transfers to work.
They are available. Seats for team or enterprise plans cost more than the retail prices, but they are fixed prices with resetting usage limits. You can assign seats to members that are the equivalent of $20/$100/$200/mo plans.
You can also do everything metered. There are multiple ways to buy.
Who is selling these with enterprise trappings? What you're describing evaporated 2+ months ago. Everything is metered for enterprise users now. If there happens to be a stray vendor offering this I'd wager 2 things. 1) it's about to be phased out. 2) model limits will be in place so even that $200 plan won't go very far.
Are we talking about the same thing? I just double-checked Anthropic still offers per-seat plans. So does OpenAI though they split the Codex-only plan away from per-seat. Gemini does as well. There’s pooled usage over certain limits but it’s still a good deal to upgrade the seat of a heavy user.
Looks more like AI slop with paragraphs like these;
> The pattern is identical across the board. Price for adoption, not for economics. Lock organizations in. Make AI a load-bearing part of every team's daily workflow. Worry about the bill later.
Not only that, but the API rate amounts being pearl clutched over in the article are still relatively trivial. 10k a month is not nothing, but when 10k a month enables a team of ~10-20 engineers, that's pretty good leverage.
It's not hidden at all, Claude pushes it even tho it poisons the context after every edit with false positives because it's always out of date. This feature should be hidden given how half baked it is.
I'm not 100% sure but I think OpenCode wants to control the harness and persistence, tool call flows etc. If they just used the Claude SDK then it would diverge architecturally from all the other providers, persist jsonl to ~/.claude, etc.
IMO there really needs to be a way to mark all variables non-null by default at package or at least a file level. Otherwise there will be a strong safety argument for always using T! syntax on almost every variable and this will just be a lot of noise.
> Providing a mechanism in the language to assert that all types in a certain context are implicitly null-restricted, without requiring the programmer to use explicit ! symbols.
i don’t think it will be that bad. we have a standard in our projects today that all java variables in code we own are not null. if you would like to have a nullable variable, you must annotate it with @Null
this is only an issue at the boundaries of our code where we interact with libraries. i imagine that will be the case with this new syntax as well
With good tooling compiler error vs lint error is a distinction that matters about as much in practice as parse error vs type error—your editor and CI pipelines will yell at you either way.
"software is a force multiplier" well maybe that's the point. I am a superstitious b*tch but maybe the Universe doesn't want our force to be multiplied any more!!!!
I've been trading for 4 years on the side mostly on intuition. I like to think one can emotionally program the powerful computer that is the unconscious mind to serve the distributed monster of global finance for profit. Sometimes I even do tarot. Seems to kinda work LoL what could possibly go wrong????
reply