← Back to UsageCut

Claude Code prompt caching and compaction, explained simply

Two things confuse almost everyone reading a Claude Code bill: why "cache read" is the biggest line, and why the session keeps compacting. They are the same story told from two ends. Here it is, plainly.

How prompt caching works

A conversation with Claude Code is stateless under the hood: to continue, the entire thread so far is sent again on every turn. Resending the full history from scratch each time would be slow and expensive, so the stable front part of the conversation - the prefix - is cached.

  • Cache write happens once, when new content first enters the prefix. It is the most expensive per token - about 38% of dollar cost from just 4.9% of tokens in measured usage.
  • Cache read happens on every later turn that reuses that prefix. Cheap per token, but it happens constantly - 93.9% of all billed tokens and 44% of cost.

That is the whole reason cache read dominates: not because you send a lot, but because whatever is in context gets read back on every single turn for the rest of the session.

Why context fills

The window has a fixed size. It fills with everything that enters and does not leave: file reads, tool output, the growing conversation, the always-on CLAUDE.md, and every connected MCP server's tool schemas. The heaviest contributor is usually exploratory reading - files you looked at once to orient, that then sit in context for the rest of the session.

Why compaction triggers

When the window gets close to full, Claude Code compacts: it summarizes older turns to reclaim space. It is a safety valve, not a failure - but frequent compaction is a signal that context is filling faster than the task needs, and each compaction risks dropping detail you cared about.

What actually reduces it

Since the cost is "what is in context, times every turn," the winning move is to keep less in context: offload exploration to subagents so only summaries stay, slim the always-on header, drop MCP servers you never call, and let a lossless trimmer collapse bulky output. The full playbook is in how to reduce Claude Code's context window usage; if you just want to know why your sessions run out of context, start there.

The figures here are measured across 1,037 real sessions, deduped by message id. Savings estimates elsewhere on this site are shown as floor-to-ceiling ranges and labeled measured or estimated - never a single guaranteed number.

See your own numbers

These are aggregates from real sessions. Your setup is different - run the free scan and get the breakdown for your own Claude Code history. It runs locally; nothing about your code or prompts leaves your machine.

npx usagecutRun a free scan →

NeoMade by Neo

UsageCut by ClockedCode - not affiliated with Anthropic. The figures on this page are measured on real Claude Code sessions and labeled measured or estimated where it matters.