Your Agent Bill Is Quadratic: Where the Money Actually Goes

Most “cut your AI bill” advice is a listicle, and listicles fail here for a specific reason. They treat every saving as equivalent. Trim your system prompt, switch to a cheaper model, compress your outputs. Each tip presented as roughly interchangeable, each worth “some” money. They aren’t interchangeable. There is a strict hierarchy, and it comes from one piece of arithmetic that almost nobody states outright:

By a turn I mean one request to the model and one response back. A tool call and its result start the next request, so an agent burns many turns per user message.

Once you see that, every optimisation you’ve heard of sorts itself into one of four tiers.

I want to work through the evidence for that ranking properly, which is more than one post can hold, so this is the first of five. Independent benchmarks, controlled experiments, and a few numbers vendors would rather you didn’t check. This part is the mechanics: what a token actually costs, where a real session’s money went, and why the cost curve bends. If you only take one chart from the whole thing, take the second one below.

A token is not a token

Anthropic’s current lineup prices four tiers, and the shape is identical at every one of them. A model reads two kinds of input: fresh tokens it has never seen, and cached input, context it has already processed once and re-reads at a discount. Per million tokens: Haiku 4.5 charges $0.10 for cached input, $1 for fresh input, $5 for output. Sonnet 5 charges $0.30 / $3 / $15. Opus 5 charges $0.50 / $5 / $25. Fable 5 charges $1 / $10 / $50.¹ One wrinkle worth naming: until 31 August 2026, Sonnet 5 carries an introductory rate of $2 fresh and $10 out. I price everything at the standard rates, and so does the chart below.

Read across any row and the ratio is always 1 : 10 : 50. A cached input token, a fresh input token, and an output token differ in price by a factor of fifty, on every tier, from the cheapest model to the most expensive. That constancy matters. It means the 50× spread is a structural fact about how Anthropic prices inference, not a quirk you can shop your way around by switching tiers. Other vendors price the same three positions at different ratios, closer to 1 : 2 : 8 in some lineups. The ordering is universal; the exact spread is not. One more rate you’ll need later: writing content into the cache costs 1.25× the fresh-input rate at the default five-minute cache, so $3.75 per million on Sonnet (the one-hour cache tier writes at 2×). That becomes important the moment anything disturbs a cached prefix.

The consequence is immediate. Which tokens you’re buying matters more than how many. That is exactly the distinction most dashboards refuse to make.

Where the money actually went

Anthropic’s Claude Code documentation prints a real session summary, verbatim: claude-sonnet-4-6: 1.2k input, 5.3k output, 940.0k cache read, 50.0k cache write ($0.55).² Price those four lines at list rates and you get two completely different pictures of the same session, depending on whether you count tokens or dollars.

By volume, this session is a caching success story. 94% of everything the model processed came from cache at a 90% discount. By cost, the story inverts twice. Output, the code and prose the model actually wrote, is 0.5% of the tokens and 14.4% of the bill, roughly 27× over-represented relative to its volume. And cache writes are the silent line item: 5% of volume, 34% of cost, because every new tool result and assistant message has to be written into the cache at 1.25× the fresh rate before it can be read back cheaply.

Add it up and the input side of the ledger, reads plus writes plus the trickle of uncached tokens, is 85.6% of the bill. Caching is doing enormous work here. Run the identical session uncached and it costs $3.05 instead of $0.55, an 82% saving. But notice what that means. Caching is table stakes, not a strategy. It is the reason the bill is $0.55, and it is already on. Everything I write about from here is about the $0.55 that remains.

One housekeeping note, because it buys everything after it some credibility. My reconstruction of that session lands on $0.553 against Anthropic’s published $0.55. The cost model I use throughout reproduces a published figure to within rounding, and the full formula is in the appendix so you can run it against your own sessions.

If the shape looks extreme, it isn’t unusual. A study of eight frontier models on SWE-bench coding tasks measured input-to-output ratios above 150:1,⁴ and OpenRouter trajectory data from September 2025 put input at 99% of agent token traffic.⁵ Agents are overwhelmingly readers, and they read the same material over and over. Which raises the obvious question: why?

The re-reading tax

Because the API is stateless. Each request is a pure function: context in, response out, nothing retained. That is not my characterisation, it is Anthropic’s own: the Messages API is stateless, so you always send the full conversational history with every request.³ The conversation your agent appears to be having lives entirely on the client side, and the only way to continue it is to send the whole thing back on every single turn. System prompt, tool definitions, every tool result, every prior message.

Walk through six turns of a modest session. Say the fixed preamble (system prompt plus tool definitions plus your instruction file) is 12,000 tokens, and each turn adds about 3,000 tokens of tool results and assistant output to the context. Then the billed input per turn runs 12k, 15k, 18k, 21k, 24k, 27k. That is 117,000 input tokens billed to hold a six-turn conversation whose entire content is 27,000 tokens. Turn six re-buys turns one through five in full.

Nothing you say to an agent is said once. It is re-sent, and re-billed, on every subsequent turn. Prompt caching softens this, since the re-reads land at a 90% discount, but it doesn’t remove the mechanism, and each turn’s fresh additions must first be written to cache at a 25% premium. The tax is discounted, never waived.

Agent frameworks push back on this with sliding windows, tool-result pruning, and summarisation, and Claude Code compacts long histories automatically. All of these cap what gets re-sent, and they genuinely bend the curve back toward linear. None of them waive the mechanism. A summary is billed like any other input, compacting a large context is itself a large request,² and the long-context studies further down are the reliability price of deleting history. What they change is the amount carried per turn. The re-sending stays.

Why the curve bends

Extend that six-turn walkthrough and the arithmetic stops being a nuisance and becomes the whole story. Keep the same assumptions (12,000-token preamble, 3,000 tokens added per turn, 700 output tokens per turn, a 90% cache-hit rate, Sonnet at standard rates) and the bill grows like this.

Eight times the turns is forty-one times the billed input. If cost scaled with work done, an 80-turn session would cost eight times a 10-turn one. It costs about twenty-seven times as much, because the input side is the sum of an ever-growing context, a triangular number, quadratic in turn count, while output plods along linearly.

Two things fall out of this table. The first explains a puzzle in the literature. Published input-to-output ratios for agents are all over the map, from tens-to-one to hundreds-to-one. Look at the fourth column. The ratio isn’t a property of agents, it’s a property of session length, climbing from 26:1 at five turns to 186:1 at eighty. Studies disagree because they measured sessions of different lengths.

The second is the hierarchy I opened with, now derived rather than asserted. Turn count is the only variable that appears squared, so it’s the only tier-1 lever. Tokens-per-turn is linear but compounds forward across all remaining turns, so tier 2. Output is linear, small, and expensive per token, so tier 3. And the model multiplier scales the whole expression without changing its shape, tier 4, which is why “we switched to a cheaper model” so often disappoints. It discounts a curve that keeps bending.

Ship smaller

Here is the first genuinely actionable consequence, and it costs nothing to adopt. Take 80 turns of work. Done as one continuous session, it bills 10,440,000 input tokens and $6.79. Split into eight 10-turn sessions, same 80 turns, same work, it bills 2,040,000 tokens and $2.00.

Identical work, 5.1× less billed input, 3.4× cheaper, because every session boundary resets the quadratic to zero. The token figure is exact under any assumptions. The dollar figure is the model-sensitive one: price the same sessions with perfect caching and no expiries and the gap narrows to about 1.9× ($4.83 against $2.53), while every real cache miss re-bills the whole accumulated context at the write premium, which pushes the gap back up and hits long sessions hardest. Either way the direction survives. Scoping tasks smaller isn’t a discipline nicety. It’s the single cheapest optimisation available, and it’s a habit rather than a purchase.

There’s a quality argument riding alongside the accounting one, and it’s rare that both point the same way. Research on long-context behaviour keeps finding the same shape. An Anthropic Fellows study had frontier models read long agent transcripts as safety monitors, and the monitors missed subtly dangerous actions 2× to 30× more often when those actions sat after 800,000 tokens of benign context than in isolation, with recall on one attack pattern falling from 99.7% at 100K tokens to 69% at 800K.⁶ That measures a model reading a long session, not the agent running one. Chroma’s context-rot study measures the model doing its own work as input grows, and it found all eighteen frontier models it tested degrading at every increment, not just near the window limit.⁷ Long sessions are simultaneously more expensive per unit of work and less reliable per decision. Smaller scope is cheaper and safer. Close the session at the task boundary and start the next one clean.

What this part didn’t price

Everything above prices attempts, meaning tokens burned per session. But nobody buys attempts. They buy merged, working changes, and the moment you divide cost by success rate the picture rearranges dramatically. The next part gets into a controlled experiment that ran nine models under one fixed harness on 350 real GitHub issues.⁸ Price its trajectories at identical token rates and the strongest model comes out cheapest per resolved issue at $0.74, while the weakest costs $3.49 and resolves 28.5 points fewer. Cheap models, it turns out, don’t save you tokens. They save you money per token, and then spend more of them.

The tier table stands until then. Cut turns first, cut what enters context second, cut output third, and only then argue about models.

Appendix: run it with your own numbers

The model behind every figure above, small enough to check on a napkin:

Defaults used throughout: S = 12,000 · A = 3,000 · o = 700 · h = 0.9 · Sonnet 5 at $3/$15. Disagree with any assumption, and you should, because they’re yours to measure. The formula recomputes in a spreadsheet cell. Your preamble is visible with /context, your session totals with /usage.