From 11,700 Tokens to 650: Why Caching Isn't the Win, Keeping Your Prefix Stable Is

Every time I open a Claude Code session, a hook quietly pastes my project handoff file into the context before I type a word. Useful, because the agent knows where the project stands. Expensive, because that file had grown to 11,700 tokens, and it loaded on every session, including the ones where I only wanted to fix a typo.

So I did the boring thing and measured it. I parsed my actual Claude Code transcripts, which record exact token usage on every turn, and ran the numbers. The result surprised me twice. Once because the savings looked huge. And again when I realized the headline number was crediting the platform, not my setup. This post walks through the whole thing: how the billing works, what the data said, where the savings really come from, and the one change that cut my per-session overhead by 94 percent.

First, how Claude Code actually bills tokens

There are three prices for an input token, and the gap between them is the entire story. Using Claude Opus 4.8 list pricing of 5 dollars per million input tokens:

• Fresh input, billed in full: 5.00 dollars per million.
• Cache write, a one-time premium to put something in the cache: 6.25 dollars per million, which is 1.25 times.
• Cache read, when that same content shows up again: 0.50 dollars per million, which is one tenth.

Output tokens, for reference, are 25 dollars per million, five times the input rate. The takeaway is simple: a cached token costs one tenth of a fresh one. That 10x gap is the lever everything in this post pulls on.

The price of one input token, by state (USD per million)

The measurement: 14 sessions, 6,352 turns

I pointed a small script at my transcript folder and summed the usage on every assistant turn. No estimates, no sampling, the actual billed tokens. Here is what came back across 14 sessions and 6,352 turns:

Metric	Value	Confidence
Cache hit rate (input served from cache)	97.9%	Measured
Cache savings vs full price	~$9,850	Measured
Actual spend	~$1,760	Measured
Cost with no caching at all	~$11,420	Estimated
Sub-agent offload	0	Measured

What it cost vs what it would cost with no caching

The myth I almost published

The easy story is "my handoff and memory architecture saved me roughly 9,000 dollars." It is wrong, and the reason matters.

Caching is automatic, and it is a platform feature. Inside one session, every turn re-sends the whole conversation so far. Claude Code caches that growing prefix on its own. Long conversations naturally hit 97 or 98 percent cache rates whether or not you have a single good context file. The platform does that. I do not get to claim it.

So what does the architecture actually earn? One narrow but real thing.

Picture the opposite. Suppose my handoff file started with a live clock that read "Last updated 2026-06-28 14:32:07." That string sits at the very front of the context and changes on every request. Every turn, the entire prefix after it is invalidated and re-billed fresh. At a 200,000-token context that is the difference between the cache-read rate and the full rate:

That is the real win. Not "caching saved me money," but "a stable prefix let caching keep working instead of collapsing to full price." My handoff and memory files are frozen prose with fixed dates, so the front of my context does not move, so the 97.9 percent holds. Quiet, structural, and easy to wreck with one careless timestamp.

The hidden tax nobody notices

Here is the part that actually bothered me. The handoff file is injected into every session by a startup hook. Building a new tool? You want it. Fixing one line of copy? You still pay for all 11,700 tokens of project history you will never read this session.

It is mostly cached after the first turn, so the dollar figure per session is small. But it is pure overhead on the sessions that do not need it, and it crowds the context window with stale history on tasks that should be simple.

Tokens the handoff file injects into every session

The fix: split the handoff into a stub and a detail file

The change is small. I split one file into two.

• The stub, about 650 tokens. This is all the startup hook injects now. It holds a one-screen snapshot of current state plus a routing rule: if you are doing a small scoped edit, this is enough; if you are building, touching a shared file, or unsure, read the detail file first.
• The detail file, the full running log. Session-by-session history, verification numbers, gotchas. It is never auto-injected. The agent reads it on demand, once, only when the task warrants it.

The routing rule lives inside the always-injected stub, so the agent always knows which file to read before it acts. Small tasks stay cheap. Build tasks pull the full context exactly when they need it, and not a moment before.

The calculations, in full

Here is the per-session math that decides whether this actually helps. The handoff is written to cache once at 1.25 times, then read on each later turn at one tenth.

A small session, 10 turns, handoff never needed

A build session, the detail file is read once

Per-session handoff cost, before vs after

So does it save money?

Yes, but be honest about the size and the source. Per small session you save roughly 8 to 13 cents. If most of your sessions are small, and mine are, quick edits, copy fixes, questions, that adds up to maybe 10 to 20 dollars a month in direct token cost. The bigger win is not the dollars. It is the context window and the focus. A typo fix should not carry 11,700 tokens of unrelated build history that the model has to read around. Less irrelevant context tends to mean sharper small-task work.

The lever that dwarfs all of this

One honest footnote. The largest token saving from a handoff or memory system is not caching at all, and my transcript script cannot even see it. It is the work that never happens.

Without a handoff, a fresh session re-derives the project state from scratch. It greps, reads whole files, and reasons across several turns to reconstruct what it already knew yesterday. That is tens of thousands of fresh, full-price input tokens plus output tokens, burned on rediscovery. The handoff file is a compressed form of that context. You spend a few hundred cached tokens to skip tens of thousands of fresh ones. You cannot measure tokens for work that did not occur, which is exactly why it is easy to undervalue.

The playbook

1. Freeze the front of your context. No live timestamps, no per-request IDs, no reordered JSON in the always-loaded files. One moving byte near the front can collapse a 97 percent cache rate.
2. Split always-on context from on-demand context. Inject a small stub every session. Keep the heavy history in a separate file the agent reads only when the task needs it.
3. Put the routing rule where it is always loaded. The stub itself should tell the agent when to go read the detail file, so it never has to guess.
4. Measure from your own transcripts. The usage data is sitting in your session logs. Do not estimate cache savings, count them.
5. Prune the detail file. Append-only history grows forever and re-inflates your build sessions. Archive the old entries.

None of this is exotic. It is the same idea as keeping a tidy README next to a deep wiki, applied to a context window with a price tag. The cache does the heavy lifting. Your job is to not get in its way, and to stop paying for history you are not using.

Amit