← blog··7 min read

Claude Code Now Compacts Your Session While You're at Lunch

Claude Code 2.1.299 added idle compaction: a session over 200K tokens that sits untouched for about 54 minutes gets summarized on its own. Here's why that interacts with the prompt cache, what it saves, and the one setting I'd check.

Kev Gary
Founder & Lead Instructor, Claude Camp

I keep one long Claude Code session open per client project. It's a bad habit and I know it, but the context it builds up (what we tried, what broke, why a file looks the way it does) is worth more to me than the tokens it costs. The part I never liked was the first message after a break. Come back from lunch, type one line, and the usage meter jumps like I'd pasted a novel.

This week's release changes that. Claude Code 2.1.299 (October 14) added idle compaction: a conversation over 200K tokens that has been idle for about 54 minutes gets compacted on its own. If you don't want it, you set "idleCompaction": false.

That's the whole feature. It's small, and it's the kind of small that quietly changes your bill, so it's worth understanding why it exists.

The thing that makes a lunch break expensive

Claude Code sends your whole conversation with every request. That sounds ruinous, and it would be, except for the prompt cache: the history gets stored, and later requests re-read it at a much cheaper rate.

The cache doesn't last forever. Per Anthropic's cost docs, the lifetime is an hour on a subscription. On an API key, or once you're drawing on usage credits, it's five minutes by default. After that, your next message is a cache miss, and the entire context gets reprocessed at full price.

So the picture of a long session looks like this:

Idle session, one-hour cachecache warmcache coldBefore: your next messagefull context reprocessed at full priceAfter: compacted at ~54 min idleshort summary, cheap to resume

The amber cursor is you walking away. Everything to the right of the hour mark is the zone where coming back costs you.

Why 54 minutes

The docs don't explain the number, so this part is my read, not theirs. Fifty-four minutes sits just under the one-hour cache lifetime. That timing fits a specific trick: compaction has to read the whole conversation to summarize it. The cost docs say it directly: compacting a large context "is itself a large request." Do that while the cache is still warm and the read is cheap. Do it after the cache expires and you pay full price to read it, then pay again to continue.

If I'm right, Claude Code is spending the last minutes of a warm cache to shrink the session, so the message you type after lunch resumes from a summary instead of a cold 200K-token reread. I haven't measured that against my own bills yet, so treat it as the likely design, not a confirmed one.

Two caveats from the docs that matter:

  • It only applies to conversations over 200K tokens. Short sessions are untouched.
  • The five-minute cache on API keys and usage credits is a different situation. A 54-minute timer can't beat a 5-minute expiry, so I wouldn't expect this to help much there.

What you lose

A summary is not the conversation. Anything compaction decides wasn't important is gone from the live context, and you won't be there to steer it, because you're at lunch. That's the real trade.

My own rule for long sessions is to keep durable facts out of the chat and in files: the decisions in CLAUDE.md, the running plan in a markdown file Claude re-reads. I wrote about that in how to write a CLAUDE.md. If your session's only copy of an important decision is a message from three hours ago, idle compaction is a good reason to fix that today.

If you'd rather control compaction yourself, turn it off in settings:

{
  "idleCompaction": false
}

You can also steer what survives by adding a "Compact instructions" section to your CLAUDE.md, which the cost docs describe: tell it to preserve test output and code changes, for example. I'd do that before disabling the feature. Disabling it means going back to paying for cold-cache reads.

The other change in that release, and it's the one that can bite

Same release, easy to miss. Per the changelog, MCP allow rules now match only the named server, so mcp__a no longer covers a__b.

If you wrote permission rules with a short server name and relied on it matching longer-named servers, some tools that ran without a prompt will now ask. That's the safer direction, and I'm glad for it. But it will look like a bug if you don't know about it. Here's the before-and-after in one picture:

allow rulemcp__aserver: aserver: a__bstill coverednow asks first

If a tool you trust starts prompting after you update, check your allow list for a shortened server name before you go looking for a bug.

What I'd do this week

  1. Run claude --version. If you're below 2.1.299, update.
  2. Open /usage and look at the prompt cache line. It shows your hit rate and whether the cache is warm or cold right now. That's your baseline.
  3. Read your own allow rules for any mcp__ entry that relied on prefix matching.
  4. Decide on purpose whether you want idle compaction. If you keep long sessions, I'd leave it on and move the important decisions into files.

If you want to see how I set up long-running Claude Code projects so a summary never loses anything that matters, that's most of what we cover in the live Claude Code program. Everything else you need for this update is in the changelog and the cost guide.

// keep reading

Related posts

← all postsPublished October 19, 2026