Token counters tell you how much you spent. I wanted a different number: how much of what I paid for was new text the model actually produced.
So I measured it against a complete local log corpus of my own agentic coding work: 722 sessions, 150,902 model calls, 34.56 billion tokens.
By tokens billed:
| Token class | Share of all tokens |
|---|---|
| Cache read (re-reading context) | 97.05% |
| Cache write (storing context) | 2.57% |
| Output (generation) | 0.38% |
| Fresh input | 0.01% |
For every token the models produced, roughly 256 tokens of cached context were read back in.
Cache pricing softens that ratio, but not the conclusion. Under published per-token list rates:
| Category | Share of cost |
|---|---|
| Re-reading context | 55.89% |
| Writing context to cache | 31.89% |
| Generating new text | 12.18% |
| Fresh input | 0.04% |
Context handling 87.8%, generation 12.2%. Re-reading context alone costs 4.59x as much as everything the models wrote. And cache writing is not a rounding error: at 31.89% it is the second-largest line, larger than generation. Caching does not make context free, it moves part of the price to the moment state is stored.
Why it looks like this
An agent doesn't send a fresh question on every step. It sends the whole conversation so far: instructions, every file it read, every command it ran. Then it adds one step and sends everything again. A token that enters the context on step 1 of a 60-step run is paid for 60 times.
I put a number on that with a derived measure, input amplification: total input tokens billed in a session, divided by that session's peak context size. Across the 590 sessions with at least three model calls, the median is 23.7x, the 90th percentile 124.5x, the maximum 4,182x.
The median session pays for its peak working state about 24 times. One session in ten pays for it more than 125 times. A session's cost is not mainly set by how big its context is, nor by how much it writes, but by the product of context size and how many times that context gets traversed.
Cost is also concentrated: an estimated 80% of the corpus total falls on 21 of 722 sessions (2.9%), and sessions longer than 200 model calls - 8% of sessions - account for an estimated 92.8% of spend.
The part you can actually change
None of the above is a knob. How often you clear the context is.
I ran a controlled comparison: twelve fixed programming tasks under six context-clearing policies - a fresh session every 1, 2, 3, 4, 6 and 12 tasks - six replicates each, with the model, the tasks and their order held constant. 36 runs.
| Clear after every | Mean modeled cost per run |
|---|---|
| 1 task | $2.165 |
| 2 tasks | $1.854 |
| 3 tasks | $1.622 |
| 4 tasks | $1.704 |
| 6 tasks | $1.679 |
| 12 tasks (never) | $1.780 |
Cost is not monotone in session length. It falls, bottoms out at three tasks, then rises again.
- Clearing after every task costs 33.5% more than clearing every third (p = 0.0022, Holm-adjusted 0.011).
- Every second task: +14.3% (p = 0.0022, Holm 0.011).
- Going from clearing every task to every third cuts cost by 25.1%.
The reason the constant-clearing end is expensive: a cache write costs 20x a cache read. Clear after every task and you keep paying to rebuild state you just threw away. At the optimum the spend splits 39.0% cache read, 32.3% cache write, 28.7% output.
Two things I want to state plainly rather than round off:
The middle is a plateau, not a point. Every fourth task is +5.1% against every third (p = 0.17), every sixth +3.5% (p = 0.45). The data cannot separate 3 from 4 or 6. "Clear every few tasks" is the finding; "clear every third" is just where the observed minimum landed.
Never clearing is not significantly worse. It comes out +9.7% against every third, p = 0.046, Holm-adjusted 0.14. An earlier version of this work claimed both extremes were significantly more expensive than the optimum. That claim is withdrawn for never clearing.
Measuring it yourself
I packaged the measurement as a small open-source tool, contextburn. It reads the transcripts your agent already writes on your machine and makes no network calls.
pip install contextburn
contextburn detail 24
It also runs as an MCP server, so the agent can check its own efficiency mid-session:
claude mcp add contextburn -- uvx contextburn mcp
Two traps, in case you write your own counter
1. Streaming logs record the same model call more than once. An early snapshot and a final record share one message id. Count both and you double the call; keep only the first and you halve the output. Take the element-wise maximum per message id.
2. Prices change the answer, and they will change yours. Both datasets behind this post were re-published with corrected costs, and the errors were mine. Cache reads had been priced at a rate that applies only to a newer model, and every cache write had been priced at the 5-minute rate when the logs show mostly 1-hour writes, billed at 2x input rather than 1.25x. Token counts, call counts and the composition table did not move at all. Every dollar figure did: the corpus split went from 83.5% / 16.5% to the 87.8% / 12.2% above. If you report a cost-weighted share, it is only as current as your price table - and worth re-deriving before you quote it anywhere.
Limits
This is a single-practitioner case study, not a sample of a population, and the dollar figures are a model applied to logs rather than an invoice.
Cache-write duration cannot be verified for part of one machine's logs. If every write were instead a 5-minute write, the corpus split would be 86.2% / 13.8% - the direction holds under every assumption I can test, only the size moves.
In the controlled runs, "no test failures" means tests the agent wrote itself, and the count differed by condition: 116.8 tests per run on average when clearing after every task, 106.8 when never clearing. The three-task reference condition was selected after the fact, as the observed minimum.
I'd like to see the same measurement run against other people's logs.
The data
Report, datasets and recomputation scripts are public:
- Corpus report and dataset: 10.5281/zenodo.22759216
- Peer-reviewed report: 10.32388/0BV3Z8
- Context-clearing experiment, 36 runs: 10.5281/zenodo.22759217
Evgenii Arsentev, PhD - Chief Executive Officer. I measure how AI agents spend money, and publish the data and the scripts. More at arsentev.ai.
Top comments (1)
The plateau is more actionable than the minimum. A fixed clear-every-three rule will break as task size and tool output change, but the mechanism suggests a measurable trigger: compact when expected future reread cost exceeds the cost of rebuilding a smaller state packet. The packet should preserve decisions, unresolved constraints, and artifact identifiers while dropping raw successful tool traces. I would also separate cache economics from latency, because the cheapest policy may still be the wrong one for interactive work.