Anthropic will now stop an agent session at a number you choose, written in whole cents as a string. That number is metered at list price rather than the rate you pay, which makes the cap tighter than your invoice and looser than one request already in flight.

Three line items, and one of them is a clock

The budgets page lists what the platform meters, and the list is shorter than you would guess. Model tokens at each served model's list price. Web searches at $10 per 1,000. Session running time at $0.08 per hour. That is the whole meter. Advisor consultations, which arrived in the same August 7 release, are folded into the same budget at the advisor model's rates.

The container row is a genuine simplification and worth saying out loud. Outside Managed Agents, code execution bills by execution time with a five minute minimum, 1,550 free hours per organization per month, then $0.05 per hour per container, and it bills that time even if the tool is never called as long as files were attached, because the files get preloaded. Inside a session, none of that applies. Anthropic's wording is that session runtime replaces the code execution container-hour billing model, and that you are not separately billed for container hours on top of it. One clock, not two.

Web search is the line item most likely to surprise a research agent. At a cent per search, a hundred searches is $1 and four percent of a $25 cap before the model has reasoned about any of the results, and the retrieved content lands on top as input tokens. Errors are not billed, and each search counts once no matter how many results come back, which is the sane way round.

On a cheap model, the clock outbills the tokens

Eight cents an hour sounds like rounding error, and on Fable 5 it is. On Haiku 4.5 it is frequently the largest thing on the bill. The reason is that runtime is priced per hour of wall clock while tokens are priced per million, so the crossover point moves with the model's rate card rather than with anything about your workload. Take a session whose output runs a quarter of its input, which is roughly the shape of an agent that reads a lot and writes a little, and ask how many input tokens per hour it takes for the tokens to outweigh the clock.

A Haiku session that spends an hour on 20,000 input tokens is a session where two thirds of the cap went on time rather than thinking. That is not a hypothetical shape either. It is what a polling agent looks like, or a monitor, or anything that waits on a slow external tool between short model calls. The fix is architectural rather than financial: run those in fewer, longer sessions, or accept that you are renting a process, not buying inference.

Anthropic's own worked example makes the point without meaning to. A one hour Opus 5 coding session with 50,000 input and 15,000 output tokens comes to $0.25 plus $0.375 plus $0.08, so $0.705. Turn caching on so 40,000 of those input tokens become cache reads and the same session is $0.05 plus $0.02 plus $0.375 plus $0.08, so $0.525. We recomputed both and they are correct to the cent. But look at what caching did to the composition: the eight cents of clock went from eleven percent of the bill to fifteen percent, because caching shrinks the token side and leaves the clock alone. The better your caching, the more of your agent bill is time.

One mercy in the meter, and it matters more than it looks. Runtime counts only the running status, measured to the millisecond. Time spent idle waiting for your next message or a tool confirmation does not count, nor does rescheduling, nor terminated. So a session parked at its cap while you decide whether to raise it is not quietly eating the increase, and an agent blocked on a human is free. We wrote about the general shape of this problem in the cost-per-session breakdown, and the caching mechanics in the prompt caching guide.

The input that loses you two orders of magnitude

The cap is a string of whole cents. Anthropic explains the choice of type: the amount is a string rather than a number so no float rounding is ever applied to it. Sound reasoning, and the validation catches the obvious mistake. Pass "25.00" and you get a 400, because decimal forms are rejected.

The mistake it does not catch is "25". That is a perfectly valid cap of twenty five cents, one hundredth of what whoever typed it meant. Nothing errors. The session simply stops almost immediately, and on Opus 5 twenty five cents buys 50,000 input tokens or three hours of doing nothing but existing. We would put a cents-versus-dollars assertion in whatever wraps this call, because the failure mode is a silent 100x rather than a loud one, and the documentation does not flag it.

Reading the meter has its own precision story. usage.list_cost is an object, not a number, carrying the same string-of-cents shape as the cap. Enforcement uses the exact, unrounded list cost, while the figure reported to you is rounded to the nearest cent, so what you read can sit up to half a cent either side of what the check actually used. That is invisible at $25 and load-bearing at fifty cents.

There are also two fields called active_seconds and they do not agree. The one on usage counts overlapping concurrent thread activity once and is what runtime is priced on. The one on stats sums each thread's own active time, so in a multiagent session it will read higher. Per-thread list_cost figures are rounded independently and exclude session runtime, so they do not sum to the session total. Anthropic says the session figure is the authoritative one, which is the answer to a question most people would not have thought to ask.

The cap stops at a price you might not be paying

Here is the sentence that deserves more attention than it has had: list cost is not your contracted price, and if your organization has negotiated discounts the session reaches its cap when the list-price total does, so your billed spend might be lower than the cap. Read that as a design decision rather than a caveat. The cap is denominated in a currency the enterprise buyer does not transact in.

Whether that is a bug depends on what you wanted the cap for. As a safety rail it errs in the correct direction, stopping early rather than late. As a budget it silently underspends, and if you sized the cap to a real monthly allocation you will be leaving a proportional slice of it unused on every run. Nobody with a negotiated rate should set these numbers without dividing by their own discount first.

The Batch API discount cannot enter the calculation at all, which removes one worry. Anthropic's table of Messages API modifiers that do not apply to Managed Agents says it plainly: sessions are stateful and interactive, and there is no batch mode. Promotional pricing is the genuine open question. Claude Sonnet 5 is on an introductory $2 and $10 through August 31 and moves to $3 and $15 on September 1, which we covered in the September repricing post. No document says whether list_cost uses the promotional rate, and none addresses a long-running session that straddles the date. The natural reading is that the intro price is the current list price and therefore the one used, but that is our inference and not a published rule.

How far past the cap a session can actually settle

The cap is checked between model requests, not mid-request. Before each request the platform compares consumed list cost against the cap, and once the total reaches it every thread pauses before its next request. Anything already in flight was admitted while the session was still under, and it runs to completion. Anthropic's own illustration is a session capped at "50" pausing with a list_cost of "53", described as expected rather than a billing error, and the guidance is to treat the budget as a bound on new work rather than an exact stopping point.

Fair enough, but a bound with no size is not much use, so we put a number on it. The overshoot is bounded by one model request per thread. The most expensive single request a model can serve is its full context window in and its maximum output out, so that product is the worst case margin on a single-threaded session. Context and output ceilings below come from our own catalogue.

Read those margins as ceilings, not forecasts. Getting Fable 5 to $16.40 in one request means filling a million-token window and generating 128,000 tokens of output on the request that happens to straddle the cap, which is not what a typical turn looks like. A more ordinary 200,000-token Opus 5 request with 32,000 tokens of output is $1.80, or seven percent of a $25 cap. The point of the ceiling is that it scales with the model rather than with the cap, so the same $25 written against Haiku is a precise instrument and against Fable 5 is a suggestion.

Multiagent sessions widen this further, because the bound is per thread and a session can hold up to 25 concurrent threads, with advisor threads exempt from that limit. We are not going to publish a 25x version of the table, because every thread issuing a maximum-context request in the same instant as the cap trips is a thought experiment rather than a workload. The honest statement is that the margin is one request per running thread, and if you run wide fan-outs on an expensive model you should size the cap with that in mind.

Nobody can tell you whether the cap counts the US surcharge

The same August 7 release note that introduced session budgets also let you set inference_geo inside an agent's model object, with a per-session override. Pinning it to "us" prices Claude 4.6 and later at 1.1x the standard rate across every token category, input, output, cache writes and cache reads alike. That multiplier stacks on top of the caching multipliers and on top of fast mode, so a one hour cache write on a US-pinned session is 2.2x base input and Opus 5 fast mode output becomes $55 per million. On Priority Tier, each token consumed with the pin draws 1.1 tokens from committed throughput.

So two features shipped on the same day: one that meters a session against public list rates, and one that multiplies the rate you are billed by 1.1. The obvious question is whether the meter knows about the multiplier. We went looking for the answer and there is not one. The budgets documentation contains no occurrence of inference_geo, and neither does the page that defines what list_cost means. The only sentence connecting the two ideas lives on the pricing page and uses the word billed: when an agent's pin is set to "us", tokens consumed by sessions running that agent are billed at 1.1x the standard rates. Billed is not the same verb as capped.

Both readings survive the text, and they differ by real money. If the multiplier sits outside list_cost, a US-pinned session with a $25 cap can invoice $27.50, and the shortfall lands on exactly the regulated workloads most likely to have wanted a hard ceiling in the first place. If it sits inside, then the phrase public list price is quietly doing work it does not advertise, because the figure would be a geography-adjusted price rather than the published one. We are not going to guess which. It is settleable empirically in a single session: pin one to "us", run an identical workload unpinned, and compare the two list_cost readings.

There is one piece of evidence that geo-aware cost accounting is an unsolved problem inside Anthropic and not merely an undocumented one. An issue filed against Claude Code in May, titled /cost estimate does not account for inference_geo pricing multiplier, reported that the built-in cost display omits the multiplier and therefore reads consistently below what is actually billed. It was labelled a bug, nobody replied to it, and a staleness bot closed it as not planned on June 18 with the note that it had been inactive too long. Different surface from Managed Agents, and we are not claiming otherwise. But the tool with the same blind spot went a month without a human looking at it, which is the context that makes the silence in the budgets docs worth writing down. The reporter's figure of roughly nine percent is also the right way round: a 10% surcharge on the base makes an unadjusted estimate understate the true bill by 9.09%.

A footgun worth knowing while you are in here. Overrides replace the model object in full, and effort is explicitly exempted from that rule while inference_geo is not. So a session override or agent update that supplies model without the pin clears it, and the session silently falls back to the workspace default. That changes where your inference runs, which is a compliance event, and it changes your bill by ten percent, which is a finance event. One of those will get noticed.

The states a capped session can strand you in

A session that hits its cap goes idle with a stop_reason of budget_reached. It is not terminated, and its history and sandbox survive like any other idle session. On the stream you get a per-thread session.thread_status_idle as each one pauses, then a session.usage snapshot, then session.status_idle, in that order, with the usage event always immediately before the idle one.

Four event types are accepted once the cap is reached, and they exist to settle work already underway: user.tool_confirmation, user.tool_result, user.custom_tool_result and user.interrupt. Anything that would start new work is rejected with a 400 that names the accepted list, user.message included. The interrupt case has a wrinkle: sent while every thread is paused at the cap it is accepted and then ignored, never appearing in the event list and changing nothing. No event resumes a session paused at its cap.

Two of the stop-reason rules will bite anyone writing a supervisor loop. A thread whose final request both crosses the cap and finishes its turn reports end_turn on its own event while the session reports budget_reached, so key on the session-level reason. And if one thread is waiting on requires_action while another is paused at the cap, the session-level reason is requires_action. A pending ask outranks the cap.

Changing the cap is allowed at any time, up or down, provided the new value is strictly greater than consumed list cost. Because a paused session usually sits a fraction past its old cap, base the new figure on the reported usage.list_cost rather than on the old max_list_cost, and add a cent, since the reported value is rounded and can read just under the exact figure the check uses. Attaching a budget to a session that was created without one is a 400: it is a creation-time decision.

Removal, by contrast, is a one-way door. Passing {"budget": null} resumes the paused work, and a session whose budget has been removed can never be given a new one. Anthropic's advice is to change the budget instead, and it is correct. Deployments behave differently and more sensibly: a deployment's budget can be cleared and set again later. Note also that a deployment budget is copied onto each session rather than pooled, so a "2000" cap on a deployment means about $20 per run, not $20 in total. If you were hoping for a cumulative spend ceiling across scheduled runs, this is not it, and Google's account-level billing caps remain a different kind of instrument.

Then there is the trap. A budgeted session whose roster includes a model with no public list price is rejected at creation with a 400 saying no list price is available. Worse is arriving there mid-flight: if a budgeted session's usage comes to include such a model, the budget can no longer measure spend, the session can pause at budget_reached, and changing the budget is rejected. The only exit is removing it, which is the irreversible move, so you forfeit the cap on that session permanently to get it running again. The likeliest way in is a limited-availability model such as Claude Mythos 5, which the pricing page lists at $10 and $50 but does not sell to everyone. If you cap sessions and also keep a limited-access model on any roster, that combination is worth an explicit guard.

Size the cap from the model, not from the intent

Use it. A stateful agent with a published, enforced ceiling is a genuine improvement over the previous arrangement, which was to watch a dashboard and hope. It is also the first spend control from any provider that meters an agent's existence rather than only its tokens, and that is the right unit for something that can sit in a loop.

Set the cap from the model, not from your intent. Take the target spend, subtract the costliest single request the model can serve, multiply that subtraction by the number of threads you actually run concurrently, and write the remainder as the cap. On Haiku that arithmetic barely moves the number. On Fable 5 it will move it a long way, and if the result is negative then a per-session cap is the wrong tool for the ceiling you had in mind.

Two guards are worth writing today. One asserts that the value you are about to send is in cents, because "25" fails silently and quietly wastes a run. The other refuses to send model in an override or an update without an explicit inference_geo, because the full-replacement rule turns an unrelated version bump into a change of jurisdiction and a ten percent change of price.

And if you are on a negotiated rate, divide before you set anything. Every cap you write is in list dollars, and your invoice is not. That gap is the difference between a rail that protects you and a budget that quietly returns a fifth of itself unspent.

One last thing that says something about how new all of this is. The machine-readable API reference for session creation, one day after launch, still has no budget parameter, no list_cost or active_seconds on its usage schema, and no inference_geo on its model config. The guides describe a feature the reference does not know exists yet. If you generate clients from that spec, generate them again in a week.

Checked against Anthropic's own pages

Everything above is Anthropic's own documentation, read on August 8, 2026, or arithmetic on rates published there. The two negative findings, that inference_geo appears nowhere in the budgets or usage documentation and that the API reference lacks the new fields, were checked against the raw source of those pages rather than inferred from a summary.

• Anthropic: session budgets - The request shape, the three metered line items, the rejection of decimal amounts, the between-requests enforcement rule, the capped-at-50-settles-at-53 example, the four accepted event types, the one-way removal warning, and the no-list-price failure at creation and mid-session
• Anthropic: pricing - Every per-million rate quoted here, the $0.08 session-hour SKU and its running-status metering, web search at $10 per 1,000, web fetch at no charge, the code execution container terms that session runtime replaces, fast mode at $10 and $50, and both worked examples. Also the sentence that a US-pinned agent's tokens are billed at 1.1x, which is the closest the docs come to the question in the geo section
• Anthropic: data residency - The 1.1x multiplier across all four token categories, the Claude 4.6 and later restriction, the two available geos, the Priority Tier burndown at 1.1 tokens per token, and the workspace allowlist behaviour
• Anthropic: API release notes - Dates session budgets and the Managed Agents inference_geo control to the same entry, August 7, 2026, alongside the advisor roster addition
• claude-code issue 60641 - The /cost and inference_geo report. Opened May 19, 2026, labelled bug, closed as not planned by a staleness bot on June 18 with no human reply. A Claude Code display issue rather than a Managed Agents one, cited here only as evidence that the multiplier is missing from Anthropic's own cost accounting elsewhere

Two things we could not establish. Whether list_cost applies the inference_geo multiplier is undocumented in both directions, and we would rather leave it open than assert a number nobody has published. Whether the cap uses promotional list prices, and what happens to a session that runs across the September 1 Sonnet 5 repricing, is likewise unaddressed. Both are answerable by experiment, and if you run one we would like to see the numbers.