In a Long Claude Code Session, Cache Rent, Effort Levels, and Routing Determine Where the Tokens Actually Go

If you use Claude Code, Cursor, or any long-running AI coding agent, you probably assume most of your bill goes to the model thinking hard. A recent analysis suggests the opposite: the overwhelming majority of spend goes to the agent rereading its own conversation history on every single turn. Here is what that means for your budget, and how to measure it yourself.

What one measured session actually showed

Itai Spector published an analysis of a real Claude Code session — about 92 minutes long, running on Opus 5.5. The headline finding: roughly 82% of the session's cost went to context rereading, while only about 9.5% went to reasoning tokens. The remaining 8.5% covered everything else and was not broken down further.

Those figures come from the author's own measurements, not independent verification. I could only see the public preview of the article, so treat all of these numbers as reported rather than confirmed.

The same analysis compared two setups on a similar kind of session. A router that picked a model per turn cost $1.70. Simply leaving the big model on high effort cost $1.94. The difference was $0.24, about 12%. That is a real saving, but it is not the dramatic reduction that router demos often imply.

One session, one author, and two runs that almost certainly did not follow the identical sequence of turns — an agent never takes the same path twice. The 12% figure should not be treated as a fixed rule. The 82% figure, though, matches how the underlying mechanism works.

Why rereading dominates the bill

Every turn of an agent session resends the entire conversation: the system prompt, tool definitions, every earlier message, and every tool result. The model itself has no memory between calls. The harness does the remembering by resending everything.

Prompt caching makes that resend cheaper, not free. Writing a prefix into the cache costs a bit more than normal input. Reading a cached prefix costs a small fraction of normal input. The default cache lives for about five minutes, with a longer option available at higher cost.

In a busy session, most input gets billed at the cheap cache-read rate. But a small fraction multiplied by a 150K-token prefix multiplied by a hundred turns is still the largest number on the invoice. Thinking happens once per turn on new tokens. Rereading happens every turn on everything.

Then there is the cold turn. Step away for seven minutes, come back, type one line, and the cache has expired. That single line drags the entire prefix back in at the write rate. It is invisible unless you log usage per turn, because the interface does not warn you that this turn cost many times the last one.

What effort levels actually change

Anthropic's own guidance on effort levels comes down to two points: use lower effort for building and higher effort for verifying, and the highest effort setting costs roughly three times the tokens per attempt compared to the low end.

That advice looks different once you know thinking is under 10% of spend. Effort mostly moves the thinking slice. Even tripling it on every turn is not what blows up a bill. The number of turns is what blows up a bill, because every extra turn pays the reread again.

If low effort means the agent takes three attempts where high effort would have taken one, you saved on thinking and paid for two extra full rereads of the context. On a long session with a fat prefix, that trade can easily go the wrong way. This may be part of why simply setting high effort landed so close to the router in the comparison: fewer wasted turns can be worth more than cheaper tokens per turn.

A reasonable working rule: build low when the task is mechanical and retries are unlikely. Verify high, because a verification that misses something costs a whole extra cycle later.

The cache problem routers do not mention

Reported Haiku 5.5 pricing was $0.10 per million input tokens and $0.50 per million output tokens, for prompts up to 100K tokens. Long agent contexts can cross that 100K boundary, and tiered pricing is easy to overlook.

At those prices, routing easy work to Haiku is tempting. The catch: the cache belongs to a model. When a router flips a turn from Opus to Haiku, Haiku cannot read Opus's cached prefix. Flip back and forth, and each switch can mean a cold prefix on the model you switched to. In a session where 82% of spend is rereading, a router that keeps breaking cache continuity is fighting the biggest cost with the smallest lever.

The advisor pattern flips the structure. Instead of one model per turn, a cheap model does the work and an expensive model is consulted occasionally as an advisor. What makes this attractive is not that the advisor is cheap — it is that the advisor sees a short context: the task and the proposed change, not the whole 92-minute history. You pay Opus prices on a few thousand tokens instead of Opus cache rent on the full transcript.

Measuring your own sessions

I built a small C# harness called TokenRent to check these claims against real usage. It reuses an idea from a Ranknod article on C# Corner about token budgets in .NET: reserve an allowance before each model call, settle it with real usage afterward, and if a call may have happened but no usage report comes back, keep the reservation held and halt further admissions. Not knowing what you spent is treated as a reason to stop, not as zero.

The harness extends that philosophy: a model with no known price also halts the cost report. An error is better than a confident total that silently priced half the turns at zero.

It has four modes:

• transcript: read a Claude Code session log and break spend down per turn, separating cache-warm and cache-cold turns.
• probe-api: send the same long prefix three times to the Anthropic API (cold, warm, then after waiting past the TTL) and print what each call cost.
• probe-ollama: the same probe against a local Ollama model, for the cheap tier.
• advisor: run one task two ways — Opus alone with full context, or a cheap executor (Haiku or a local Ollama model) with Opus reviewing only the task and the result.

Setup requires no NuGet packages; everything is in the base class library. For the local tier, pull a model like qwen2.5-coder:7b through Ollama, either installed directly or run in Docker.

Create a prices.json next to the project. The Haiku line uses the reported numbers above. Add the Opus line yourself from the current pricing page — the harness refuses to run on a model it has no price for, which is the point. Cache multipliers default to 1.25x for writes and 0.10x for reads; verify these against current documentation and override per model if they differ.

What this means for your bill

The practical takeaway is not "switch to a cheaper model" or "turn effort down." It is that turn count and cache continuity matter more than per-token rates in long agent sessions. Fewer turns with a warm cache will usually beat more turns with cheaper tokens.

If you want to check any of this against your own usage, the harness is a starting point. The numbers reported by Spector are his, not verified by me, and your sessions will differ. But the mechanism — resending growing context on every turn — is the same for everyone, and it is worth seeing in your own logs before you build a budget on someone else's percentages.