DEV Community: Sam Stull

Why a long idle pause costs you: Claude Code's prompt cache

Sam Stull — Mon, 26 Oct 2026 03:39:26 +0000

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. /compact replaces the conversation with a summary, so the cold rebuild is small.
Or clear it. If the next task is unrelated, /clear and 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 /compact nudge 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

Claude Code usage limit reached: how the 5-hour and weekly limits work

Sam Stull — Mon, 26 Oct 2026 03:38:33 +0000

"You've hit your limit" usually arrives in the middle of something. Here is how Claude Code's limits work on a Pro, Max or Team plan,
what actually moves them, and how to see the end of a window coming instead of finding out from the error.

There are two limits. A session limit that resets every five hours, and a weekly limit that resets at a fixed time each week.
What fills them is mostly new tokens: on my account, 1% of the 5-hour limit was about 166k new tokens but about 11 million
cached ones.

The two windows

-
The 5-hour session limit. Anthropic's help center: paid plans have "a session limit that resets every five hours, and weekly
limits that reset once every week"
(How do usage and length limits work?).

-
The weekly limit. It "reset[s] at a fixed time each week that is assigned to your account", whenever you started using Claude
(What is the Pro plan?).

-
Where to see them. Settings → Usage on claude.ai shows both as progress bars, with the time left in the current session
(Usage limit best practices). Claude Code also
passes the same readings to your status line, which is how a tool can show them while you work.

When either one is used up you wait for its reset, or keep going on paid extra usage if you've turned that on. A full weekly limit
stops you even with room left in the 5-hour window.

What fills them: new tokens, not cached ones

The meter is a percentage, and Anthropic doesn't say how many tokens a percent is. I measured it on my own account by comparing each
rise of the 5-hour reading with the tokens my sessions used in between (61 observations, two days; the method is in
How many tokens is 1% of your Claude Code limit?):

	Tokens per 1% of the 5-hour limit
New tokens (input, cache writes, output)	≈ 166k
Cached tokens (cache reads)	≈ 11.2M

One account, one plan. A fit on the previous day gave about 200k and 10.7M, so read these as a range.

A cached token counted roughly 1/67 as much as a new one. Claude Code re-sends your whole conversation on every model call, but most
of it comes back from the cache, so a long session is cheaper than its size suggests. What runs a window out is anything that sends
new tokens:

Subagents. Each one writes its own context from scratch. A typical one cost me about 2% of a 5-hour window (Do subagents burn your limit faster?).
Coming back after a long pause. Once the prompt cache expires, the next message re-sends the whole context as new tokens (Why a long idle pause costs you).
Big tool output and file reads. Everything new that enters the conversation is new tokens once.
A large starting context. Instructions, tool lists and skills are written once per session and every subagent, then re-read on every call.

How to see the runout coming

The percentage alone doesn't say whether you'll make it to the reset. That depends on your pace: 70% with an hour left is fine at a
slow pace and a lockout in twenty minutes during a burst of subagents. limitcast does that arithmetic for you:

$ limitcast status
window used burn runs out resets today status
claude 5h 71% +18.2%/h 16:40 17:00 - AT_RISK
claude 7d 41% +0.6%/h - Sun 03:00 6% left OK

The 5-hour window is forecast from the last hour's pace; AT_RISK means it runs out before it resets.
The weekly window uses your pace over the last full day, nights included, and shows today's even share of the week, so one busy hour doesn't cry wolf.
The same line sits in your Claude Code status line, from the readings Claude Code already passes to it. No login, nothing leaves your machine.

The free version gives you the forecast and the status line. Pro also stops new subagents when a window is on
pace to run out within 30 minutes, moves them to Sonnet while it's tight, and sends a desktop notification before you hit the limit.

What to do when you're close

Don't start a fan-out near the end of a window. Ten subagents at about 2% each are a fifth of it.
Compact long sessions before a pause, not after: /compact shrinks what the next call has to re-send.
Queue the heavy job for after the reset instead of starting it with 10% left.
Check what loads before you type. Unused MCP servers and skills are re-sent on every call and to every subagent: limitcast trim measures them.

See your own numbers

npm install -g limitcast
limitcast install # adds the forecast to your status line; backs up settings.json
limitcast status # every window: used, burn rate, runout time, reset

Node 20+, macOS or Linux. Install details · limitcast uninstall restores your settings.

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 · Pricing ·
How many tokens is 1%? · Subagents and your limit ·
Idle pauses and the prompt cache

How many tokens is 1% of your Claude Code limit?

Sam Stull — Mon, 26 Oct 2026 01:26:25 +0000

Originally published at limitcast.dev.

Anthropic shows how much of your 5-hour and weekly limit you've used, as a percentage. It doesn't say how many tokens that percentage is, and it doesn't say how different kinds of tokens count. So I measured it on my own account.

1% of the 5-hour limit was about 166,000 new tokens, or about 11 million cached tokens. A cached token counted roughly 1/67 as much as a new one.

That ratio changes what's worth optimizing. Over the two days I measured, new tokens were 2.5% of everything Claude Code sent, and they used about 63% of my limit.

	Share of tokens	Share of the limit they used (estimated)
New tokens (input, cache writes, output)	2.5%	≈ 63%
Cached tokens (cache reads)	97.5%	≈ 37%

My Claude Code usage, 23–25 October 2026: 53.7M new tokens and 2,103.5M cached tokens. The limit share applies the fit below to those totals.

How I measured it

Claude Code passes your limit readings to the status line: percent used of each window and when it resets. Its transcripts record every model call's tokens: input, cache writes, cache reads and output. Put the two side by side and you can see how many tokens it took to move the meter.

Each time the 5-hour reading rose between two status-line updates, I took the rise and the tokens my sessions on that account used in between, split into new tokens (input, cache writes and output) and cached tokens (cache reads). Then a least-squares fit with no intercept:

rise in % ≈ a × new tokens + b × cached tokens

With 61 such observations, the fit gave:

	% of the 5-hour limit per million	Tokens per 1%
New tokens	6.04%	≈ 166k
Cached tokens	0.090%	≈ 11.2M

A fit on the previous day's readings gave about 200k and 10.7M, so treat these as a range rather than constants: roughly 165–200k new tokens, or 10.7–11.2M cached tokens, per 1%.

What it means in practice

Subagents are expensive. Each subagent starts its own context and writes it into the cache from scratch. Subagents sent about a third of my tokens (33%), but nearly half of my new tokens (48%), and used an estimated 42% of my limit.

Your starting context is cheap per call, but it adds up. My sessions start at about 100k tokens before I type: system prompt, tools, MCP servers, skills, CLAUDE.md. Written once into the cache, that's about 0.6% of the limit. After that, each model call re-reads it from the cache for about 0.009%. A session with 300 model calls spends about 3% of a window re-reading that starting context. Trimming 4k tokens of unused skills and MCP servers from mine saved about 0.3% of a window over 1,100 calls: real, but small.

Cache misses are where it gets expensive. This one is an inference from the ratio rather than something I measured directly: when the prompt cache expires (after a pause, for example), the next call writes the whole context again as new tokens. In a session that has grown to 200k tokens, that single call is more than 1% of the limit.

So the order of what to watch is: how many subagents you start, how long your sessions run between pauses, and only then how big your CLAUDE.md is.

The caveats

This is one person's account on one plan, over about two days. Your numbers will differ.
The fit doesn't separate models. If Anthropic weights Opus and Sonnet differently, my mix of the two is baked into these numbers.
Cache writes are counted as new tokens. They may be weighted differently from input and output.
The readings are whole percentages, so each observation is noisy. It takes dozens of them before the fit settles.
Anthropic can change how limits are counted at any time; a measurement like this is a snapshot.

Measure your own

I built this measurement into limitcast, a free command-line tool for Claude Code and Codex. It reads only the files Claude Code already writes on your machine and sends nothing anywhere.

npm install -g limitcast
limitcast install      # records your limit readings from the status line
# use Claude Code as normal for a day or two, then:
limitcast results

Once it has about 30 observations, limitcast results prints your own numbers: how many new and cached tokens move your meter by 1%. The fit is in src/calibrate.mjs if you want to check it.

I'd like to hear whether other people's ratios look similar, especially on different plans.