Before I had an opinion about Anthropic's new Agent SDK credit pool, I added up what my own agents burn in a month. The heaviest job I run spins up ten-plus Opus instances per pass. That is programmatic work, the kind the Agent SDK and claude -p are built for, not interactive chatting. It is the exact usage the June 15 change puts on its own meter.
So when the "your subscription just got cut 25x" screenshots started circulating, I had a number to check the panic against. The meter was always running. June 15 just turns the display on. For Pro and most Max-5x subscribers, that display is going to show a number well under the cap, and the change is pure visibility. For Max-20x power users running fleets of agents through third-party tools, it is a genuine 15-to-30x reduction in subsidized inference. Both are true. The mistake is letting the second group's reality set everyone's blood pressure, because the response is identical either way: treat programmatic Claude as metered compute, and budget it per workload.
What changes on June 15
Two pools, one subscription. Anthropic's help-center article draws the line cleanly. Interactive usage stays exactly where it is: Claude Code in your terminal, the chat apps on web, desktop, and mobile, and Cowork all keep drawing from your normal subscription limits. Programmatic usage moves to a separate monthly credit: the Agent SDK, claude -p, Claude Code GitHub Actions, and any third-party app built on the SDK.
Here is the part worth reading twice. The credit is denominated in dollars, metered at full API list rates, and it does not roll over.
| Plan | Monthly Agent SDK credit | Covers |
|---|---|---|
| Pro | $20 | Solo claude -p scripts, light automation |
| Max 5x | $100 | Daily agentic dev, a personal CI hook |
| Max 20x | $200 | Heavy fleets, multi-agent pipelines |
| Team Standard | $20 / seat | Shared automations (per user, no pooling) |
| Team Premium | $100 / seat | Heavier per-seat programmatic work |
When the credit runs out, programmatic calls stop, unless you have opted in to extra usage, which then bills at standard pay-as-you-go API rates. The opt-in is a one-time toggle. Anthropic is emailing eligible accounts before June 15 to claim the credit, so the practical first action is small: read that email.
The credit does not roll over and does not pool across seats. A bursty workload that spends nothing in week one and everything in week four still resets to zero on the first. Plan around the calendar, not just the total.
The calm framing also skips how this arrived. Not as a tidy billing update: Anthropic banned third-party agents outright in April citing capacity, took the backlash, and reinstated access in May with the credit pool as the condition. "Visibility event" is accurate for the meter. It undersells a value proposition that got withdrawn and renegotiated in public. Either way, June 15 leaves you a number to budget against, which is the rest of this post.
Whether it's a price hike depends on whether you were extracting the subsidy
This is the question the screenshots skip. A flat subscription that lets code call Claude without limit is only a bargain if your code calls Claude a lot. So the honest answer splits by how hard you were already pushing.
If you are a Pro or Max-5x subscriber whose agents run a handful of times a day, you were never near the new ceiling. Anthropic's own cost guidance puts the average enterprise Claude Code developer around $13 a day, and the bulk of that is interactive work that does not touch the new pool at all. Your claude -p cron job and your occasional Agent SDK experiment fit inside $20 to $100 with room to spare. For you, the credit pool is a dashboard you did not have before. Nothing got taken away.
The Max-20x crowd has a real grievance, and pretending otherwise loses them in the first paragraph. Zed measured the old subsidy at roughly 15 to 30 times API pricing for agent usage. Tool builders ran businesses on top of that math. Capping their programmatic access at $200 of API-rate inference is, for them, a 15-to-30x reset, and no amount of "you should have been measuring" makes that not sting. As one senior data scientist told InfoWorld, the monthly limit "won't even last a day of serious work." When an Anthropic engineer posted that subscribers "don't pay extra," readers attached a community note correcting it, and for the heavy users that correction is the honest read.
But notice what the heavy users are doing in response. They are pricing their workloads. InfoWorld quotes Paul Chada of Doozer AI with the line worth taping to every engineering lead's monitor: "Stop optimizing for the subsidy and start optimizing for the token." That is the move. It is the vibe-coding-versus-agentic-development question wearing a billing statement. The teams that win the next quarter are not the ones who found a cheaper subscription. They are the ones who know what a unit of their agentic work costs.
What your agent workloads burn
Most engineering orgs cannot answer that yet, and it is the only question that matters now. The answer is not one number. It is a number per workload class, because the spread is enormous.
A single interactive coding turn is cheap. A 20-turn agent loop is not, because the cost compounds: every turn re-sends the growing context, and Opus 4.7's tokenizer plus higher effort levels can stretch the effective per-trace cost to 8 or 10 times the per-token sticker. Fan that loop out across a multi-agent pattern and Anthropic's own number is a 15x token multiplier over a chat. The Agent SDK and /batch are precisely the patterns that draw from the new pool, and they are the most expensive shapes you can run.
Run the arithmetic against a $100 Max-5x credit and the workload class, not the headline, decides your ceiling.
Those run counts are illustrative, not a benchmark, and that is the point. The same credit buys 200 light scripts or 14 multi-agent runs. If you do not know which shape dominates your usage, you do not know your budget, and the per-token rates are published right there in the API pricing for you to do the math. This is the same discipline as putting a budget on each model-and-effort cell of your routing layer: you cannot govern spend you have never attributed. If your work is mostly interactive or runs on Sonnet rather than Opus, you live at the cheap end of that chart and may never feel the cap. Knowing which end you live at is the whole job.
Where the cloud-spend analogy breaks
"Budget it like cloud compute" is the right instinct and an incomplete one. The State of FinOps 2026 reports that 98% of organizations now manage AI spend, up from 63% a year ago, and per-workload governance is the maturity bar. Borrow that muscle. Just know three places the analogy snaps.
Credits do not roll over. AWS lets an idle month bank against a busy one; this pool does not. A workload quiet for three weeks that then slams the pool in the fourth gets no relief from the lull.
They are also per user, never per team. A shared CI pipeline everyone depends on draws against one person's $100, not a team budget, which makes shared automation awkward in a way no cloud project account is.
Then there is the part cloud bills never had to handle: agents do not self-throttle. A human gets tired and stops. An agent runs tests, retries, browses, and loops while nobody is watching, which is how one weekend of unattended refactoring posts a four-figure bill. Autonomous burn varies wider than VM-hours ever did.
Design around all three. Put hard per-run caps on unattended jobs. Route the heaviest fan-out to a dedicated API key with its own budget instead of starving the shared pool. Instrument burn per workload so the quiet weeks do not lull you. And size the plan to the work, not the headcount, which is the same per-role provisioning logic that held well before the credit pool. The pool just makes it enforceable.
The meter was always running on your agentic work. June 15 only makes the number visible, and a visible number is a gift to anyone trying to run a serious engineering budget. The teams that treat their subscription as an unlimited entitlement will get a surprise. The teams that treat it as metered compute, the way they already treat their cloud bill, will adapt in an afternoon.
Want to pressure-test your own programmatic budget before June 15? Mapping your workload classes to the right plan tiers is what a focused advisory session is built for. I have run this math for the engineers I provision, daily-use developers at $100 and power users at $200, and the surprising part is never the total. It is which workload was quietly eating it. Grab a 15-minute slot and we will find yours.