Home / Context and cost

Where the bill really comes from, and why a token count lies

The real cost of a session rarely hides where you look for it: a token count often confuses a reread at cache rate with a first read at full rate, a handful of marathon sessions carry most of the bill because the entire history is reread on every tool call, and any file loaded automatically at startup is paid for in full again at every compaction, not just once at the start.

A Claude Code session open since the morning, which by the end of the day only asks a final question that fits in one sentence, still bills for much more than that sentence. The reason lies in a specific mechanism: every tool call sends Claude a new request carrying the complete conversation history, and that history is reread every time, at the cache's reduced rate but never for free.

What the cache lowers, and what it does not remove

The cache lowers the price of the reread, it does not cancel it. A session that runs through several dozen tool calls therefore pays for the same portion of history several dozen times, at a lower rate than the first read, but added up over the whole day. Here is a calculation with figures chosen for the exercise, which you can reproduce with your own:

History before a tool call: 40,000 tokens
Five tool calls within the same session
Total tokens reread: 40,000 x 5 = 200,000 tokens reread at the cache rate

The same calculation explains why a session left open all day can weigh more heavily in a bill than several short sessions covering the same volume of work: it is not the volume of work that costs, it is the number of times the accumulated history is sent back.

What reloads in full at every compaction

A project's instructions file and automatic memory load once at session startup, then stay frozen. Only three events cause them to be reread in full from disk: compacting the conversation, clearing it, or restarting the session. This reload runs at the cache rate as long as CLAUDE.md and memory have not changed since the start of the session, and only falls to the full rate if they were modified in the meantime. A compaction triggered mid-session, with the cache still warm, therefore costs a fraction of what the context size would suggest; it is mainly compacting an old session, resumed after a long pause where the cache has expired, that really costs. The difference between compacting and clearing therefore matters as much for cost as for task continuity.

A count that confuses a cached reread with a first read at full rate gives a false impression of the bill: two lines carrying the same number of tokens can cost ten times more one than the other depending on whether they come from a first read or a cached reread. The detail of this cache rate is covered in the lesson on the cache and the Batch API. Before judging a cost to be high, two separate questions therefore need to be told apart: how many tokens were processed, and at what rate each one was billed.