Why Claude Code Suddenly Burns Tokens 10x Faster: The Prompt Cache Nobody Talks About (2026)

Four separate threads hit Reddit this week, all describing what looks like the same bug in four different ways. One user's 5-hour limit went from 0% to 100% without answering a single query. Another asked whether Claude Code had doubled token consumption overnight — "6% at night to 25% in the morning. Wasn't using it at night at all." A third watched Claude Code get stuck printing the word "court" thousands of times, incinerating tokens until they hit Escape. A fourth was just new and already at 50% of their weekly limit.

I use Claude Code every day and I've had the first two happen to me. The replies in those threads are mostly correct about what to do — clear your sessions, don't run one chat for weeks — but almost nobody names the actual mechanism. It isn't context size on its own. It's the prompt cache.

The distinction matters, because it's the difference between "big sessions cost more" (roughly linear, manageable) and what people are actually reporting: the same session, the same prompt, costing ten times what it cost an hour ago. That's a cache miss, and once you know what causes one, most of these "sudden" spikes stop being mysterious.

The Part Everyone Gets Half-Right

The standard Reddit answer is correct as far as it goes. From the "5-hour limit instantly" thread:

Whenever you send a message, it's not just sending that message, it's sending the entire conversation history every single time.

True. The model is stateless, so Claude Code re-sends the full context on every request: system prompt, project context, every prior message and tool result, plus your new message.

But if that were the whole story, a 200k-token session would cost roughly the same on every turn — expensive, but predictably expensive. It doesn't work that way, because most of that request is byte-identical to the previous one, and the API doesn't reprocess what it already processed.

Here's the number that explains everything else in this article. Per Anthropic's docs, cache_read_input_tokens are billed at roughly 10% of the standard input rate. Tokens that miss the cache are billed at full price.

So the same 200k-token session has two completely different costs depending on one invisible variable:

Turn type	What happens	Relative input cost
Cache hit (normal turn)	Only the new exchange is processed	~10%
Cache miss (something changed)	The entire history is reprocessed	100%

That's the 10x. Nothing about your prompt changed. Nothing about your context changed. The cache state changed.

How the Cache Actually Works

The API matches the start of each request — the prefix — against content it recently processed. Claude Code deliberately orders every request so the stable stuff comes first:

1. System prompt — core instructions, tool definitions, output style. Changes when the loaded tool set changes, or Claude Code is upgraded.
2. Project context — CLAUDE.md, auto memory, unscoped rules. Changes at session start, /clear, or /compact.
3. Conversation — your messages, Claude's responses, tool results. Changes every turn.

Normal turns only append to layer 3, so layers 1 and 2 stay cached and you pay the 10% rate on nearly everything.

The critical property: the match is exact, and a change anywhere in the prefix recomputes everything after it. There is no per-file or per-segment caching. Edit one line near the top of the request and you re-pay full price for all 200k tokens behind it.

The Vicious Cycle Nobody in the Threads Spotted

One commenter in the "save tokens" thread got remarkably close:

If you keep a session "warm" by keeping less than 60 minutes between each turn, then most of that is kept in cache... After 60 minutes the entire context is reprocessed and you take the token hit.

That's essentially right, and better than most advice you'll read. On a Claude subscription, Claude Code requests the one-hour cache TTL automatically — usage is included in your plan, so the longer TTL costs you nothing. Every request that hits the cache resets the timer, so the cache stays warm as long as you keep working.

But the docs contain a detail that nobody in any of the four threads mentioned, and it's the single nastiest thing in this whole system:

If you've gone over your plan's usage limit and Claude Code is drawing on usage credits, you are billed for that usage, so Claude Code automatically drops the TTL to five minutes.

Read that again in the context of someone panicking about their usage. You blow through your limit. You enable usage credits to keep working. Your cache TTL silently drops from 60 minutes to 5. Now every coffee break, every meeting, every time you stop to read what Claude wrote for more than five minutes, your next turn reprocesses the entire session at full price — and that is now being billed to you as real money rather than absorbed by your plan.

Explaining "It Turned On Like a Switch"

The person whose limit vanished instantly said something the thread glossed over: they'd been building for weeks with no problem, and then "it pretty much turned on like a switch."

Compounding context explains a gradual climb. It does not explain a switch. Two documented things do:

Auto-update plus resume. Claude Code downloads new versions in the background and applies them on next launch. A new version typically changes the system prompt or tool definitions — layer 1. And the docs are blunt about what that means when you go back into an old session:

Resuming a session after an upgrade reprocesses the entire conversation history with no cache hits, since the history now sits behind a different system prompt. The cost scales with how long the resumed conversation is, so the first turn back into a long session can be the most expensive request you send.

A weeks-long session, resumed the morning after an auto-update, is close to a worst case: maximum history, guaranteed zero cache hits, one turn. That is a switch, and it plausibly explains the "6% at night to 25% in the morning, wasn't using it at night" report too.

MCP servers reconnecting on their own. When MCP tool definitions load into the prefix rather than being deferred, any change to them invalidates the cache — and per the docs this "can happen without any action on your part: a stdio server's process exits, an HTTP session expires, or a server reconnects automatically after a transient failure." Tool search defers MCP definitions by default on supported models, which protects you; if tool search is disabled or unavailable, a flaky MCP server is a random cache-invalidation generator wired into your session.

The Full List of Silent Invalidators

Straight from the docs, these break the cache and give you one slow, expensive turn:

• Switching models with /model — each model has its own cache. Also fires on opusplan every time you toggle plan mode, and on Fable 5's automatic model fallback.
• Changing effort level with /effort — the cache is keyed by effort too. (Claude Code now shows a confirmation dialog for exactly this reason. More on what the levels do in my effort levels breakdown.)
• Turning on fast mode mid-session — adds a header that's part of the cache key. Cheap at the start of a session, expensive deep into one.
• Connecting or disconnecting an MCP server (when its tools sit in the prefix).
• Enabling or disabling a plugin that ships an MCP server. Plugins that only add skills, commands, agents, or hooks are cache-safe.
• Denying an entire tool — a bare Bash or WebFetch deny rule removes the definition from the system prompt. Scoped rules like Bash(rm *) are fine.
• Upgrading Claude Code.

And the ones that feel expensive but are actually free: editing files in your repo, editing CLAUDE.md mid-session (it doesn't apply until restart anyway), changing output style, changing permission mode, invoking skills and commands, /recap, and spawning a subagent.

Two Things the Threads Got Wrong

"Compaction costs you money." One commenter argued that /compact is a trap because "it rewrites the history and the next call re-pays for everything it kept." That's a reasonable inference from the prefix rule, and it's wrong. Per the docs, the summarization request itself shares your existing prefix and reads the cache rather than reprocessing the history, and the turn after compaction only builds cache for the much shorter summary. Most of compaction's cost is generating the summary, not a cache miss.

There is a better move for one specific case, though: if you've gone down a path you want to abandon entirely, /rewind beats /compact. Rewinding truncates back to a prefix that is already cached, instead of building a new one. I cover the broader clear/compact/context workflow in Claude Code context management.

"The 'court' bug is a repetition loop." This one's more interesting. In that thread, Claude diagnosed itself as suffering "an autoregressive repetition loop, or 'neural text degeneration'" — one accidental token raising the probability of the same token again — and blamed the session for being "long and repetitive." The commenters ran with it. The post's author already spotted that the reasoning was circular: the loop is what made the session long.

But the GitHub issue the thread linked, #64108, describes something different. It's titled "Tool calls intermittently emitted as literal text (stray 'court' + raw <invoke>)" — a stray court token followed by raw XML function-call markup appearing in the transcript instead of the tool executing. That signature points at function-call serialization corruption, not generic text degeneration. As of this writing the issue is open with no official response.

The practical advice from that thread survives regardless of the cause, and it's the one thing everyone agreed on: hit Escape immediately. A runaway generation loop compounds — every repeated token joins the context that gets reprocessed on the next turn.

What I Actually Do

• /clear between unrelated tasks, always. Not to shrink context — to reset the cache cleanly rather than dragging a stale prefix around.
• Model and effort chosen once, at the top. If I know a session is heavy planning, I set it before the first prompt.
• Long breaks get a /clear first, not a session left open. The prefix I come back to is going to be cold anyway.
• /context when replies feel sluggish, /usage when the meter looks wrong. On a paid plan, /usage attributes recent usage to skills, subagents, plugins, and individual MCP servers as a percentage of the total — that's how you find a server quietly costing you a fortune. Press d or w to toggle 24-hour and 7-day views.
• Watch the cache ratio, not just the total. A statusline script can display cache_read_input_tokens against cache_creation_input_tokens. A high read-to-creation ratio means caching is working. If creation stays high turn after turn, something in your prefix keeps changing.
• Never resume a weeks-old session. Start fresh in the project directory and let Claude read the code — the codebase holds the real context, and reading files selectively is dramatically cheaper than replaying a 150k-token chat. A commenter in the limits thread gave exactly this advice and it's the best answer in all four threads.

FAQ

Why did my Claude Code usage jump overnight without me using it?

You almost certainly didn't burn tokens overnight — you burned them on the first turn the next morning. Claude Code auto-updates on launch, and resuming a long session under a new system prompt reprocesses the entire history with zero cache hits at full input price.

Does clearing context actually save tokens, or just improve quality?

Both, but through different mechanisms. Smaller context means fewer tokens per turn, and a clean prefix means a higher share of those tokens bill at the ~10% cache-read rate. See Claude Code usage limits explained for how the two timers count them.

Is switching to Sonnet mid-session a good way to save tokens?

Eventually, yes — but the switch itself costs you one fully uncached turn, because each model has its own cache. Switching deep into a large session can cost more than it saves on the next few turns. Switch at the start, or right after a /clear.

How do I tell a cache problem from just having too much context?

Run /context for size and check your statusline's cache fields for cache health. Large context with a high cache-read ratio is fine. Small context with high cache-creation every turn means something in your prefix keeps changing — usually an MCP server reconnecting or a setting you keep toggling.

Bottom Line

Every one of these threads was framed as a billing bug, and every one of them has a mechanical explanation that the community's folk wisdom gets about 70% right. "Don't use one giant session" is good advice for the wrong reason. The reason is that a cached prefix costs a tenth of an uncached one, so the expensive question isn't how big is my context — it's how often does my prefix change. Pick your model once, clear between tasks, and stop resuming month-old sessions, and the mystery spikes mostly stop.