18.4 Billion Cached Tokens

I dumped every Claude Code turn since January into a Postgres lake and added up the tokens. Fresh input: about 20.1 million. Output: about 92.5 million. Cache_read: about 18.4 billion.

Read that again. The model re-read 18.4 billion tokens of cached context to produce 92.5 million tokens of new work, off the back of 20 million tokens I actually fed it cold. The cache is doing roughly 900 times the volume of my fresh input.

That number is not a curiosity. It's the load-bearing economic fact under everything I've built — the overnight chain, the 32 workers, the long infra marathons. Without it, none of this runs on Apple M4 hardware in my house. With it, it does. Let me show you why.

What Cache_read Actually Is

Every turn of a long agent session re-sends the whole conversation so far: the system prompt, every prior message, every tool call, every file the model already read, every command output. The model can't "remember" across turns on its own — the context window is the memory, and the context window has to be re-supplied on every single call.

Naively, that's catastrophic. A ~3,700-turn session — one of my longest, an all-day homelab infrastructure run — would re-process the entire growing transcript on every turn. By the end, each turn is shipping hundreds of thousands of tokens of history just to add one more step. Pay full freight on all of it and the bill is absurd, and the latency is worse.

Prompt caching breaks that. The first time the model sees a chunk of context, it pays cache_creation to write it into the cache. Every turn after that, the same prefix comes back as cache_read — at roughly a tenth of the cold input price, and much faster, because the model isn't re-ingesting it from scratch. My lake shows ~843M cache_creation tokens against ~18.4B cache_read. The cache is read about 22 times more than it's written. That ratio is the entire game.

The Economics, Concretely

Here's the mind-bending part. The thing I pay for least, by volume, is the thing the model "sees" most.

• 20.1M fresh input — the new stuff each turn. The actual cold cost.
• 18.4B cache_read — the context re-read every turn, at ~10% the price.
• 92.5M output — what the model produced.

If that 18.4B had been billed as cold input, the input side of my usage would be roughly 900x larger. Instead it's discounted into a rounding error next to the work it enabled. The cache didn't make my sessions a little cheaper. It made a category of work — long, context-heavy, single-thread infrastructure sessions — go from economically stupid to economically obvious.

This is why a solo operator can run the kind of sessions I run. A 3,000-turn session is not 3,000 independent calls. It's one call that gets cheaper per-token the longer it goes, because the fixed cost of establishing context amortizes across every turn that reuses it. Length stops being the enemy. Length becomes the thing the cache rewards.

What It Does Not Save

Honesty matters more than the headline here, so let me be precise about the limits. The cache is not free money and it does not save what people assume it saves.

It does not make output cheaper. Those 92.5M output tokens are billed at full output rates, every one of them. Caching touches the input prefix, not generation. A worker that produces verbose answers pays full price for every wasted token. The cache will not bail you out of a chatty model. That's a model-class decision, not a caching decision.

It does not save the first read. Cache_creation is real cost. The first time the model ingests a giant file or a long system prompt, you pay to write it in. Caching only pays off on reuse. Read a 5,000-line file once and never touch that context again and you paid creation for nothing.

It does not survive a context reset. The cache keys on a stable prefix. Change something early in the context and everything after it invalidates — you're back to cache_creation prices for the rebuilt tail. Caches also expire. Walk away long enough and the prefix goes cold; the next turn re-pays creation.

It does not fix bad context hygiene. A bloated context that re-reads the same file four different ways, or stuffs in junk the model never uses, gets cheaper per token with caching but is still wasteful in absolute terms. Cheap waste is still waste. The cache rewards reuse, not hoarding.

How This Changes How You Structure a Session

Once you internalize the ratio, you stop running agent sessions the way most people do, and you start running them the way the cache wants.

Stay in one conversation. This is the big one. The single most expensive habit in AI work is context-switching — closing a session, opening a new one, re-establishing everything cold. Every time you do that, you throw away a warm cache and pay creation all over again. My 22:1 read-to-creation ratio exists because I run long, continuous, single-problem sessions. People who open and close terminals constantly, or start fresh for every small task, are leaving the entire cache discount on the floor. The cache wants you to stay.

Front-load the stable stuff, append the volatile stuff. The cache keys on prefix. So the things that don't change — system prompt, project context, the files you'll reference all session — belong early and untouched. The things that change every turn belong at the end. If you edit something near the top of a long context, you blow away the cache for everything below it. Structure the session so the expensive-to-establish context sits still and the churn happens at the tail.

Treat session length as an asset, not a liability. My instinct from years of "keep it tidy, start clean" was wrong for this medium. A long session isn't accumulating debt — it's accumulating a warm cache that makes every subsequent turn cheaper. The homelab marathons near 3,700 turns aren't expensive because they're long. They're efficient because they're long. The cost-per-turn drops as the context warms.

Don't confuse "the model saw it" with "I paid for it." This is the mental flip that took me longest. In a warm session the model is reasoning over hundreds of thousands of tokens of context, but I'm paying cold price for almost none of it. The apparent richness of what the model "knows" in turn 3,000 is almost entirely cache. The trap is the inverse: assuming a fresh session is cheap because it's short. A fresh session is all cold input. The short session can cost more per unit of real work than the long one.

Why I Care

I build agentic infrastructure on hardware in my house — Coquina for memory, Forge running 32 autonomous workers, a 25-step overnight chain that does security review, code review, auto-fix, and research while I sleep. Zero cloud inference for the local fleet, but the Claude Code work that builds and debugs all of it lives or dies on cache economics.

18.4 billion cache_read tokens is the proof. It's not a vanity metric — it's the line item that says this scale of solo work is viable at all. The cache is the difference between "I could build this if I had a team and a budget" and "I built this, alone, on hardware in my house, and here's the telemetry."

Knowing which token you're actually paying for — and structuring the session so the model re-reads instead of re-ingests — is one of the most underrated skills in shipping real AI systems. Most people never look at the ratio. The ratio is the whole story.

If you're building agent systems and want to talk cache economics or how to structure long sessions, I'm at reed@grainlabs.io.