The shape of a token bill

Four numbers explain almost every surprising LLM invoice, and three of them are not the ones people look at.

May 2026

cost per call

cached prefix reads0.1× list

volatile input1× list

output5× input rate

the prompt you rewrote≈ 0

Output tokens are the most expensive per unit and the least discussed.

Where the money actually is. Four terms, drawn to scale for a typical agent workload. The block people optimise first is the smallest one on the row.

Every token bill is four numbers multiplied together, and the intuition people carry — that the prompt is the expensive part — is usually wrong by an order of magnitude in whichever direction is least convenient.

Output tokens cost 5× what input tokens cost on Sonnet 5, and the same ratio holds on Opus 5 and Haiku 4.5. Caching does nothing to them at all — it is a purely input-side mechanism.Which means a verbosity instruction in the system prompt can outperform a caching change on some workloads. Both are worth doing; only one of them gets written up.

Read the usage block, not the dashboard

Three fields, on every response:

cache_read_input_tokens — served from cache, at 0.1× list.
cache_creation_input_tokens — written to cache, at 1.25× list.
input_tokens — the uncached remainder only. Not the prompt size.

The last one is the trap. An agent that has been running for an hour and reports four thousand input_tokens does not have a small prompt; it has a working cache. Add all three to get the real number.

The rest is arithmetic

The full model, with sliders, lives in the other essay. The short version: freeze your prefix, put volatile content below the breakpoint, and check cache_read_input_tokens > 0 in a test.

Thanks to everyone who has ever asked me “but why is the bill like that,” which is the question this whole page is an answer to. Mistakes, rounding and simplifying assumptions are mine; the prices are Anthropic’s published list rates and will drift.