In mid-May 2026, Anthropic announced it would split subscription usage into two separate pools, effective June 15, 2026. Teams that wired their agent workflows tightly to one subscription model now have to re-plan capacity and cost on short notice.
Mid-May 2026: One Announcement, a New Billing Mode
In mid-May 2026, Anthropic announced that subscription usage would be split into two separate pools — effective June 15, 2026. What used to work as a single, shared usage allowance is now carved into two distinct buckets, each with its own limits.
This isn't the first move in that direction. Back in April 2026, Anthropic introduced a restriction that stopped third-party tools from consuming the flat-rate allowance of subscription plans. Anyone running an agentic tool or a custom integration through a Claude subscription already felt that first shift. Splitting usage into two pools is the logical continuation.
The net effect is plain to describe: teams that built their workflows assuming a single, flat usage allowance — especially those routing agentic or third-party tools through a Claude subscription — now face changed economics and new limits. And with short lead time.
Klingt interessant?
What Is Actually Happening Here
The distinction matters: this isn't a model being switched off, and it isn't an external directive. It's an ordinary business decision by a vendor about its own pricing and usage model. That's exactly what makes the case instructive.
Because the mechanics are the same as any shift in availability: a condition your architecture relies on changes on the vendor's schedule — not yours. If you ran a capacity plan last quarter that assumed a shared allowance, your numbers are wrong as of June 15. If you coupled a third-party tool to the subscription, you were already out of luck in April.
It's worth seeing this in context. In April, we described here how Anthropic first restricted access to a model with Claude Mythos. The lever was different — safety rather than billing — but the pattern is the same: the conditions under which you use a model are not a constant. They are a variable inside the vendor's control.
What This Means for CTOs and Tech Leads
Three consequences I think are worth taking seriously:
First: pricing and terms shift on the vendor's calendar, not yours. A subscription model isn't a contract for three years of planning certainty. It's a snapshot the vendor can adjust at any time — and announce whenever it suits them. A few weeks of lead time is rarely enough to cleanly re-plan capacity that grew over months.
Second: binding your cost model to a single subscription is building on sand. The pool split hits hardest where teams coupled agentic workflows tightly to the flat-rate plan. That coupling is the risk — not the new pricing model itself. If the economics of your entire workflow hinge on one tariff detail, then every tariff change is a fire alarm.
Third: architecture shouldn't follow a vendor's billing model. It's tempting to squeeze the cheapest available option for everything — one subscription, one endpoint, everything routed through it. But that makes another company's business decisions the foundation of your own architecture. The vendor changes its model, and your cost model changes too — without you touching a single line of code.
This Is Exactly Where nopex Comes In
The pool split confirms what we've been saying since the Mythos story: the decisions about access, pricing, and terms of AI models aren't made where your software runs. They're made by the vendor — and they apply to you anyway.
nopex is built for exactly this. We combine agentic software development with infrastructure that doesn't create hard single-vendor lock-in: European data centers, open models where possible, proprietary models where they add clear value — but the application logic never knows which vendor is behind it. If a vendor changes its pricing model, splits its usage limit, or restricts third-party tools, the platform absorbs it: it routes to a different model or provider instead of breaking your cost model.
That's the whole point: your architecture follows your logic, not a third party's billing model. The question of which model is cheapest today, and under which terms it's available, shouldn't slow you down — the platform handles that. What happens to the usage limit on June 15 will happen again, with this vendor or another. The only open question is whether it lands on your architecture when it does.
