Claude Code's idle compaction: a summary instead of a cache rebuild

Long coding sessions are expensive in a specific way: the cost is not the next question, it is the hundreds of thousands of tokens of history sent with it. Prompt caching makes that history cheap to send again, but only while the cache is alive. Claude Code 2.1.299, published on 14 October 2026, added idle compaction: a large conversation left idle is summarised shortly before its one-hour cache expires, so coming back later doesn't mean paying to rebuild it. This article explains the trade, when it helps, and how to measure it.

What changed

The Claude Code changelog describes the feature in one line: "a 200K+ token conversation left idle for about 54 minutes is compacted before its one-hour prompt cache expires, so your next message doesn't reprocess it all." It applies in the terminal. The 200,000-token minimum can be changed with CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS, and "idleCompaction": false in settings.json turns it off. Version 2.1.302 added an "Idle compaction" row to /config and made "the notices shown after an idle compaction" say how to turn it off.

Two related changes followed within days, according to the changelog and the npm release history. Version 2.1.300 added cache_creation_5m_tokens and cache_creation_1h_tokens to the OpenTelemetry api_request event, splitting cache writes by lifetime. And 2.1.304, published on 19 October, fixed self-paced /loop wake-ups that were scheduled at the one-hour maximum and fired just after the cache had expired, which made them re-read the conversation uncached.

Why the cache's lifetime sets the bill

The prompt caching documentation gives the multipliers, relative to a model's base input price:

• a 5-minute cache write costs 1.25 times the base input price;
• a 1-hour cache write costs 2 times;
• a cache read costs 0.1 times on most models. A footnote on the same page sets it lower for the newest ones: "Cache hits and refreshes on Claude Opus 5.5 and Claude Sonnet 5.5 are priced at 0.05x the base input price", and Claude Fable 5.1 and Claude Mythos 5.1 are at 0.025 times.

While a session is active, each turn mostly reads from the cache, at a tenth of the input price or less, depending on the model. If the cache expires, the next turn sends the whole history again as new input and writes it to the cache again. On a one-hour cache, that write costs twice the base input price for every token of history.

Whether a session uses the one-hour cache depends on how it connects. The changelog shows a history of settings for this, such as ENABLE_PROMPT_CACHING_1H for API-key and cloud-provider users and, later, promptCacheTtl and subagentPromptCacheTtl to keep a one-hour cache on the main conversation while subagents use five minutes. Check which applies to your setup before you model costs.

The trade, with example numbers

Here is an illustration. The numbers are examples, not measurements: a 300,000-token conversation on a one-hour cache, left for lunch, and a compaction summary of 20,000 tokens. It assumes a model at the standard 0.1 times cache-read rate; the note after the list covers Opus 5.5 and Sonnet 5.5, which have a lower rate.

• Without idle compaction, the first message after the cache expires writes the full history again: 300,000 tokens at 2 times the input price, the same as 600,000 input tokens.
• With idle compaction, the compaction request reads the history from the still-live cache, 300,000 tokens at 0.1 times, the same as 30,000 input tokens, plus the output tokens of the summary. The next message then starts from the summary. Writing 20,000 tokens of it to a one-hour cache costs the same as 40,000 input tokens.

On Opus 5.5 or Sonnet 5.5, where cache reads cost 0.05 times, the compaction read falls to the equivalent of 15,000 input tokens, so the gap between the two paths is wider still.

On those assumptions the return trip costs a fraction of the rebuild, before counting the summary's output tokens. The saving grows with the size of the conversation. The changelog sets the feature's minimum at 200,000 tokens, though it doesn't say why that figure was chosen.

There are costs on the other side.

• Compaction runs whether or not you come back. A session abandoned at 5 p.m. still pays for one compaction at about minute 54. For people who leave many large sessions open and never return to them, the feature adds spend instead of saving it.
• A summary is not the history. After compaction, the model works from a summary of what happened, not the full transcript. Details it didn't keep, such as an exact error message or a decision made two hours earlier, are gone from the context. The changelog for these versions includes several fixes for compaction losing recent messages or summaries in particular resume paths, a reminder that this is delicate machinery.
• Timing interacts with other features. The /loop fix in 2.1.304 shows how close to the cache boundary these schedules run. Anything that wakes a session near the one-hour mark can land on either side of it.

Seeing it in telemetry

Claude Code's monitoring documentation lists the fields you need on the api_request event: input_tokens (which excludes tokens read from or written to the prompt cache), cache_read_tokens, cache_creation_tokens, cost_usd, and query_source, the subsystem that issued the request, with "compact" given as one of its example values. That makes compaction requests separable from ordinary turns.

The new split fields, cache_creation_5m_tokens and cache_creation_1h_tokens, appear in the changelog for 2.1.300 but were not on the monitoring page when we checked on 20 October 2026. If your collector has a fixed schema, add them explicitly. They matter because a one-hour write costs 1.6 times a five-minute one, and a single "cache creation" number hides which you paid for.

We covered the wider picture in prompt caching as a cost control and in why the harness sets the bill. Idle compaction is a clear case of the second point: the same model, used the same way, now costs a different amount because the harness changed what it does while you are away.

What it means for engineering and security leaders

• Long idle sessions are a cost pattern worth naming. Before this change, every return from a break could mean a full cache rebuild. Now it means a compaction, but only for sessions above the threshold.
• The default suits people who come back. Teams whose developers leave many large sessions open and abandon them may see little saving or a small increase. Measure before tuning.
• Context loss is a quality question. If developers report the agent "forgetting" after lunch, compaction is a likely cause. They can turn it off for work that depends on precise earlier context.
• Telemetry schemas need maintenance. New fields arrive in releases before they reach the documentation. Pin the fields you rely on and review release notes for new ones.

Practical takeaways

• Upgrade to Claude Code 2.1.304 or later to get idle compaction, the split cache fields and the /loop timing fix.
• In your telemetry, group api_request events by query_source and compare compaction requests with the cache rebuilds they replace.
• Add cache_creation_5m_tokens and cache_creation_1h_tokens to your collector and dashboards.
• Decide a team default: leave idle compaction on, raise CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS, or set "idleCompaction": false for people who rarely return to old sessions.
• Tell developers what the compaction notice means, and how to turn it off for a session where exact history matters.

SpanDock receives Claude Code's OpenTelemetry and shows every session, model call, token and dollar on its dashboard, as described in getting started. When a tool reports a cost itself, that figure is used; when it reports only tokens, SpanDock estimates the cost from a price catalogue and marks it as estimated, as the model proxy and budgets page explains. That is enough to compare the cost of sessions before and after a change like this one.