Claude Code idle resumes: what they cost, and when the new warning appears

The 30-second version

On a Claude subscription within your plan’s usage, Claude Code writes the main conversation into a prompt cache with a one-hour minimum lifetime. Within that hour, the next request reads the cached context at a twentieth of the input price on Opus 5.5. After a longer gap the entry may be gone, and the next request writes the context to the cache again, at twice the input price.

Two October releases deal with this. The changelog for Claude Code 2.1.299 (14 October) announced idle compaction: a 200K-token conversation left idle for about 54 minutes in the terminal is compacted before its cache expires. Claude Code 2.1.304 (19 October) added a warning on Pro and Max plans when resuming an inactive conversation “would use a noticeable share of your 5-hour usage limit”.

We measured how often this costs us, read how the warning decides, and tested idle compaction:

• In our transcripts it happened 355 times. Across 46 main conversations from 10 July to 25 October, 355 requests that came an hour or more after the previous one wrote at least half their context to the cache; 250 of them wrote 95% or more. The median request wrote 365,288 tokens. At Opus 5.5 list prices, those writes were $1,151, 55% of the $2,074 those conversations cost in all.
• Under an hour, the cache mostly held. Of 270 requests after a 5-to-60-minute gap, 266 read most of their context from the cache.
• Most of it came from long-running sessions. Nineteen conversations accounted for all 355; one had 101. Automated prompts, most of them scheduled checks, started about half.
• Idle compaction never ran on them, and we don’t know why. None of our transcripts records one. Those sessions had been running for weeks on 2.1.283 and 2.1.293, but the 2.1.283 binary already contains the idle-compaction code behind a feature flag.
• With the configuration cached on our account, the warning can’t appear on a Max plan with Opus 5.5. It is a client-side estimate that shows at 5% of the 5-hour limit; Opus 5.5 would need about 1.36 million tokens on Max 5x, beyond its 1-million-token window. Fable 5.1 reaches it at about 300K tokens on Max 5x.
• Idle compaction worked on a fresh 2.1.310 session. It compacted a 421K-token conversation at 54 minutes for about $0.18. On a second return, 2 hours 12 minutes after the first, the compacted conversation wrote 24,738 tokens to the cache ($0.20), while an identical one with idle compaction off wrote 409,710 ($3.28).

Verdict: leave idle compaction on. When it runs, a return after more than an hour can write a summary to the cache instead of the whole conversation: on our second return, $0.20 against $3.28, and $0.58 against $3.51 counting the compaction and both returns. Claude then works from that summary. Check that it actually runs on sessions you keep open for days (the terminal says “Compacted while idle”): on ours it never did. And on a Max plan with Opus 5.5, don’t wait for the warning: with the configuration we saw, it can’t appear.

What changed in October

The warning asks “Resume this conversation?” and says how long the conversation has been inactive, how many tokens long it is, and about what share of your 5-hour limit resuming it will use. You can resume, or start a new conversation; “Claude can look this one up if you refer to it later”.

Why a resume costs anything

On Opus 5.5, a one-hour cache write costs $8 per million tokens and a cache read $0.20, against $4 for uncached input. Every request resends the whole conversation, so whether its context is read from the cache or written again decides most of the cost.

The one-hour cache is the default only on a Claude subscription within your plan’s included usage. With an API key, a cloud provider, or once a subscription draws on usage credits, Claude Code’s main conversation uses a five-minute cache unless you set promptCacheTtl yourself.

Our transcripts show where the line falls. We took every request in our main conversations (subagent transcripts left out) up to 19:18 UTC on 25 October, measured the gap since the previous request in the same conversation, and checked whether most of the request’s context was read from the cache or written to it:

Every cache write after a gap of under a day was a one-hour write, and requests after a 5-to-60-minute gap mostly read their context from the cache, so they cost little. Past an hour, almost every request wrote most of its context again.

What our logs show

We call a request a cold resume when its transcript record came at least an hour after the previous request’s record in the same conversation, its input context was at least 20K tokens, and it wrote at least half of that context to the cache. The gap between records approximates the time since the previous request. There were 355. The median one had a context of 384,785 tokens and wrote 365,288 of them; 250 wrote 95% or more, and 176 still read some context from the cache. Fourteen also switched models. The median write cost $2.92 at Opus 5.5 list prices, the largest $7.70, and the gap before them had a median of 9.9 hours.

They were not spread evenly. Nineteen of our 46 main conversations had any, and two of those accounted for 159 of them and $632. These are sessions we keep running for days and send work to. About half of the 355 were started by an automated or system-added prompt, most of them scheduled checks such as a daily inbox check or a weekday morning check, and most of the rest by a message sent into the session after a break. One came after Claude had waited more than two hours for an answer to a question it had asked.

Idle compaction never ran on these sessions. None of our transcripts records one. Our long-running sessions had been running for about four weeks; a running process keeps the version it started with, since updates “take effect the next time you start Claude Code”, and theirs were 2.1.283 and 2.1.293. After 2.1.299 shipped, they had 86 cold resumes with input contexts of at least 200K tokens. But the 2.1.283 binary already contains idle-compaction code behind a feature flag, and the flag’s cached value on our machine is set to compact, so their age doesn’t explain it. We don’t know why it didn’t run.

When the warning appears

The warning isn’t documented as a rule. In the 2.1.310 code, Claude Code estimates the share of your 5-hour limit like this:

share = context tokens / 1,000,000 × rate for the model × 100 / 5-hour allowance for your plan

The context is capped at the model’s window and the plan tier is the one Claude Code believes applies. It shows the warning only when it considers the cache expired, judging by the time since the last request, or the model has changed; when you aren’t already limited or using usage credits; and when the share is at least minPercent, which defaults to 5. The rates and allowances come from a configuration Claude Code downloads. Our account’s copy, cached in ~/.claude.json on 25 October, had allowances for Max 5x (50,000) and Max 20x (200,000), rates for 11 models, and no entry for Pro.

From those values:

Figures above 1 million tokens can’t be reached within a 1-million-token window. So with this configuration, Opus 5.5 users on either Max plan won’t see the warning. We checked: resuming a 764K-token conversation that had been idle for ten days, on Opus 5.5 on our Max 20x account, showed no warning; by the formula it would use 0.7% of the 5-hour limit. On Max 5x, the warning starts at about 300K tokens for Fable 5.1 and 500K for Opus 4.6.

These are Claude Code’s own estimates from a configuration that can change. We didn’t check them against the usage meter, which reports whole percentages.

Idle compaction, tested

We built two identical conversations in the terminal on Claude Code 2.1.310, each starting with the full Claude Code changelog: about 421K tokens of context once the terminal’s own prompt was added. We sent each a one-line message at 19:25 UTC and left them alone. Conversation A kept idle compaction at its default; B ran with "idleCompaction": false. Costs are at Opus 5.5 list prices, from the transcripts and the Session panel of /cost.

A compacted exactly as documented, and the terminal said so: “Compacted while idle, before the prompt cache expired”. At 20:27, 61.5 minutes after the warm-up, B’s request still read its 402,067-token context from the cache. That doesn’t show how long B’s cache would have lasted on its own. The two conversations started with identical prefixes, sessions in the same directory “can read each other’s cache”, and A’s compaction had read that same prefix eight minutes earlier; a read refreshes a cache entry’s lifetime, which Anthropic describes as a minimum, after which entries are deleted “promptly, though not immediately”. Counting the compaction, A had spent $0.38 since the warm-up and B $0.23.

The saving shows on the next return. We left both alone again and wrote to them at 22:39 and 22:40 UTC, 2 hours 12 minutes after their last requests. Neither transcript records another model request in between. A went first, but it no longer sent the changelog, so its request couldn’t refresh the cached copy the two had shared. This time B read 11,334 tokens from the cache and wrote 409,710, about 97% of its context, for $3.28; its Session panel gave the likely cause as “idle past the 1h TTL”. A, now a summary plus the terminal’s opening prompt, wrote 24,738, $0.20. Since the warm-up, A has cost $0.58 in all and B $3.51. What A gave up is its history: the summary replaced the changelog and the older messages, only the last reply was kept word for word, and the summary tells Claude where the full transcript file is if it needs details.

Two more things we saw. After compaction, A’s Session panel counted “1 expected rebuild (compaction or tool-result clearing)”, and both panels show Claude Code’s own estimate of whether the main conversation’s cache is still warm, with the time since it was last used. It is worked out from timestamps, not checked with the server, but it is a quick look before you come back to a large conversation. And the 2.1.310 code skips idle compaction in some cases: when auto-compaction or idle compaction is off, the conversation is below the threshold, a newer request has arrived, the timer fires more than a minute late, the cached prefix has changed, or your rate-limit status is no longer “allowed”, for example near your limit.

What to do

• Come back within the hour, or start fresh. For a new task, a new conversation costs only its starting context; Claude can look up the old one if you refer to it.
• Mind scheduled prompts into idle sessions. A prompt sent into a large session after more than an hour usually means writing its context again. In our logs, automated prompts started about half of all cold resumes.
• Keep idle compaction on, and lower CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS (down to its 100K floor) if your conversations usually stay under 200K tokens.
• Don’t wait for the warning on Opus 5.5. With the configuration we saw, it can’t appear on a Max plan. A 400K-token resume, if all of it is written to the one-hour cache, is about 1.5% of a Max 5x 5-hour limit by Claude Code’s own estimate, and $3.20 at list prices.
• Expect a summary when you come back. After idle compaction, Claude works from a summary of the older messages, with the most recent ones kept word for word; the full history stays in the transcript file, and the summary points Claude to it.

What we didn’t test

• Other people’s usage. All 355 cold resumes came from our own machine, and most from sessions we keep running on purpose. A developer who closes the terminal at night will see a different pattern.
• Why idle compaction didn’t run on our long-running sessions. We found no idle compaction in any transcript and couldn’t establish the reason.
• The usage meter. The shares above are Claude Code’s estimates from its downloaded configuration; the meter we can read reports whole percentages.
• Pro plans and other accounts. Our cached configuration had no Pro allowance, and other accounts may receive different values.
• Prices. Costs are Opus 5.5 list prices applied to all our traffic, including conversations from before its release on 22 September; subscription plans pay in usage, not dollars.
• More than one idle-compaction test. One pair of conversations on one machine, built from the same file, with the first comparison muddied by their shared cache.

Companion reading

• What agent traffic actually costs after Opus 5.5 — why cache writes, not reads, are most of an agent’s bill.
• Claude Code usage limits — how the 5-hour and weekly limits work.
• Claude Code context management — compaction, /clear and keeping contexts small.
• Running a fleet of long-lived agents — the setup that produced most of our cold resumes.
• Codex CLI’s background daemon, and what Claude Code leaves running — the long-running processes behind sessions like ours.

Sources

1. Anthropic — Claude Code changelog, entries for 2.1.299, 2.1.302 and 2.1.304. Retrieved 25 October 2026.
2. npm — @anthropic-ai/claude-code, publish times for 2.1.299 (14 October 2026, 00:23 UTC), 2.1.302 (16 October, 16:48 UTC) and 2.1.304 (19 October, 19:47 UTC).
3. Anthropic — Claude Code: Prompt caching, “Which TTL each request gets” and “Choose the TTL yourself.”
4. Anthropic — Prompt caching, cache-write multipliers and the 5% read rate on Opus 5.5.
5. Anthropic — Claude Code: Settings reference, idleCompaction: its conditions and the “Compacted while idle, before the prompt cache expired” notice.
6. Anthropic — Claude Code: Environment variables, CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS.
7. Anthropic — Set up Claude Code, “Auto-updates.”

Our own measurements, on one macOS machine on 25 October 2026: every main-conversation transcript under ~/.claude/projects up to 19:18 UTC (46 conversations, 7,121 distinct requests from 10 July); the warning’s text and logic in the Claude Code 2.1.310 binary, and the idle-compaction code in 2.1.283; the configuration cached in ~/.claude.json; a resume of a 764K-token idle conversation in the terminal; and two 421K-token conversations on Claude Code 2.1.310, one with idle compaction on and one off, left idle twice.

FAQ

Why does resuming an idle Claude Code session use so much of my limit? On a Claude subscription within your plan’s usage, Claude Code caches the main conversation for one hour. Within the hour, the next request reads most of the context from the cache, at a twentieth of the input price on Opus 5.5. After a longer gap the entry may have been deleted, and the context is written to the cache again, at twice the input price. In our transcripts, 266 of 270 requests after a 5-to-60-minute gap read most of their context from the cache, while 355 of 357 requests after a gap of an hour or more wrote most of it again: a median of 365,288 tokens, about $2.92 at Opus 5.5 list prices.

When does Claude Code show the ‘Resume this conversation?’ warning? Claude Code 2.1.304 added it for Pro and Max plans. In the 2.1.310 code it is a client-side estimate: context tokens times a per-model rate, divided by the plan’s 5-hour allowance, shown only when Claude Code considers the cache expired or the model has changed, and the estimate reaches 5%. With the configuration cached on our account on 25 October, Opus 5.5 would need about 1.36 million tokens to reach 5% on Max 5x and 5.46 million on Max 20x, more than its 1-million-token window. On Max 5x, Fable 5.1 reaches it at about 300K tokens. The configuration is downloaded and can change.

What is idle compaction in Claude Code? It compacts a conversation that you’ve stepped away from, so your next message sends a summary instead of the whole conversation. The changelog announced it in 2.1.299: a conversation of 200K tokens or more, idle in an interactive terminal session for about 54 minutes, is compacted before its one-hour cache expires. It also needs auto-compaction on, the one-hour cache, feature flags reachable, and the computer awake at that point. CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS changes the 200K minimum, down to 100K, and "idleCompaction": false in settings.json turns it off. In our test on 2.1.310 it compacted a 421K-token conversation 54 minutes after the last request, in 7 seconds, for about $0.18 at list prices. On a second return, 2 hours 12 minutes after the first, it wrote 24,738 tokens to the cache ($0.20), while an identical conversation with idle compaction off wrote 409,710 ($3.28).

Why didn’t idle compaction help our long-running sessions? We don’t know. None of our transcripts records an idle compaction. Our long-running sessions had been running for about four weeks, on Claude Code 2.1.283 and 2.1.293, and after 2.1.299’s release they had 86 cold resumes with input contexts of at least 200K tokens. The 2.1.283 binary already contains idle-compaction code behind a feature flag, so their age alone doesn’t explain it.

How can I avoid paying for cold resumes? Come back within the hour, or start a new conversation for a new task instead of resuming a large old one; Claude can look up the previous conversation if you refer to it. Keep idle compaction on. If you send prompts into a large idle session on a schedule, an interval over an hour means the context is usually written again each time; in our logs, automated prompts, most of them scheduled checks, started about half of these requests.