97% of what my coding agent billed for was re-reading its own context

Evgenii Arsentev — Wed, 16 Sep 2026 07:11:32 +0000

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.