Coming in L2Cache 2.0. The cache warnings, keep-warm heartbeat and cold resume guard described below arrive in 2.0, which is coming soon. The explanation of prompt caching and the Claude Code commands apply today. The App Store has version 1.4.6.
You leave a long Claude Code session for lunch, or overnight. You come back, type one short message, and that single message uses more of your budget than the last twenty did. Nothing is broken. The session's prompt cache expired while you were away, and the first message back paid to rebuild it.
This article explains what the prompt cache is, why the first message after it expires costs so much, how to see it coming, and the cheaper ways to carry on.
A model remembers nothing between requests. Every time you send a message, Claude Code sends the whole conversation again: the system prompt, your project context, every earlier message and tool result, and your new message at the end.
Most of each request is the same as the one before it, so the API caches it. On a normal turn the API reads the unchanged start of the request (the prefix) from cache, and only fully processes the new part. Reading from cache is billed at a small fraction of the normal input price.
The cache doesn't last forever. It expires after a period with no requests, called its time to live (TTL). Each request that hits the cache resets the timer, so it stays warm while you keep working.
The API offers two lifetimes, and which one Claude Code uses depends on how you pay:
You can choose the lifetime yourself with the promptCacheTtl setting (Claude Code 2.1.242 or later). A coffee break is enough to cool a 5-minute cache. A 1-hour cache survives a meeting, but not lunch.
When the cache has expired, there's nothing to read. The first request back has to process the whole context again and write it to the cache. Cache writes cost more than normal input, while cache reads cost far less:
| Price per token, relative to normal input | Cache read (warm turn) | Cache write (cold reload) | Cold ÷ warm |
|---|---|---|---|
| Opus 5.5 and Sonnet 5.5, 1-hour cache | 0.05× | 2× | 40× |
| Opus 5.5 and Sonnet 5.5, 5-minute cache | 0.05× | 1.25× | 25× |
| Most other models, 1-hour cache | 0.1× | 2× | 20× |
| Most other models, 5-minute cache | 0.1× | 1.25× | 12.5× |
Multipliers from Anthropic's prompt-caching pricing, checked November 9, 2026. Opus 5.5 and Sonnet 5.5 price cache reads at 0.05× base input; most other models at 0.1×.
So for the context part of the request, the first message after expiry costs roughly 12× to 40× a warm turn, depending on the model and the cache lifetime.
A worked example. A 241k-token Opus 5.5 session on a 1-hour cache. A warm turn reads that context for about $0.05 at API list prices (241k × $0.20 per million). After the cache expires, the next message writes it again for about $1.93 (241k × $8 per million). That's one message costing what about forty warm turns cost, before Claude has written a word.
On a subscription you don't see dollars, but the reload still counts against your plan's 5-hour and weekly limits. Anthropic doesn't publish exactly how cache reads and writes are weighted there, so treat the API multipliers as a guide to the shape of the cost, not an exact figure.
The expensive part is that one request. After it, the context is cached again and the following turns are back to cheap reads, until the next long break. A session you leave and come back to every few hours pays the reload every time.
Size makes it worse. In our own Claude Code sessions, once context passed about 600k tokens, cache rewrites after expiry made up 60–66% of all the cost. Large sessions don't get expensive because of each warm turn; they get expensive every time they go cold.
claude --resume, claude --continue and /resume load the transcript from disk and show it to you. Nothing is sent to the model until you submit a prompt. That gives you a free moment to decide what to do before you pay for anything.
Two numbers tell you what the next message will cost: how big the context is, and whether the cache is still warm.
/usage (2.1.251 or later) adds a Prompt cache (main) line that says whether the cache is warm, which lifetime it's on, and how long the session has been idle. /context shows what's filling the context.usage record holds the context size (input_tokens + cache_creation_input_tokens + cache_read_input_tokens) and a timestamp. The cache lifetime shows in cache_creation.ephemeral_1h_input_tokens versus ephemeral_5m_input_tokens. If the time since the last reply is longer than the lifetime, the cache is cold./compact asks the model to summarize the conversation and carry on from the summary. While the cache is warm, the summary request reads the history from cache, so it costs a fraction of what the size suggests. After a break, it reprocesses the whole history as uncached input, which is why compacting costs the most when you resume an old session. If you're going to compact, do it before you leave. /compact <focus> tells it what to keep.
Claude Code can also do this for you: idle compaction compacts a session on the 1-hour cache once it's at least 200k tokens and has sat idle for about an hour, as long as your Mac stays awake. It's on by default; the setting is idleCompaction.
/clear starts a new, empty session in the same terminal. It costs nothing, and the new session starts small instead of reloading the old one. What you lose is the context, so the trick is to bring the important part with you: a short handoff with the goal, the files you were in, what's done, what's next and where you left off. A handoff is usually a few hundred to 1.5k tokens, not hundreds of thousands.
A cold session is also a natural place to start fresh anyway. If the next thing you want to do is a different task, the old context mostly gets in the way.
On a 1-hour cache, a single short message before the hour is up resets the timer for a small fraction of what a cold reload costs. That's worth it for a big session you really will come back to soon. It isn't worth doing all night, or on a 5-minute cache, where you'd need one every few minutes.
For a small session, the reload doesn't matter much. A 30k-token session reloaded cold is still a cheap request. Save the thinking for the big ones.
L2Cache reads your Claude Code session files on your Mac, so it knows each session's size, cache lifetime and the time of its last request. It uses that to warn you at three points:
Cold cache at 14:05 — this session's cache expired 3 h ago.
Your next message reloads 241k tokens (≈ 20× a warm turn).
Cheaper: type /clear — L2Cache starts a fresh session with this session's handoff.
Or just send your message to continue as is.If you type a message anyway, L2Cache stops that one message, once, so it doesn't reload the context by accident. Your text isn't lost: press ↑ and Return to send it as is, and you won't be stopped again in that session. Or type /clear, and the new session starts with the cold session's handoff already loaded. The same check runs on a terminal left open overnight, which never fires a resume event.
The multiplier in the warning is a rounded figure. As the table above shows, the real ratio is between 12× and 40× depending on model and cache lifetime.
/clear is a file L2Cache writes when the cache expires.claude -p --continue only get the warning./new starts the fresh session. Codex doesn't record a cache lifetime, so L2Cache assumes the short five-minute one./clear and a handoff.L2Cache shows each coding-agent session's size and cache state, and warns you before a cold reload.
Download L2Cache for Mac