On June 15 Anthropic starts counting Claude agent consumption separately from human chat consumption. Each user will have two mirror monthly meters, not one. If your team fires Claude Code agents in CI/CD, in background workers or in code-review pipelines, not monitoring that second meter can multiply the bill by 3-5× during the first weeks.
These are the 6 concrete changes to your setup that have to be live before the switch, not after. A few days ago we published another insight aimed at the CFO with the FinOps controls for the same switch. This one covers the other half — the technical one.
Why the switch changes the cost mechanics
Until June 14, Claude Code's unified meter gave you a comfortable illusion: a single line on the bill, a single alert, a single human (usually the CFO) reviewing the monthly aggregate. The consumption of a developer chatting with Claude and the consumption of a Claude agent resolving a job in CI added up against the same budget.
That hid an important pattern. A developer chatting with Claude consumes between 50 and 200 thousand tokens in a typical 2-3 hour session. A Claude Code agent launched against a large repo with a multi-step workflow can consume 1-3 million tokens in a single job — and typical workflows aren't one-offs, they're recurring. If your team has 10 developers on staff + 4-6 agentic jobs daily, the agent/chat token ratio is already ≈4:1, not 1:1.
With the unified meter, that ratio stayed buried under a comfortable average. With two mirror meters, the "agent" bucket will empty two to three times faster than the "chat" bucket — and it will be visible to the whole committee. Without technical governance before June 15, you reach June 16 with three alerts an hour during the first week.
Teams that already discipline their use of agents with Spec-Driven Development recover in velocity what the switch adds in FinOps oversight: in onext AI-Accelerated Development programs we measure ×7 development velocity, 0 sprints lost and −50% time-to-production over teams of 10-100 developers with the methodology. SDD isn't FinOps in disguise, but it's what keeps FinOps from slowing you down.
Change 1 · Separate the agent budget and the chat budget in your CLAUDE.md
CLAUDE.md is the file Claude Code reads as organizational context before each job. Until today it probably only holds code and architecture conventions. From June 15 it needs a section dedicated to budget.
Minimum structure: three explicit blocks.
- A monthly chat budget in tokens per developer (how many tokens each team member can spend in interactive sessions).
- A monthly agent budget in tokens per workflow (how much each recurring agentic pipeline can consume, distinguished by name).
- A breaking point (threshold in tokens/hour) above which the agent must stop and wait for human review.
What you gain: the team doesn't discover the problem when the bill arrives, it discovers it when the agent stops on its own and opens a message in Slack.
Change 2 · Add explicit rate limits per agentic workflow in CI
An agent launched from GitHub Actions or equivalent has no notion of the time of day or the state of the rest of the organization. Without rate limits, an innocent change to a workflow (for example, running the agent on every push instead of on every PR) can multiply consumption by 20× over a weekend.
The practical recommendation: for each agentic workflow defined in CI, explicitly declare a maximum number of concurrent jobs and a maximum number of jobs per hour. Without that limit, a careless merge at 7 p.m. on Friday can trigger dozens of jobs in parallel — and you won't see it until Saturday morning when the cost alerts arrive.
What you gain: a concrete, predictable, auditable ceiling. The simplest estimate to start with: N jobs per hour ≤ your hourly budget in tokens / average consumption per job × 0.7 (safety factor for variations). If you don't yet have a single measured job metric, measure three typical jobs this week before deciding the ceiling.
Change 3 · Instrument OpenTelemetry traces per agent
Without per-agent observability, debugging cost is impossible. The bill tells you how much the "agent" bucket consumed in the month; it doesn't tell you which agent, which prompt, which tool, or when.
OpenTelemetry is the open standard your team already uses for microservices. For Claude Code the minimum integration is: each call to the agent is recorded as a span, with attributes agent.name, agent.workflow, tokens.input, tokens.output and tools.invoked. If the agent calls another agent or invokes an external tool, it's recorded as a child span within the parent trace.
What you gain: when the "agent" bucket jumps on June 17 at 11:42, you open the dashboard, filter by the last hour and see exactly which workflow and which prompt is consuming 3 times more than expected. Without this, the June 15 switch turns any overrun into a ghost hunt that lasts days.
Change 4 · No-loop rules in SDD specs
It's the cheapest change to apply and the one with the highest impact on cost. A well-written SDD spec prevents the agent from falling into a recursive loop (it calls itself, it calls another agent that calls it back, it tries to solve the problem with 5 iterations when 1 was enough). A poorly written or absent spec turns every agentic job into a token lottery.
The operating rule: in the spec, always declare the maximum number of turns the agent can use to solve the problem, and declare which tools it cannot invoke (or, equivalently, explicitly declare only the ones it can). Without that boundary, the Claude Code agent tends to explore additional tools as a way of "trying something else" — and every exploration costs tokens.
This discipline is the foundation of the Spec-Driven Development we apply in every onext AI-Accelerated Development program. The difference between a team with mature SDD and a team without SDD post-June 15 is the difference between a predictable bill and an overrun alert every five days.
Change 5 · Mandatory human approval above a tokens/hour threshold
Rate limits and no-loop specs give you soft ceilings: the agent self-regulates. What's missing is a hard ceiling: a mandatory human intervention when hourly consumption exceeds a threshold agreed by the team.
The recommendation: for each agentic bucket (one per recurring workflow), set a threshold in tokens/hour. When it's crossed, the agent stops automatically and a message opens in a dedicated Slack channel with the last prompt, the last trace and an "approve next hour" / "stop for good" button.
What you gain: the worst-case scenario goes from "bill running wild for 5 hours until someone notices at 3 a.m." to "bill controlled for 30 minutes until the Lead Dev decides." It's the difference between €500 and €5,000 over a poorly governed weekend.
Change 6 · Weekly audit of tokens consumed by context vs by output
Few organizations separate them, and it's what causes the most surprise in the first review. In Claude Code (and in any modern agent) the cost of input tokens —the context fed into each call— is usually greater than the cost of output tokens.
If your team learned Claude Code with the human-chat metaphor ("I ask it, it answers me"), it tends to optimize the output: shorter answers, fewer iterations. But the real saving is in the context: entire repo files sent in every job when one section would do, conversation histories carried session after session, tools with excessively long descriptions replicated in every call.
A 30-minute weekly audit —reviewing 5 traces, comparing input vs output tokens, identifying where unnecessary context is being sent— usually cuts agentic consumption by between 15% and 30% in the first month. It's not a technical code change, it's a review discipline.
What not to do
There are three tempting reactions to the June 15 switch that are worth ruling out before taking them.
Blocking all Claude Code "until we understand the change." It's the decision that seems most prudent and is the worst. Your team falls back to Copilot without control or, worse, to programming without an agent — you lose the ×7 development velocity that sustains your roadmap and the teams return to habits that took months to shed.
Rewriting all the specs at the last minute. The June 15 switch is about pricing, not functionality. The specs you have today are still valid on June 16. If you reach June 14 with a massive refactor in progress, the regression risk multiplies the FinOps problem you were trying to avoid.
Migrating to an open-source model "just in case." The enterprise ecosystem is converging toward Anthropic (Wall Street JV in May, EPAM 10k certified architects, PwC 30k, SAP-Anthropic — all in the last 60 days). Migrating against that vector because a bill scares you is the right decision for day 30, not for day 60.
Your next step
The 6 changes above are your minimum viable setup before June 15. If you want to check whether your team already has the technical discipline the switch is going to demand, the SDD checklist for your team gathers 16 diagnostic questions — you get the result by email in under 10 minutes.
If, after taking the checklist, you want a 30-minute conversation with onext about how we apply this with teams of 100-1,000 employees, write to info@onext.es. The onext AI-Accelerated Development program is where we set up the 6 changes above as part of the setup, not as a post-overrun patch.
Frequently asked questions
What exactly changes on June 15 in Claude Code billing?
Anthropic separates the agent consumption meter from the human chat consumption meter. Each user will have two mirror monthly buckets instead of one. The unit price per token doesn't change; what changes is the visibility and allocation of consumption. Before June 15, an agent in CI and a developer in session consumed against the same budget; from June 15, against two independent budgets.
Does my team need to approve the changes at CTO level, or is Lead Dev enough?
The first 4 technical changes (CLAUDE.md, rate limits, OpenTelemetry, SDD specs) can be coordinated by the Lead Dev without CTO intervention if SDD discipline is already in place. The last 2 (human approval threshold and weekly audit) touch budget and organizational process — they need CTO validation because they define what is considered "abnormal" and who interrupts whom. Approving the monetary threshold without the CTO is what produces the 3 a.m. conflicts.
Does the Anthropic change also affect Claude used via direct API, or only Claude Code?
The meter split applies to the Claude Code product (the agent) and the Claude.ai product (the chat). If your team invokes the API directly from your own code without using Claude Code, direct API billing follows its usual logic — but it's worth checking whether what you call "direct API" isn't de facto an embedded agentic workflow, in which case the split reaches you all the same.
How much is the average bill of a 10-developer team estimated to rise post-switch?
It doesn't rise because of the switch itself — the unit price per token doesn't change. What does change is that overruns from poor agentic control are now visible and attributable. In practice, teams without technical governance see increases of 30-80% in the first month post-switch before applying the 6 changes, and return to baseline or below in the second month.
Is it better to wait for June 15 to start Spec-Driven Development, or to bring it forward?
Bring it forward. SDD reduces agentic consumption before the switch (fewer iterations, less unnecessary context, fewer loops) and reduces organizational pressure afterward (fewer overruns, fewer alerts, fewer discussions with the CFO). Starting SDD on June 14 gives you almost all the upside; starting it on June 16 gives it to you a month late and under the pressure of incident reports.
