I kept hitting session limits without understanding what was eating them, so I stopped guessing and measured my own logs. Across 637 sessions and 34,215 API calls: context re-read (cache read): 98.5% of all billed tokens cache writes: 1.2% what the model actually wrote (output): 0.3% fresh input: rounds to 0.0% That is 360 tokens re-read for every token written. The per-session median is 97.6%, p10 91.2%, p90 99.1%. Nine sessions in ten sit above 91%, so this holds across the distribution rather than coming from a few huge outliers. One caveat before anyone raises it: cache reads are billed at a fraction of input tokens, so these percentages are tokens, not money. Weighted by relative price, re-read context comes to 77.3% of the cost. Two things I did not expect. The model’s own output is 0.3% of the total. What makes a long turn expensive is carrying the conversation forward, one call at a time, and that cost keeps growing while the answer stays the same size. The second is that measuring this is easy to get wrong. The usage block is repeated identically on every line of the same API call, once per content block. In my corpus that is 1.69 lines per call, so summing per line overcounts by 69%. Deduplicate by requestId. What I do not know, and would like to hear from you: whether the subscription rate limits count tokens the same way, because nothing on disk says so. If you have hit the 5 hour wall while running long sessions with lots of subagents, does this match what you see? (I measured it with a tool I wrote for myself to watch what a session is doing. It is open source and reads the logs Claude Code already writes: github.com/duqaXxX/seedeep. The numbers above are reproducible without it, the logs are in ~/.claude/projects.) submitted by /u/duqaxxx
Originally posted by u/duqaxxx on r/ClaudeCode