Why your assistant re-reads everything, and what it costs

Open the token breakdown of almost any Claude Code session and the largest number by a wide margin is cache reads — the context the model has already been sent, replayed on every turn. On the sessions behind this article, cache reads ran to billions of tokens against tens of millions of output. That ratio is not a bug. It is what a conversation with a large context window looks like.

What the ratio actually tells you

A high cache-read share is the healthy case: the provider is serving context from cache at a fraction of the input price instead of charging you full rate to re-read the same files. What is worth noticing is the opposite — a session where fresh input stays high relative to cache reads. That usually means the context is being rebuilt rather than reused.

Three things commonly cause it:

• Starting a new conversation for each task. A fresh session has no cache to hit. Two related tasks in one conversation cost far less than the same two split apart.
• Changing the early part of the context. Caches are prefix-based: editing something near the start invalidates everything after it. Adding to the end is cheap, rewriting the beginning is not.
• Long gaps. Cache entries expire. A conversation resumed the next morning pays to re-establish what it had.

What it does not tell you

It says nothing about whether the work was good, and it is not a productivity number. A session that solved a hard problem in one expensive turn is better value than five cheap ones that did not. Read it the way you would read a query plan: useful when something feels slower or costlier than it should, meaningless as a target.

The one habit worth changing

If you take one thing from this: keep related work in one conversation, and add context at the end rather than editing the start. That single change moves the ratio more than anything else on this list, and it costs nothing to try.