tokenstat
homepricingstatshelpsign in
tokenstat
Reading your usage

Why cache reads dominate your token count

György
Reviewed by
György
Updated Jul 30, 2026 3 min

The first time you look at a tokenstat report, one number tends to stop you: billions of tokens, when you have had maybe a few hundred conversations. The explanation is not a bug, and it is the single most useful thing to understand about what AI coding tools actually cost.

Four counters, not one

Every request an AI coding tool makes is recorded as four separate numbers:

Counter What it is
Fresh input Text the model has not seen before and must read in full
Output What the model generates back
Cache write Context being stored so the next request does not have to re-read it
Cache read Context served from that store instead of being read again

A long agent session re-sends its accumulated context on every single turn. Without caching that would be ruinous, so the vendors cache it: the first turn pays a cache write, and every turn after that pays a much cheaper cache read for the same material.

That is why cache reads dominate. On a typical machine they are the large majority of every token counted, and it is entirely normal for them to be well over 90% of the total.

The number that matters is not the token count

Here is the part that changes how you read a report. Cache reads are billed at a small fraction of fresh input, so they dominate the token column and barely register in the money column.

Which means a raw token total, on its own, tells you almost nothing about cost. Two people with the same billions-of-tokens headline can be an order of magnitude apart on what that work was worth, depending entirely on the split.

This is what tokenstat shows you that a single big number cannot:

tokenstat summary

Read the split, not the total.

What this means in practice

A big context is not the expense people assume. The common worry is that a long conversation costs proportionally more because the whole history is re-sent. It is re-sent, but mostly as cache reads. The real costs of a very long session are different ones: cache-miss spikes when the cache expires or the context shifts, latency, and the quality drop as the model's attention spreads across a window full of things that stopped being relevant.

Cache misses are worth noticing. When a session goes cold, the next request re-reads the context as fresh input at full price. A workflow that keeps restarting sessions pays that repeatedly.

"Would this have been cheaper without cache?" is a real question with a real answer. tokenstat computes what the same work would have listed at with no cache at all. The gap is usually large, and it is the clearest illustration of what the cache is doing for you.

Every money figure here is usage measured at list rates, whether or not any of it was billed. If a subscription covered the work, tokenstat marks it as plan-covered and keeps it out of the charged column. The point of showing list value is the scale of the work, not what anybody was charged.