Missing Claude’s cache on Opus 5.5 costs up to 40x more

In an October 13 post on Dgrcode, a developer works through the cost of Claude’s prompt cache. On Opus 5.5, a message sent after the cache has expired can cost up to 40 times more than the same message sent while the cache is still warm. The post then works out when it is cheaper to keep the cache alive with /loop and when to shrink the session with /compact.

The cache holds the processed version of everything the model has already read. Claude Code sends the whole context on every turn: the system prompt, AGENTS.md, skills, every earlier message and the new one. On a hit, Claude reuses the stored result and processes only what is new. Anthropic’s Claude Code documentation explains that the match is exact and runs from the start of the request, so a change anywhere in that prefix forces everything after it to be recomputed. Switching models has the same effect, because each model keeps its own cache. Claude Code uses a 1-hour cache that expires an hour after the last read or write. On the raw API the default is shorter. Since March 6, a cache_control block without an explicit ttl gets 5 minutes instead of 3,600 seconds, and teams that missed the change saw quota burn of 15-20x, Particula reported.

The 40x figure comes straight from the price list. Opus 5.5 charges $4 per million input tokens and $0.20 per million for a cache read, 20 times less. A 1-hour cache write costs twice the input price, and a miss rewrites the entire context at that doubled rate. The author’s example is a session with 300k tokens of context that gets a new 1k-token message. A hit costs the equivalent of 17k base input tokens. A miss costs 602k, more than 35 times as much. The bigger the existing context and the smaller the new message, the closer the gap gets to the full 40x.

The cheapest way around a miss is to never let the cache expire. A throwaway message like wait, I'm still working on this is about 10 tokens, but it writes more than 100 to the cache, because the previous response and the role markers go with it. Even with only 100k tokens of context, that saves 38.5x compared to a miss. Each hit also adds another hour for only a twentieth of the base price, so a perfectly automated cache costs 2x for the first hour, 2.05x for two hours and 2.1x for three. “There’s definitely a cost asymmetry here that can be leveraged,” the author writes. Claude Code’s /loop automates the ping, and you could loop roughly 40 times before it costs as much as a single miss. Cron syntax has no clean way to say “every 50 minutes”, so the post settles on running the loop at :00 and :30, which gives 40 iterations in 20 hours.

Compaction is the other option. It replaces the conversation with a summary, and the cost of producing that summary is easy to underestimate. The post breaks it down for the same 300k session, compacted before the cache expires. Claude Code’s compaction instruction is about 2k tokens, and with the context read from cache that step comes to 19k base input tokens. The summary is output, which Opus 5.5 bills at 5x the input price. In the author’s experience a summary usually stays under 30k tokens, which works out to 150k and is usually the most expensive part of compacting. The first message afterwards writes the summary, about 30k of system prompt and tools, and the new message to the cache, for another 122k. That size varies a lot by setup, and /context shows yours. In total, compacting costs 291k, about half a miss but far more than a hit. The savings come later: each following message reads around 60k from cache and costs about 5k instead of 17k.

The post’s rule of thumb is to compact when the context is big (roughly 600k tokens) or the pause is long (8+ hours), and to loop otherwise. The full decision flow:

• Under 100k of context: let the cache expire.
• Over 600k: compact, since you would have to soon anyway.
• Pause of 2 hours or less: loop.
• Pause of 16+ hours: compact.
• Pause of 8-16 hours: compact above 200k of context, loop below.
• Context under 300k: loop.
• Otherwise, a pause of 4+ hours: compact.

Pauses of 2-4 hours are a gray area. If you will keep working in the session for a long time, compaction is probably better. If you only need a few more prompts to finish the task, looping probably is.

Compaction also loses information. Going from 800k tokens to a 30k summary is more than 26x compression. The author points to prompt-compression research that puts the sweet spot at around 10x to 20x, with a performance drop around 25x, while noting that this research compresses the prompt itself rather than summarizing a conversation, so it is only a reference point.

While the post was being written, Claude Code reported “Compacted while idle, before the prompt cache expired.” The session held 220.3k of a 1M-token window, and the author had been away for just over an hour. “It looks like Anthropic agrees that missing the cache is pretty bad, although we disagree on what the best strategy would’ve been in this scenario,” the author writes; the choice there would have been to loop.

What the author wants instead is a cache-expiration setting in Claude Code with three modes. Keep Alive would loop, Smart Cache would choose between compacting and looping based on context size and time away, and Let Expire would do nothing. The time away would be something the user tells the harness.