Key takeaways
- A budget written into the prompt cannot stop a run. Only the layer that places the call can refuse to place the next one, which puts the ceiling in the orchestrator or nowhere.
- Declaring a browser toolset adds about 6,610 input tokens on Claude Opus 5 and a computer toolset about 4,520, before the agent has read a word of its task.
- 4 charges on an agent bill are not tokens at all: web search at $10 per 1,000 searches, code execution at $0.05 per container-hour past a free allowance, managed session runtime at $0.08 per session-hour, and multipliers such as 1.1x for US-only inference.
- A budget calibrated on an older model under-counts on a newer one. Anthropic states that Claude 4.7 and later use a tokenizer producing roughly 30% more tokens for the same text.
- Our recommendation: enforce 2 ceilings, a per-task one that aborts the run and a per-tenant one that refuses new runs, and express both in currency rather than tokens.
Ask a team where the agent’s budget lives and the answer is usually a sentence in the system prompt telling the model to be efficient. That sentence has no mechanism behind it.
The layer that can actually stop a run is the one that places the call. It is also the only layer that sees the charges a token counter never touches, and on a bill made of per-search fees, container hours and routing multipliers, that gap is not rounding.
Why is a budget in the prompt only advice?
Because the model is the thing being limited, and it cannot enforce a limit on itself.
A prompt instruction changes the distribution of what the model tries. It does not prevent anything. A model asked to stay under a budget will often behave more frugally, and will still place call number 41 if its plan calls for one, because nothing in the request path is checking.
The orchestrator has the opposite properties. It has no opinion about the task and complete authority over whether the next HTTP request happens. Google’s Site Reliability Engineering, chapter 22, makes the same argument for retries: the recommendation is a server-wide retry budget, for example 60 retries per minute in a process, enforced at the layer that issues the calls. The pattern transfers directly, and the reason is identical. Budgets work where the calls are made.
Billing alerts sit at the other extreme. They are accurate, they are provider-native, and they fire after the money is gone. An alert is a report, not a control, and the distinction matters most precisely when a loop is running fast.
What does the token counter fail to see?
Four kinds of charge, none of which is denominated in tokens.
| Charge | Billed per | Published rate | Visible to a token counter |
|---|---|---|---|
| Web search tool | Search performed | $10 / 1,000 | No |
| Code execution | Container-hour past the allowance | $0.05 / hour | No |
| Managed session runtime | Session-hour while running | $0.08 / hour | No |
| US-only inference routing | Multiplier on every token category | 1.1x | No, it is a price change |
| Input and output tokens | Million tokens | Model-dependent | Yes |
Only the last row is what most budget code counts. The code execution tool bills a minimum of 5 minutes per execution and gives each organisation 1,550 free hours a month before the hourly rate applies, which means the charge is zero for a long time and then is not, and nothing in a token counter marks the transition. Anthropic’s pricing documentation also waives the code execution charge entirely when the request includes the current web search or web fetch tool, so the identical agent step is free in one configuration and metered in another.
There is a fifth trap that is not a separate charge but silently rescales every existing budget. Anthropic’s pricing documentation states that Claude 4.7 and later use a newer tokenizer producing approximately 30% more tokens for the same text. A ceiling of 200,000 tokens per task, tuned against an older model, is a materially tighter ceiling after a model upgrade, and the run that starts aborting did not get more expensive in money terms.
What does a tool definition cost before the agent says anything?
Between a few hundred and several thousand input tokens, on every single request.
| What is declared | Added input tokens | Charged on |
|---|---|---|
| Tool-use system prompt, tool_choice auto or none | 286 | Every request with tools |
| Tool-use system prompt, tool_choice any or tool | 406 | Every request with tools |
| Bash tool definition | 325 | Every request |
| Text editor tool definition | 700 | Every request |
| Computer toolset, default members | 4,520 | Every request |
| Browser toolset, default members | 6,610 | Every request |
The browser toolset row is the one worth sitting with. Declaring it costs about 6,610 input tokens on Opus 5 before the agent has read its task, and it is charged again on every turn of the loop. A 40-turn run pays that overhead 40 times.
Two consequences follow. The first is that trimming the toolset is a real lever: Anthropic’s pricing documentation notes that disabling zoom with configs removes about 410 tokens from the computer toolset, and enabling all four optional browser members adds about 880. The second is that this overhead is exactly the kind of fixed per-call cost that a per-task cost calculation has to include explicitly, because it does not scale with how much work the agent does.
Why currency, not tokens
A token ceiling has to be recomputed whenever the model changes, the cache state changes, the routing changes or the tokenizer changes. All four of those change without anyone editing the budget.
A currency ceiling survives all of them, because the conversion happens at the moment of the call using the rate that actually applies.
Where should the ceiling live, and what should it do?
Two ceilings, both in the orchestrator, doing different things.
- Per-task ceiling: abort the run. Checked before each model call, against the accumulated spend of this task. When it trips, the run stops and becomes an escalation rather than an exception, which is the same escalation path a permission failure needs.
- Per-tenant ceiling: refuse new runs. Checked when a run is admitted, against spend in the current window. When it trips, running work finishes and nothing new starts, which is the degradation behaviour that matters when a provider or a budget starts rationing capacity.
The difference is deliberate. Aborting in-flight work on a tenant ceiling destroys partial progress that has already been paid for. Refusing admission costs nothing already spent.
Three properties make the difference between a ceiling and a counter:
- It is checked before the call, not after. A check that runs on the response has already bought the response.
- It includes the charges that are not tokens. A search counter and a runtime clock, added to the spend figure at the same point the token cost is.
- Tripping it produces a queue item, not a stack trace. A run that raises and dies has not been stopped under policy, it has crashed, and nobody finds out why until someone reads the logs.
The question for a cost review is not what the agent spent last month. Ask: what is the largest amount a single runaway task could spend before something refuses to place the next call? If the answer requires a person to notice, there is no ceiling.
Frequently asked questions
How do you stop an AI agent from running up a large bill?
Enforce a ceiling in the orchestrator, the layer that places each model call, so it can refuse to place the next one. Budgets described in the prompt are instructions the model may follow, not limits, and billing alerts fire after the money is spent.
Does a token budget capture the full cost of an agent?
No. Server-side tools such as web search bill per use rather than per token, managed agent sessions bill for runtime, and routing choices apply multipliers. A counter that only sums input and output tokens misses all of these.
How much do tool definitions add to an agent request?
More than most budgets assume. Anthropic's published figures for Claude Opus 5 are 286 tokens for the tool-use system prompt, 325 for the bash tool, 700 for the text editor, about 4,520 for a computer toolset and about 6,610 for a browser toolset.
Should a budget be expressed in tokens or in currency?
Currency, because token prices differ by model, by cache state and by routing, and because several agent charges are not denominated in tokens at all. A token ceiling has to be recalculated every time any of those change.
Method and sources
- Anthropic, Claude pricing documentation, read 25 September 2026. Source of the tool definition overheads, of web search at $10 per 1,000 searches, of code execution at $0.05 per container-hour beyond 1,550 free hours per organisation per month and free when used together with web search or web fetch, of managed session runtime at $0.08 per session-hour, of the 1.1x US-only inference multiplier, and of the statement that Claude 4.7 and later use a tokenizer producing roughly 30% more tokens for the same text.
- Site Reliability Engineering, chapter 22, Addressing Cascading Failures, Google, consulted for the server-wide retry budget pattern and its worked example of 60 retries per minute per process.
- Token Economics for LLM Agents: A Dual-View Study from Computing and Economics, arXiv:2605.09104, consulted for the treatment of tokens as a budgeted production factor rather than an unmetered input.
- Figures circulate for specific runaway-agent incidents, including a widely repeated $47,000 loop. We found no primary publication behind that number and it therefore does not appear in this article.
- The two-ceiling policy and the abort behaviour recommended here are our editorial judgement. We report no spend reductions of our own, because we have not measured them.