Claude Code token usage: you pay for the whole conversation again on every turn

I measured three real Claude Code sessions. For every new token I gave it, it re-read between 16 and 61 tokens of history. That, not the model, is what your session costs.

Every turn re-sends the whole conversation: the bars grow turn by turn, the history is read back from cache at 0.1x and only the new part is prefilled at full price; on a real session, 61x more history re-read than new tokens

TL;DR Nothing gets sent once. Everything that lands in the conversation goes out again on every turn the session has left, so turn 40 is paying for the 39 turns in front of it. Session length costs you more than your model choice does, which is why /clear between tasks beats every other setting.

You check /usage, half your window is gone and you have not done much, and the first suspect is always the model. It almost never is.

What you spend is a multiplication of two things, and only one of them is about the model:

What a token costs. Which model processes it, whether it goes in or comes out, and whether it was cached.
How many tokens you send. What ends up in the context, how many turns it stays there, and how many contexts you have running at once.

You pick the first one once and forget it. The second one grows on its own while you work.

Nothing gets sent once

The model remembers nothing between turns. Every request carries the whole conversation, and Claude Code appends whatever is new to the end of it.

You type "fix the failing test in utils.test.ts". That is not one request, it is five:

1  system prompt + CLAUDE.md + your message     → asks to read the test
2  all of the above + the test                  → asks for the file under test
3  all of the above + the second file           → proposes an Edit
4  all of the above + the applied Edit          → runs npm test
5  all of the above + the test output           → answers and stops

Five requests for one small fix, and every one of them carried the entire conversation up to that point. The file it read in request 2 travels again in 3, in 4 and in 5. And on turn 40, if the session gets that far.

The cache is what makes this survivable: the history being re-sent is read back at 10% of the input price. Ten percent, not free. Multiply that by every turn still to come and it stops being a small number. What breaks that cache and what leaves it alone is prompt caching in Claude Code, and I am not repeating it here.

I measured three real sessions

Claude Code records every request, token counters included, in the session's .jsonl file. You can add it up:

jq -s '[.[] | .message | select(.usage)] | unique_by(.id) | map(.usage) | {
  requests: length,
  new:      (map(.input_tokens + .cache_creation_input_tokens) | add),
  history:  (map(.cache_read_input_tokens) | add),
  output:   (map(.output_tokens) | add)
} | . + {per_new_token: (.history / .new | floor)}' \
  ~/.claude/projects/<your-project>/<session>.jsonl

The unique_by(.id) matters: the same response shows up more than once in the file, and without it you count everything twice.

Three of my own sessions from this week:

session             requests   new tokens   history re-read   ratio
A, ten days            1,378        5.9 M            357 M     61x
B, one long day          630       10.5 M            171 M     16x
C, one morning            87        0.37 M           14.3 M    39x

For every new token I gave it, it re-read between 16 and 61 tokens of history. That ratio holds whatever anything costs, because it is raw token counts.

Priced out, with cache reads at 0.1x, cache writes at 2x and output at 5x, re-reading the history came to 65%, 39% and 54% of each bill. In two of the three sessions it cost more than everything else put together: more than the new files, more than the model's own answers, more than any call I made about which model to run.

What a token costs

Token type	Price	When you pay it
New input	1x	Whatever you add this turn
Cache read	0.1x	The history, on every turn
Cache write	1.25x on a 5-minute TTL, 2x on the one-hour TTL	Once per token
Output	~5x	The answer, the tool calls and the thinking

Two things here are not obvious. Output runs about five times the price of input, because it is produced one token at a time and each one holds the GPU far longer than reading does. A 200-token answer is 200 passes through the model. That is half the reason your effort level moves the needle so much: thinking is output.

The other one is the shape of the cache. You pay to write a token in once, and you collect the 10% read on every turn after that. On a subscription the TTL is an hour, so the write lands at 2x. Call it the entry fee on a history you are about to re-read a few hundred times.

Where to look, in the order that matters

Anthropic publishes its own ranking of the four things worth watching, sorted by what they cost. The order is the interesting part:

1. Long sessions. "Every turn re-sends everything before it, so this is where most of a session's tokens go." The same curve that makes Claude get worse the longer a session runs, seen from the bill instead. And having a million tokens of window does not fix this, it gives it more room.

2. Too much in the context. Files it did not need, verbose command output, leftovers from the last task, MCP servers you are not using. All of it goes out again every turn, and the model has to think around it too. Some of it is in there before you type anything, and each feature loads at a different moment, the plugins you never use included. On the part you add yourself, this is where the five ways to give context, keeping five MCP servers and a quiet flag on anything that prints too much do their work.

3. A model or effort level above what the task needs. It multiplies everything else, and both settings carry over from one session into the next. Which one to run when.

4. Breaking the prompt cache. Switching model, effort or fast mode mid-conversation, or coming back after it has expired.

Look at where the cache landed. Last. Session length outranks your model and outranks a cache bust, and it is the hardest one to see: /usage tells you how much you have burned through, but no command breaks out how much of that was history being re-read. For that you have to go into the .jsonl.

A subagent is an economic move, not just an isolation one

A subagent starts with a context of its own: its own system prompt, the tools and your CLAUDE.md, but not your conversation. It runs its own turns, and the only thing that reaches your session is its answer. The rest is thrown away.

The catch is that it sometimes re-reads things your session already had, paying for its own turns while it does. On a small job that is pure overhead. It pays off when the job produces output you have no reason to keep: reading through a log, working over a whole test suite. What you save is not that one turn, it is every turn afterwards that no longer carries the output.

If you hand off the same job over and over, give it a definition with model: haiku. Otherwise it runs on whatever your main session runs on. And remember your session only ever gets what the subagent chose to report.

What to do with this

Before you start the next task, /clear instead of carrying on in the session you already have open. It is a command, not a setting, and by Anthropic's own ranking it beats any decision you make about the model.

The rest of the habits, with the recipe for each, are in how to save tokens in Claude Code. This tip is the why behind those ten.

Official docs: Maximizing the value of your Claude Code sessions · Prompt caching