Claude Code's "Compacted while idle" message, explained: why it happens and how to turn it off

Since the end of September 2026, some Claude Code users have come back to a long session and found it had been summarized while they were away. The only trace is a one-line notice: "Compacted while idle, before the prompt cache expired." The conversation history they left behind has been replaced by a summary.

This is a cost-saving feature that Anthropic switched on without a changelog entry or documentation. As of October 12, 2026, neither the prompt-caching page, the context-window page nor the settings reference describes it, and the Claude Code changelog through version 2.1.296 (October 9) doesn't mention it. This explainer pieces it together from Anthropic's prompt-caching documentation, the code Anthropic ships in its published npm package, and the GitHub issues where users first reported it.

The short version

• What it is: if a large conversation sits idle, Claude Code compacts it about 54 minutes after your last activity, while the one-hour prompt cache is still warm.
• Why: compacting while the cache is warm is cheap. Coming back after the cache has expired means reprocessing the entire history at full price.
• Who gets it: sessions whose main conversation uses the one-hour cache, which by default means Claude subscribers within their plan's usage, and whose context is at least 200,000 tokens by default.
• How to stop it: add "idleCompaction": false to your settings.json (Claude Code 2.1.290 or later). This keeps normal auto-compaction at the context limit.

Why a cache deadline matters

Every time you send a message, Claude Code re-sends the whole conversation to the API: system prompt, project context, every earlier message and tool result. Anthropic's docs explain that prompt caching lets the API reuse the unchanged start of each request (the prefix) instead of reprocessing it, billing the re-read at a much lower cached rate.

Cached prefixes expire after a period of inactivity, and every request that hits the cache resets the timer. The API offers two lifetimes, five minutes and one hour. Claude Code requests one hour for the main conversation on a Claude subscription within your plan's included usage, and five minutes for API-key, usage-credit and cloud-provider users unless they set promptCacheTtl to 1h themselves. Anthropic's docs say the longer lifetime "helps when you leave a session idle and come back to it, because you skip the reprocessing an expired prefix costs."

The price gap is large. According to Anthropic's prompt-caching pricing:

Last verified: October 12, 2026

Return to a 400,000-token conversation after the hour is up, and the first request rewrites all 400,000 tokens. On Opus 5.5 that is a 2× cache write instead of a 0.05× read: roughly 40 times the cost of the same request with a warm cache. (Opus 5.5's base input price is $4 per million tokens; see our guide to the current Claude lineup.) Large contexts are common now that Opus and Sonnet offer 1-million-token windows, which our explainer on long-context recall covers.

What Claude Code does about it

Compaction replaces the message history with a summary. Anthropic's prompt-caching page explains why timing matters. Producing the summary is a separate request that shares the conversation's prefix, so "while the cache is warm, that request reads your prefix from the cache, so a mid-session /compact costs a fraction of what the context size suggests." After a break longer than the cache lifetime, the same summarization request "reprocesses the full history as uncached input."

Idle compaction acts on that difference. Rather than wait to see whether you come back after the cache expires, Claude Code summarizes the conversation just before the deadline, while doing so is still cheap. When you return, the next request only has to write the much shorter summary to the cache.

The idea came from users. In issue #66115, opened on June 7, 2026, a user asked for an "auto-compact on idle timeout to prevent cache expiry cost," with a configurable timer. Commenters on that thread worked through the trade-offs: a timer that fires after the cache has already expired makes things worse, accounts on the one-hour cache need a later trigger, and small sessions aren't worth compacting. A similar request is open for OpenAI's Codex CLI (openai/codex #40924, "Compact large idle sessions before prompt cache expiry"). It proposes an opt-in mode with a minimum context size and no compaction during active turns.

When it fires

Because Anthropic hasn't documented the feature, the conditions below come from the code in the Claude Code 2.1.296 package that Anthropic publishes on npm. The setting's description and the notice text are plain strings in that package; the rest is read from minified code. This is the shipped implementation, not a statement of Anthropic's intent, and Anthropic can change it, including through the server-side switch.

In that build, idle compaction runs only when all of these hold:

1. Anthropic has switched it on for you. A server-controlled flag sets the mode to off, log-only or compact, and the default in the code is off. That is why users saw the behavior start without updating their settings.
2. Auto-compaction is on. DISABLE_COMPACT, DISABLE_AUTO_COMPACT or autoCompactEnabled: false all disable it.
3. You haven't set idleCompaction to false.
4. The main conversation is on the one-hour cache. On a five-minute cache there is nothing to schedule.
5. The timer fires at 90% of the cache lifetime, which is about 54 minutes after the last request or reply on a one-hour cache. If the timer fires more than a minute late, or the cache is already cold, it does nothing.
6. The context is at least 200,000 tokens. CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS can raise that floor, and it can't go below 100,000.
7. Nothing else is happening. No turn is running, no newer request has been sent, the transcript hasn't moved on, another process isn't holding the session, and you haven't interacted in the last 60 seconds.
8. You aren't close to a rate limit.

User reports match these numbers. In issue #100277, a commenter running 2.1.294 reviewed three sessions and counted 11 "automatic" compactions. All 11 came after 53–56 minutes of inactivity, at 236,000 to 616,000 tokens, far below the 1-million-token window. In issue #101070, a 2.1.296 user on Opus 5.5 reports two idle compactions on October 10, at 207,910 and 225,866 tokens, each about 54 minutes after the last response.

Timeline

The package contents show when the code shipped, not when the server switch turned it on for any given account. The September 30 start date comes from user reports.

The backlash

Not everyone wants the trade. The author of issue #98747 runs about 20 parallel long-running sessions. On October 1 they reported that seven were compacted overnight after updating to 2.1.286, "none near the context limit." Each lost exact instructions, decision rationale and in-flight state, and they rebuilt the context by hand from the transcripts. They accept the cost logic but argue that for this workflow "the trade is backwards." They asked for compaction to be opt-in, or announced with a way to decline it.

Comments on #66115 split the same way. Some users called on-by-default idle compaction "actively destructive" and asked for it to be made opt-in. Another called it "awesome," pointing out that cold reads cost far more than cache reads.

Two practical problems have also surfaced:

• It's hard to tell apart from other compactions. According to #98747 and #101070, idle compactions were recorded with trigger: "manual" before 2.1.290 and with trigger: "auto" since then. To scripts, hooks and readers of the transcript, they look like a /compact you ran or a context-limit compaction. In #100277, users reporting a "premature auto-compact" bug on Opus 5.5's 1-million-token window appear to have been seeing idle compactions.
• Hooks can't single it out. The hooks reference lists only manual and auto as PreCompact and PostCompact matchers, so a hook meant for context-limit compactions also fires on idle ones (#101070).

How to turn it off, or tune it

Keep normal auto-compaction and opt out of idle compaction (2.1.290 or later). Add this to ~/.claude/settings.json, or to a project, local or managed settings file:

{
  "idleCompaction": false
}

The setting's description, as shipped in the package, reads: "Set to false to stop Claude Code from compacting a long conversation while the session is idle. Setting it to true does not turn idle compaction on." In other words, it can only opt you out. Whether you get the feature is still up to Anthropic's server-side switch.

Make it fire only on very large sessions. Set the CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS environment variable, for example to 500000. The code applies a minimum of 100,000. This variable isn't documented either.

Turn off all automatic compaction. In /config, turn off auto-compact (the autoCompactEnabled setting), or set DISABLE_AUTO_COMPACT=1. This is the fix most often shared on forums. On older versions it was the only one. It also stops Claude Code from compacting when you approach the context limit, so you'll need to run /compact yourself.

Use the five-minute cache. Idle compaction only runs on the one-hour cache, so FORCE_PROMPT_CACHING_5M=1 or "promptCacheTtl": "5m" also stops it. You give up the longer cache lifetime, though, which usually costs you more if you take breaks.

Downgrading doesn't reliably help. The notice and the server flag are already in the 2.1.284 and 2.1.285 packages, so an older version may still compact idle sessions when the server switch is on, and it has no idleCompaction setting.

Should you turn it off?

It depends on what you need from the session when you come back.

• Leave it on if you step away from big sessions and mostly resume the same task. You'll come back to a cheaper, faster session, and on a subscription that means less of your usage limit. Anthropic's docs already recommend compacting at natural breaks, and a nearly identical Resume from summary dialog is offered to Pro and Max users who resume a session that has been idle for over an hour and is over 100,000 tokens.
• Turn it off if you keep long-running sessions as working memory: detailed instructions, decisions and state that a summary might drop. Turn it off too if you run many sessions in parallel and check on them intermittently, or rely on hooks or transcript tooling that needs to know why a compaction happened.
• If you keep it on, put durable instructions where compaction can't touch them. Anthropic's context-window docs say project-root CLAUDE.md, unscoped rules and auto memory are re-injected from disk after any compaction. Instructions given only in the chat are summarized. Our guide to writing CLAUDE.md covers what belongs there.

One thing hasn't changed: compaction isn't free. The summarization request is a model call, so a session you never return to would have been cheaper left alone. Idle compaction bets that you'll come back.

What's confirmed, reported and uncertain

• Confirmed from Anthropic's documentation:
  • the one-hour and five-minute lifetimes and who gets which by default
  • cache pricing multipliers
  • that compaction is cheap while the cache is warm and expensive once it's cold
  • the autoCompactEnabled, promptCacheTtl and DISABLE_AUTO_COMPACT controls
• Confirmed from Anthropic's published package (2.1.296):
  • the notice text
  • the idleCompaction setting and its description
  • the CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS variable
  • the server-controlled switch
  • the 200,000-token default, the 90% trigger point and the conditions listed above
• Reported by users:
  • that the behavior began with 2.1.286
  • the trigger values recorded in transcripts
  • the timings and token counts of specific compactions
  • lost working context
• Unknown:
  • which accounts Anthropic has enabled it for
  • whether Anthropic plans to document it, change the defaults or add an "idle" trigger
  • whether it will reach API-key users who opt into the one-hour cache

Anthropic hadn't commented publicly on the feature as of October 12, 2026.