The session isn't doing more work. The invoice says otherwise.
Nothing about turn 40 feels ten times heavier than turn 4 — same kind of edit, same size of file, same one-line request. But the bill doesn’t track how the work feels; it tracks how much gets re-sent. A developer watching their own usage after leaning on compaction to manage a long session put it plainly:
“Compaction wont save you, in fact calling compaction will eat about 3-5x the cold cache cost in usage ive found.” That number is specific to compaction’s double cache-miss, but the underlying feeling is universal: the session doesn’t feel exponential. The bill does.
Turn N doesn't cost N. It costs the sum of everything up to N.
A transformer’s self-attention compute scales with the square of sequence length — a well-known property of the architecture, not a Claude-specific detail. In practice this surfaces one layer up: a stateless model retains nothing between calls, so an agent loop that wants continuity has to re-serialize the accumulated transcript into every request. Turn 1 sends the first step. Turn 2 sends steps one and two. Turn N sends all N.
Add that up and the total isn’t N steps of cost — it’s the triangular number N(N+1)/2. A 20-step loop at roughly 1,000 tokens per step doesn’t cost the 1,000 × 20 = 20,000 tokens a linear estimate suggests. It costs 1,000 × (20 × 21 / 2) = 210,000 cumulative input tokens — because every one of those 20 calls re-sent everything before it.
| Turn number | Tokens re-sent (1,000 tok/turn, full history each call) |
|---|---|
| turn 5 | this turn: 5,000 · running total: 15,000 |
| turn 10 | this turn: 10,000 · running total: 55,000 |
| turn 20 | this turn: 20,000 · running total: 210,000 |
| turn 50 | this turn: 50,000 · running total: 1,275,000 |
Read the two columns separately and the trap becomes obvious. What a single turn costs grows in a straight line with turn number — turn 50 sends exactly 10× what turn 5 sends. What you’ve paid in totalby that point doesn’t: cumulative spend through turn 50 is 85×cumulative spend through turn 5, not 10×, because every prior turn keeps getting re-billed alongside the new one.
The obvious responses, and where each one stops.
Just stop resending full history.Not actually available — a stateless model has nothing to reason from between calls except what the request contains. This isn’t a workaround to consider; it’s the constraint that produces the whole problem.
Compact more often. Repeated summarization re-summarizes repeatedly, which costs more, not less — and each compaction is a cache miss on the pre-compact history anda fresh cache miss on the newly written summary, which is exactly the 3–5× cold-cache penalty quoted above.
Truncate old turns by hand.This shrinks token volume the same way compaction does, but with no summary left in place of what’s dropped — it’s the same lossy trade as compaction, done manually and without even a recap.
Turn on prompt caching and stop thinking about it. Real savings, bounded ones — see the next section for the arithmetic.
Caching divides the coefficient. It doesn't remove the exponent.
Anthropic’s prompt cache is real and worth using: a cache write costs 1.25× the base input price on a 5-minute cache or 2× on a 1-hour cache, and a cache read — a hit on an already-cached, byte-identical prefix — costs just 0.1× the base input price, a 90% discount (Anthropic, prompt caching docs). Run the same 50-turn, 1,000-tokens-per-step loop from the table above through those rates — new content written to cache each turn, the growing prefix read from it — and cumulative spend through turn 50 drops from 1,275,000 fresh-input-token-equivalent units to roughly 185,000: about 7× cheaper.
It is still growing faster than linearly. The quadratic term doesn’t disappear — its coefficient shrinks by almost exactly the cache-read discount, ten. That tracks: the part of the bill that was quadratic is the repeated read of a growing prefix, and a 90%-cheaper read is a 90%-cheaper quadratic term, not a linear one.
The discount also has a sharp edge. The cache match is exact — Anthropic’s docs specify “100% identical prompt segments” up to the cache-control marker, and a change earlier in the prompt invalidates the cache for everything that follows it (same page). One edited line upstream of the breakpoint, and the next call pays fresh-input price for the whole prefix again. Non-product options that help without touching pricing: batching independent subtasks into separate short sessions instead of one long one caps how large N gets in the first place, and putting static content (tool definitions, system prompt) ahead of anything that changes turn to turn keeps the cache breakpoint stable longer.
What one long session actually spent, measured, not modeled.
The numbers above are worked examples. This one is a real session: our own production telemetry, not a benchmark and not an extrapolation. It’s the number we can stand behind against the “5.5×” and “98.5%” figures that circulate without a published methodology — ours comes with the raw counters attached.
A single Claude session ran 11,232 turns. Averaged across the whole run, each turn sent about 116 tokens of genuinely new input against roughly 445,621 tokens read from cache — a 99.97% hit rate — at an average cost of $0.181 per turn. The growing-transcript problem above never applied, because the full transcript was never what got re-sent.
| What was measured | The number |
|---|---|
| turns in the session | 11,232 |
| fresh input, average per turn | ≈ 116 tokens |
| cache read, average per turn | ≈ 445,621 tokens (99.97% hit) |
| cost, average per turn | $0.181 |
| where it's from | Vinculum production telemetry, 2026-06-09 — one live session, measured, not a benchmark |
Turn 11,000 cost about what turn 100 did — because nothing was being resent.
The gap between the worked math and the receipt above is the whole point. In the full-resend model, cumulative cost through turn 50 runs 85× cumulative cost through turn 5 even with caching applied. In the measured session, 116 fresh tokens per turn held as an average across all 11,232 turns — turn 11,000 wasn’t materially more expensive than turn 100, because the model was never being asked to re-read a transcript that had grown eleven thousand turns long.
A substrategets there by keeping decisions as typed, addressable records outside the conversation and handing the model a compact briefing instead of the accumulated transcript. The context sent per turn stops scaling with how long the project has run, so there’s no growing prefix to re-read — cached or not — and no N(N+1)/2 curve underneath the bill in the first place.
Common questions.
Does prompt caching fix the quadratic cost?
It discounts it — it doesn’t remove it. Anthropic’s cache read price is 0.1× the base input rate, which divides the quadratic term’s coefficient by roughly ten. The bill still grows faster than linearly with turn count, just along a flatter curve. See the longer treatment for where the discount stops helping.
Are the "5.5x" and "98.5%" numbers people cite accurate?
We can’t verify them — they circulate without a published methodology, so we don’t repeat them as fact. What we can stand behind is our own production telemetry, cited with the raw counters in the receipt below, because it’s a real session we can point to rather than a number someone quoted.
Is this specific to Claude?
No. Self-attention’s compute cost scaling with the square of sequence length is a property of the transformer architecture generally, and re-serializing a growing transcript on every call is a pattern in agentic tool use broadly, not a quirk of one vendor’s API. The pricing figures cited here are Anthropic’s published rates; the shape of the problem is the same wherever a stateless model is called in a loop.