Comparing AI coding agents by their advertised per-million-token price is like comparing cars by fuel price per litre. It is a real number, and it tells you very little about what the journey costs.
The mechanisms below come from Anthropic's published pricing documentation. Other providers differ in detail, but the shape of the problem is the same everywhere, and knowing the shape is what lets you read any price list properly.
Output is not priced like input
Across the entire model range, output tokens cost several times what input tokens cost. The ratio is consistent enough to plan around: output sits at roughly five times the input rate on each model tier.
This matters for coding specifically. An agent that reads a large codebase and answers briefly behaves very differently, cost-wise, from one that reads little and generates a lot. Two agents can consume identical total tokens and produce bills that differ substantially, purely from the input-output split.
Caching has a break-even point
Prompt caching is the mechanism most likely to change your bill, in either direction.
The documented multipliers, relative to the base input price:
| Operation | Multiplier | Duration |
|---|---|---|
| Cache write, 5 minutes | 1.25x | valid 5 minutes |
| Cache write, 1 hour | 2x | valid 1 hour |
| Cache read (hit) | 0.1x | matches the preceding write |
A cache hit costs a tenth of the standard input price. The documentation states the break-even explicitly: caching pays off after just one cache read for the five-minute duration, or after two reads for the one-hour duration.
The implication runs both ways. An agent that re-reads the same context repeatedly within a session benefits enormously. An agent that writes a cache and never reads it back has simply paid a 25% or 100% premium on those tokens for nothing.
Tools cost tokens before they do anything
This is the least visible line item, and for agentic workloads it is not small.
When a request includes tools, three things consume input tokens beyond your own content:
- the tools parameter itself, carrying names, descriptions and schemas
- the tool_use and tool_result blocks in requests and responses
- a dedicated system prompt the API adds automatically to enable tool use
That automatic system prompt is documented per model and per tool-choice setting, ranging from a few hundred tokens to several hundred more when tool choice is constrained. Individual tools add their own definitions on top: the bash tool and the text editor tool each carry a documented token cost of their own.
None of this appears on a price-per-million-tokens comparison table. All of it is charged on every single request that carries tools, which for a coding agent is essentially all of them.
Server-side tools bill separately
Some capabilities are charged in addition to tokens rather than through them.
Web search is billed per search performed, on top of the standard token cost of the content it returns. And the returned results become input tokens, both in the search iterations of a single turn and in the subsequent turns of the conversation, which means one search can keep costing you across a long session.
Web fetch, by contrast, carries no additional charge beyond the tokens of the fetched content. The distinction is worth knowing because the two feel identical in use and bill differently.
A model change can raise costs with no price change
The subtlest mechanism of all.
Anthropic notes that its newer models use a different tokenizer, one that produces approximately 30% more tokens for the same text, with the exact increase depending on content and workload.
Read that against a price list. If the per-token rate is identical but the same source file now counts as more tokens, the identical task costs more. A migration that looks free on the price sheet is not free in practice, and no amount of comparing headline rates would have revealed it.
Where real savings sit
Three levers, in rough order of effect for coding work.
Match the model to the task. The documented guidance is to use the smallest capable model, reserving the most expensive tier for the hardest reasoning. The spread between tiers is large, and most agent turns are not the hard part of the problem.
Cache deliberately, not reflexively. Caching a large system prompt or a stable set of files that will be read back repeatedly is clearly worthwhile. Caching something read once is a loss. The break-even is one read, or two on the longer duration.
Batch what is not interactive. The Batch API gives 50% off input and output for asynchronous work, and it combines with caching. It is useless for a conversation, and well suited to a mass refactor or a test-generation pass.
Reading any price list properly
When you next compare two agents, the headline rate answers one narrow question. Four others decide the bill:
- What is the output-to-input ratio for how you actually work?
- Will the context be re-read often enough to clear the caching break-even?
- How much tool overhead rides on every request, before your content?
- Are server-side tools billed separately, and do their results persist as input tokens?
An agent with a higher headline price and better caching behaviour can cost less than a cheaper one that re-sends the same context every turn. That is the comparison worth making, and it is not the one the price pages invite you to make.
The mechanisms described here, including the caching multipliers and their stated break-even, the 50% batch discount and its combinability, the tool-use token overhead, the per-search web-search charge, and the approximately 30% tokenizer increase on newer models, are taken from Anthropic's published pricing documentation, checked at the time of writing. Specific rates are deliberately not quoted here because they change; the mechanisms are what remain useful. Verify current figures against the provider's own page before budgeting. Commercial links carry the rel="sponsored nofollow" attribute; an affiliate commission may apply at no extra cost to you.
