Tahir Nazir

Posted on Oct 28 Originally published at its-tahir.com

I checked my Claude Code transcripts: 'compacting early' was idle compaction

#ai #claudecode #productivity #programming

Originally published at its-tahir.com.

Last week two of my Claude Code sessions compacted at about 265K tokens on a 1M-token window. It looked like a regression, so I read the compaction records in my own transcripts. They told a different story, and it turns out 'Claude Code keeps compacting' is really four different problems with four different fixes. Has yours been compacting early too? I'd like to know which of the four it was.

If Claude Code compacted far below the limit after you'd been away, that's idle compaction, not a lower threshold: it summarises a 200K+ token conversation before its one-hour cache expires, and "idleCompaction": false turns it off. If it keeps compacting for other reasons, it's one of these, and each needs a different fix:

What you see	What it is	Fix
It compacted far below the limit after you'd been away	Idle compaction, not a lower threshold	`"idleCompaction": false` in settings.json
It compacts at the same low point every time, such as 200K	A small auto-compact window	`/autocompact auto`, or unset `CLAUDE_CODE_AUTO_COMPACT_WINDOW`
It compacts, refills within a few turns, then stops with `Autocompact is thrashing`	Something refills the context	`/context`, then read files in chunks or trim what loads at startup
`Prompt is too long` instead of compacting, or a cloud session that loops	An open bug	Resend the message, or start a new session
It never compacts and stops with `Context limit reached`	Auto-compact is off	Turn Auto-compact on in `/config`, or unset `DISABLE_AUTO_COMPACT`

Two commands tell you which one you have: /context shows what's filling the window, and /autocompact with no value shows the window your current model uses.

Last checked 28 October 2026, against Claude Code 2.1.312.

Four things look like 'Claude Code keeps compacting'. Match the symptom first, because the fixes don't overlap.

What my own sessions show

Before writing this I read the compaction records in this machine's Claude Code transcripts. Every compaction writes a compact_boundary line with its trigger and token counts, so you can see exactly when and why it ran. I read only that metadata, not the conversations.

Every normal auto-compaction fired at the limit, between 967,344 and 972,043 tokens, on versions 2.1.292 to 2.1.310. That matches the documented default for 1M-context models, "about 967K tokens".

Then on 27 October, in the VS Code extension on 2.1.310, two compactions marked "trigger": "auto" fired at 265,565 and 263,336 tokens. Read by token count alone, that looks like auto-compact kicking in at a quarter of the window. It wasn't. Both records also carried "precomputed": true, and both landed one to two seconds after I sent a message following a long break: about three hours the first time, about seven the second. That's idle compaction, which Anthropic has started rolling out to the VS Code chat panel and the desktop app's Code tab.

People hit the same confusion in GitHub issue #101067, which reported auto-compaction "at 281K to 845K tokens" as a regression. The reporter later confirmed every early compaction carried the line "Compacted while idle, before the prompt cache expired" and fired about 54 minutes after the last message.

To check your own, run this in a terminal (macOS, Linux, or Git Bash on Windows). It prints the trigger and size of every compaction in your saved transcripts:

grep -rh '"compact_boundary"' ~/.claude/projects/ | grep -oE '"(trigger|preTokens|precomputed)":[^,}]*'

On my machine it printed lines like "trigger":"auto" "preTokens":265565 "precomputed":true. Any precomputed: true entry is an idle compaction.

Cause 1: idle compaction, after you've been away

If the early compaction happened after a break, look for one of these notices:

Compacted while idle, before the prompt cache expired

Compacted using a summary written while you were away · turn off with "idleCompaction": false in settings.json

The first is the terminal's notice. The second appears in the VS Code chat panel and, inside a row labelled Claude Code notice, in the desktop app.

Idle compaction summarises a conversation of 200,000 tokens or more shortly before its one-hour prompt cache expires, so your next message doesn't pay to reprocess the whole history. It isn't a lower threshold, and changing the auto-compact window won't stop it. To turn it off:

{
  "idleCompaction": false
}

That needs Claude Code 2.1.290 or later. In the terminal, /config has an Idle compaction row from 2.1.302. The full guide to "Compacted while idle" covers the exact conditions, the new VS Code and desktop behaviour, and when it's worth leaving on.

Cause 2: a small auto-compact window

If it compacts at the same point every time, check the window. Run /autocompact with no value. In a report on issue #101067, the dialog showed Current setting for Opus 5.5: 1m tokens (default for this model), and pressing Esc left it unchanged. That 1M is the window. On 1M models, compaction triggers a little under it, at about 967K.

With no window set, Claude Code compacts at the model's context limit, with these exceptions from the model configuration docs:

Session	Compacts at
Native 1M models: the Fable models, Sonnet 5 and later, Haiku 5.5, Opus 4.7 and later	About 967K tokens
Those models with `CLAUDE_CODE_DISABLE_1M_CONTEXT=1`	The 200K boundary
Sonnet 4.6 and Opus 4.6 without extended context	The 200K boundary
A model ID Claude Code doesn't recognise, such as a gateway alias	The window it assumes for that ID
Cloud sessions	As the conversation approaches the model's limit

Four places can set a smaller window, from highest priority to lowest:

CLAUDE_CODE_AUTO_COMPACT_WINDOW environment variable. It overrides everything below, and while it's set, /autocompact only reports it.
--autocompact flag, for one launch: claude --autocompact 500k.
/autocompact <size>, saved for the current model under modelSettings in your user settings. Since 2.1.288 it's per model, so a window you set for Opus doesn't apply to Sonnet.
autoCompactWindow in a settings file, for every model.

All of them take 100K to 1M tokens, and Claude Code caps the value at the model's real window. To go back to the default for your model, run /autocompact auto, and unset the environment variable if you have one.

The environment variable reads numbers differently. In /autocompact and --autocompact, a bare 200 means 200,000. In CLAUDE_CODE_AUTO_COMPACT_WINDOW, 200 means 200 tokens, and Claude Code warns that it reads as 200 tokens, so Claude Code treats it as the 100k minimum. Write 200000, or 200k on 2.1.304 or later. Before 2.1.304, 200k silently set a 100K window, per that release's changelog.

Why CLAUDE_AUTOCOMPACT_PCT_OVERRIDE seems to do nothing. The variable sets the percentage of the window at which compaction triggers, from 1 to 100. It can only lower the threshold: values above the default percentage are ignored. And the docs say it "applies only in sessions that compact before the model's context limit". A default session compacts at the limit, so there's nothing for the percentage to apply to.

That's the long-running complaint in issue #63186. A commenter there found it only worked once CLAUDE_CODE_AUTO_COMPACT_WINDOW was also set, with the trigger at roughly the window times the percentage: a 500,000 window at 60% compacted at about 300K. If you want to compact earlier, setting the window directly is simpler.

Want it later, not earlier? On a 1M model you're already at about 967K. On a 200K model, the 200K boundary is the model's real limit, so there's no room to raise. If you use the settings builder on my tools site, it writes autoCompactWindow and the rest of settings.json for you.

Cause 3: "Autocompact is thrashing"

This is the full message:

Autocompact is thrashing: the context refilled to the limit within 3 turns of the previous compact, 3 times in a row. A file being read or a tool output is likely too large for the context window. Try reading in smaller chunks, or use /clear to start fresh.

Compaction didn't fail. It worked, and then the context filled straight back up, three times in a row, so Claude Code stopped instead of burning requests on a loop that isn't moving.

Run /context and compare the Messages row with the rows above it. That's the docs' own test, and it splits the problem in two:

Messages is the largest row: something in the conversation is refilling the window. Ask Claude to read the big file in chunks, a line range or one function, instead of the whole thing. Run /compact with a focus that drops the large output, like /compact keep only the plan and the diff. Move large-file work to a subagent, which has its own context window. To see how big a file is before Claude reads it, paste it into a token counter.
The other rows together are larger: what loads at session start leaves too little room to work. Trim it.

The message always blames "a file being read or a tool output", but the reports on GitHub show three other sources:

Re-injected instruction files. In issue #85489, no single file or output was large. A 248 KB set of .claude/rules/*.md plus CLAUDE.md was re-attached after each compaction, about 122K tokens in one turn on top of the post-compaction summary, which landed right back on the trigger. That session compacted 16 times in 1 hour 48 minutes. Smaller instruction files, or rules that load only when relevant, fix it.
A window too small for your fixed context. In issue #100932, a 100K autoCompactWindow with roughly 25K to 30K tokens of instructions and memory loaded every session left very little room. The session, and its subagents, thrashed after a few tool calls. The reporter also found the "3 turns" count model responses inside a tool loop, not your messages. If you've lowered the window, raise it.
An oversized MCP tool definition. In issue #102389, tool search pulled in an MCP tool whose input schema was about 2.99 MB. Every request went over the 1M limit, and because discovered tools survive compaction, the session couldn't recover. Fix or disconnect the server, then start a new session.

Two recent releases fix cases you might be hitting. 2.1.307 fixed "some 'Autocompact is thrashing' errors in turns that read many PDF pages, images or other large tool results". 2.1.309 fixed sessions compacting repeatedly after reading files under a very large nested CLAUDE.md. If you're behind, update first.

Cause 4: open bugs that look like compaction trouble

Prompt is too long instead of compacting. Issue #104494 traces this to the auto-compact check running before the turn's CLAUDE.md and memory attachments are added. The check sees room, the attachments push it over, and you get a local Prompt is too long without a compaction. Resending the same message usually works, because the second attempt counts the attachment and compacts first.
A cloud session that refills after every compaction. Issue #105086, opened on 25 October, describes claude.ai/code sessions where each compaction freed about 83K tokens and the window was full again three or four tool calls later, until the session ended. The same prompts ran fine in the local CLI. It's open with no fix, so in a cloud session, push your work early.
The session stops after compacting. In issue #104920, the session went idle after an auto-compaction instead of starting the work Claude had just announced. Type "continue".

Auto-compact not working: it never compacts

The opposite problem. If Claude Code hits the limit without compacting, check three things:

Is auto-compact off? "autoCompactEnabled": false in a settings file, or DISABLE_AUTO_COMPACT=1 in your environment. Either one keeps it off, and the other can't turn it back on.
Did you get Prompt is too long instead? That's the #104494 ordering bug above. Resend the same message.
Did you set only CLAUDE_AUTOCOMPACT_PCT_OVERRIDE? On its own it does nothing in a default session. Set a window as well, or use /autocompact.

Turning auto-compact off

You can, but you'll trade compactions for hard stops. Switch Auto-compact off in /config, which writes "autoCompactEnabled": false, or set DISABLE_AUTO_COMPACT=1. Both also turn off idle compaction, and /compact keeps working. When the window fills, Claude Code stops with:

Context limit reached · /compact or /clear to continue · auto-compact is off · /config to turn it on

DISABLE_COMPACT=1 goes further and disables /compact too, so /clear is the only way forward. Since 2.1.311 it can only turn compaction off from a settings file, not back on.

For most people the better move is narrower: idleCompaction: false if the problem is compactions after breaks, or a larger window if you lowered it.

Recent fixes worth updating for

Version	Fix
2.1.304	`CLAUDE_CODE_AUTO_COMPACT_WINDOW=200k` no longer silently sets a 100K window, and out-of-range values now warn
2.1.307	Fewer thrashing errors in turns that read many PDF pages, images or large tool results
2.1.309	No more repeated compaction after reading files under a very large nested CLAUDE.md
2.1.310	Compaction after a "Prompt is too long" error no longer keeps too much dense text such as base64 or SVG
2.1.311	Claude no longer sees stale CLAUDE.md and MEMORY.md right after a compaction
2.1.311	Standard-context sessions that ran over 200K tokens now compact instead of stopping with `Usage credits required for 1M context`
2.1.312	A subagent's `autoCompactWindow` can now lower the window set by `CLAUDE_CODE_AUTO_COMPACT_WINDOW`

Key takeaways

'Claude Code keeps compacting' is four different problems: idle compaction, a small auto-compact window, something refilling the context, or an open bug. /context and /autocompact tell them apart.
Compactions far below the limit after a break are idle compaction. The transcript marks them precomputed: true. Turn them off with idleCompaction: false.
With no window set, 1M-context models compact at about 967K tokens. A window set by /autocompact, autoCompactWindow, --autocompact or CLAUDE_CODE_AUTO_COMPACT_WINDOW makes it compact earlier; /autocompact auto resets it.
In CLAUDE_CODE_AUTO_COMPACT_WINDOW, 200 means 200 tokens. Write 200000 or 200k. CLAUDE_AUTOCOMPACT_PCT_OVERRIDE can only lower a window that's already set.
'Autocompact is thrashing' means compaction worked but the context refilled. If /context shows Messages as the largest row, read files in chunks; otherwise trim CLAUDE.md, rules and MCP tools.

FAQ

For the cost side of long sessions, why Claude Code uses so many tokens breaks down where usage goes, and the full list of Claude Code errors and fixes covers everything else. Keeping long-running agent sessions on track across compactions is part of the work I do: see recent projects.

FAQ

Why does Claude Code keep compacting?

Usually one of four things. Idle compaction summarises a 200K+ token conversation you left for about an hour, far below the context limit. A small auto-compact window, set with /autocompact, autoCompactWindow, --autocompact or CLAUDE_CODE_AUTO_COMPACT_WINDOW, makes it compact at the same low point every time. Something refills the context right after each compaction, which ends in 'Autocompact is thrashing'. Or you hit an open bug. Run /context and /autocompact to see which.

What does 'Autocompact is thrashing' mean in Claude Code?

Compaction worked, but the context refilled to the limit within 3 turns of the previous compaction, 3 times in a row, so Claude Code stopped retrying. The message blames a file or tool output, which is the usual cause, but re-injected CLAUDE.md and rules files, a small auto-compact window, or an oversized MCP tool definition can do it too. Run /context: if the Messages row is the largest, read files in chunks; if the other rows together are larger, trim what loads at startup.

What is the default auto-compact threshold in Claude Code?

With no window set, Claude Code compacts at the model's context limit. Models with a native 1M window, such as the Fable models, Sonnet 5 and later, Haiku 5.5 and Opus 4.7 and later, compact at about 967K tokens. Sonnet 4.6 and Opus 4.6 without extended context, and 1M models with CLAUDE_CODE_DISABLE_1M_CONTEXT=1, compact at the 200K boundary. My own sessions on 1M models compacted between 967,344 and 972,043 tokens.

How do I change when Claude Code auto-compacts?

Run /autocompact with a size such as /autocompact 500k, which saves the window for the current model, or /autocompact auto to go back to the default. You can also set autoCompactWindow in settings.json, pass --autocompact for one launch, or set CLAUDE_CODE_AUTO_COMPACT_WINDOW. The window must be between 100K and 1M tokens, and the environment variable overrides the others.

Why does CLAUDE_AUTOCOMPACT_PCT_OVERRIDE do nothing?

It can only lower the threshold, and it applies only in sessions that compact before the model's context limit. A default session compacts at the limit, so the percentage has nothing to apply to. Set an auto-compact window, for example CLAUDE_CODE_AUTO_COMPACT_WINDOW=500000, or use /autocompact directly, which is simpler.

How do I turn off auto-compact in Claude Code?

Switch Auto-compact off in /config, which writes autoCompactEnabled: false, or set DISABLE_AUTO_COMPACT=1. Both also turn off idle compaction and keep the manual /compact command. With it off, a full window stops the session with 'Context limit reached' until you run /compact or /clear. DISABLE_COMPACT=1 goes further and disables /compact too. To stop only the compactions after a break, set idleCompaction to false instead.

Why does CLAUDE_CODE_AUTO_COMPACT_WINDOW=200 not set 200K?

In the environment variable, a number with no suffix means that many tokens, so 200 is 200 tokens, which Claude Code raises to the 100K minimum. Write 200000, or 200k on Claude Code 2.1.304 or later. The /autocompact command and --autocompact flag are different: there, a bare number from 100 to 1000 means thousands.

Sources