You leave a long Claude Code session for lunch, come back, type one short message, and the 5-hour meter jumps. Nothing went wrong:
the prompt cache expired while you were away.
After a pause, your next message re-sends the whole conversation as new tokens. New tokens count about 67 times as much
against the limit as cached ones (on my account), so by those rates the first message back into a 300k-token session costs about 1.8% of a 5-hour
window, where the same message a minute earlier would have cost about 0.03%.
What the prompt cache does
Every Claude Code model call sends the whole conversation: instructions, tool definitions, every message and tool result so far. The
part that hasn't changed since the last call is read back from Anthropic's prompt cache instead of being processed again. Cache reads
are cheap, which is why a long session costs far less than its size suggests.
The cache doesn't last forever. Anthropic's docs: "By default, the cache has a 5-minute lifetime. The cache is refreshed for no
additional cost each time the cached content is used", and a 1-hour lifetime is available as an option
(Prompt caching). Each call keeps it warm. Stop
for longer than its lifetime and it's gone.
What the first message back costs
With the cache gone, the next call writes the whole context to the cache again. Cache writes are new tokens, and new tokens are what
the usage limit mostly counts. From my own fit (How many tokens is 1% of your limit?): 1% of
the 5-hour window was about 166k new tokens or 11.2M cached ones.
| Context re-sent | Cache still warm | Cache expired |
|---|---|---|
| 100k tokens | ≈ 0.01% | ≈ 0.6% |
| 300k tokens | ≈ 0.03% | ≈ 1.8% |
| 600k tokens | ≈ 0.05% | ≈ 3.6% |
Share of the 5-hour window for the context alone (the reply adds a little), from one account's measurement: 6.04% per million new
tokens and 0.09% per million cached ones. Your plan's numbers differ; the ratio is what matters.
One message is a few percent. It adds up when you come back to several long sessions after a meeting, or when every subagent you
start after a break has to rebuild its context too.
What to do about it
Compact before you leave.
/compactreplaces the conversation with a summary, so the cold rebuild is small.Or clear it. If the next task is unrelated,
/clearand start fresh instead of paying to rebuild a context you don't need.Come back to one session at a time. Each expired session rebuilds separately.
Watch your context size. limitcast Pro puts a
/compactnudge in the status line once a session re-sends more than ~150k tokens per call.
limitcast 0.11: a warning before the expensive message
limitcast Pro now has a cold-cache warning. When a session that re-sends 100k+ tokens has sat idle past the cache lifetime (60 minutes
by default, LIMITCAST_CACHE_MINUTES to change it), it holds your first message once and tells you what it will cost against
your own measured limit. Send it again to go ahead, or /compact first:
limitcast: this session sat idle for 75 minutes, so its prompt cache has
expired. Your message re-sends 300k tokens of context: ≈1.8% of your
5-hour window (≈0.03% if the cache were still warm). Send it again to go
ahead, or run /compact first to shrink it.
It comes with limitcast install --guard (install); free installs record what it would have held.
Already installed with --guard? Run limitcast doctor --fix to add it. More on the warning
Measure your own numbers
npm install -g limitcast
limitcast install # records your limit readings from the status line
# use Claude Code for a day or two, then:
limitcast results # what 1% of your 5-hour window is, in new and cached tokens
Local only, never uses your Claude login. Install details · Pro plans
limitcast forecasts when each Claude Code and Codex window runs out, and its Pro plan stops runaway subagents before they burn the rest of it.
See what limitcast does · How the 5-hour and weekly limits work ·
How many tokens is 1%? · Subagents and your limit
Top comments (0)