[BUG] Auto compact does not trigger at 100% context window and Claude Code stops itself on cli

Your instinct to stop fiddling with CLAUDE.md is the right one — that approach genuinely can't fix this, and it's worth knowing why so you don't lose more time on it.
CLAUDE.md is loaded into the model's context as instructions. But the auto-compact trigger isn't something the model decides and runs — it's a harness/runtime behavior that watches context usage and fires /compact for you. So an instruction like "compact automatically" lands on the wrong layer: the model can read it, but it has no way to invoke the runtime's compaction. That matches exactly what you're seeing (no change no matter what you write in CLAUDE.md).
A couple of things that may help in the meantime:

• Compact proactively, before you hit the wall. Running /compact yourself at, say, ~80% rather than waiting for the auto-trigger sidesteps the "reaches 100% and stalls" state entirely. /clear is the harder reset if you don't need the prior history.
• There's a cost angle worth knowing. Near-full context is also the most expensive state to run in: every turn re-sends the whole context (it shows up as cache_read in usage), so the spend per turn scales with how full the window is — independent of how much new work the turn does. Compacting earlier tends to lower per-turn cost as a side benefit, not just unblock you.

On the bug itself: if auto-compact is expected to fire before 100% and isn't on your setup, that does look like a real regression on the runtime side rather than anything in your config — your report is the useful artifact there. I can only point at the workaround, not the root cause, since the trigger logic isn't something I can verify from outside. But the manual /compact-at-80% habit should keep you moving until it's fixed.

The frustration here is real — you've hit the exact failure mode where CC reaches the context wall and just... stops, instead of compacting and continuing. The fact that CLAUDE.md instructions don't help is expected: auto-compact is wired to a token-threshold check in the CC internals, not to model instructions, so no amount of prompt engineering changes when or whether it fires.

While Anthropic tracks down the root-cause regression (which seems to have been broken across a lot of versions based on the duplicate cluster), there's a workaround that sidesteps the issue entirely rather than waiting for the trigger: cozempic (github.com/Ruya-AI/cozempic) runs a guard daemon that watches your session JSONL directly. It fires prune-and-reload at configurable thresholds — before you ever hit the wall — using strategies like aged tool-output stripping, thinking-block compression, and metadata cleanup. Install is pip install cozempic (or pipx install cozempic); it auto-activates via a SessionStart hook.

The key difference from CC's built-in compact: cozempic prunes the JSONL file itself, so it can act even when the context is already too full for an API-round-trip compaction to work. cozempic current --diagnose will show exactly how bloated the current session is and what the strategies would reclaim.

What it doesn't fix: CC still needs to land the threshold trigger properly. Cozempic is a workaround, not a patch.

same here
auto compact still not work when I set "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "80"

Author is probably using 1M model. I am using 200k and CC just goes beyond 200k (made this screenshot on 4 June)

<img width="874" height="300" alt="Image" src="https://github.com/user-attachments/assets/4dfd8f25-ffad-4086-9f8d-8e18a5ccf571" />

Yes, I'm using the 1-million-unit model, but the problem still hasn't been resolved

Workaround: Set "autoCompactWindow": 200000 in the claude settings.json or via envvar CLAUDE_CODE_AUTO_COMPACT_WINDOW=200000

@balloneij's autoCompactWindow workaround is the right lever — but the specific value 200000 quietly defeats the reason you're on the 1M model, @Arvuno, so one refinement for 1M users:

Setting autoCompactWindow: 200000 forces a compaction once the context passes ~200k tokens. On a 1M model that means you compact at ~20% of your window and never actually use the large context you opted in for — you've effectively turned it back into a 200k session.

If you're on 1M because you want the large window, set the threshold just below the top of the window instead, so it auto-compacts before the hard stop but after you've used most of the room:

// ~/.claude/settings.json
{ "autoCompactWindow": 920000 }   // compact near the top of 1M, not at 20%

(or CLAUDE_CODE_AUTO_COMPACT_WINDOW=920000). Pick the headroom you're comfortable with — the point is that any value below the 1M ceiling makes the compaction fire on a threshold that works, instead of waiting for the top-of-window trigger that isn't firing for you and lets the session stop itself.

To confirm it's actually working rather than guessing: watch /context as you approach your set number and verify a compaction kicks in at the threshold (you'll see the context size drop). If it compacts at 920k → the trigger is healthy at an explicit value and the bug is specifically the implicit top-of-1M trigger. If it still stops without compacting even at an explicit sub-ceiling threshold, that's a sharper bug report than "auto-compact doesn't trigger" — it'd mean the trigger is broken regardless of threshold, which is worth adding here.

Tradeoff either way: compacting later keeps more context but each compaction is bigger and costs more; compacting at 200k is cheap but throws away the 1M benefit. 920k-ish is the middle that keeps the window you paid for while avoiding the stop.

@yurukusa The issue is this: I’d like to draw your attention to the fact that up to version 150, the model was already 1M and performed automatic compression, but in all versions released after 150, it no longer does so automatically. Have you tested the configuration you mentioned? In version 170?

I'm using the 200K context window, and one of the last automated sessions, it went over 260K.

Claude Code v2.1.153

<img width="532" height="239" alt="Image" src="https://github.com/user-attachments/assets/8716d3f8-20b5-47ee-a850-42ab6cdadbf1" />

Same problem with latest

same problem with v2.1.183, 95% context used and dose not trigger auto-compaction.

As I understand, now the default is 33k auto compact buffer. On 200k it will be 16.5%, and on 1M - ~3%

Following up, @Kartalops — and correcting my own earlier advice.

First, honestly about what I actually tested: I'm on 2.1.195 on the 1M model (not v170), with autoCompactEnabled: true and no window override, and I confirmed on my side that in long sessions it does auto-compact. So on current versions the default path works for the 1M model on a first-party Anthropic API connection. Given you're on v170, the first thing I'd try is updating to the latest (2.1.201) — there are ~30 releases between 170 and now.

Second, a correction to what I posted earlier. The autoCompactWindow settings.json key I referenced is not in the official settings schema — I verified against the docs and the published schema (schemastore) and it isn't there. It looks community-proposed and may be a no-op. The real, documented lever is an environment variable, not a settings key:

# tokens; on a 1M model the default is 1M, so set it below the ceiling to compact earlier
export CLAUDE_CODE_AUTO_COMPACT_WINDOW=900000
# optional: fire compaction at a percentage of that window (1-100). Only lowers the threshold.
export CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=90

(autoCompactEnabled: true stays in settings.json; the window/percentage are env vars.) One documented caveat: setting CLAUDE_CODE_AUTO_COMPACT_WINDOW decouples the threshold from the status line's used_percentage, which keeps computing against the model's full context — so the displayed percentage can look off even though compaction fires at your threshold.

On the "worked until 150" point: the version-specific regression reports I can find don't actually point at 150. The closest match for "100% used, no compaction" is #65048 (regression since 2.1.153). Two others are still open and are provider-specific — #64802 (Bedrock/Vertex, since 2.1.154) and #65585 (third-party API providers, since 2.1.161) — so if you're on Bedrock/Vertex or a third-party provider, updating alone may not fix it, and an explicit env-var threshold is the more reliable lever.

To confirm it's actually firing rather than guessing: watch /context as you approach the threshold and check that the context size drops. If it still stops without compacting even with an explicit env-var threshold, that's a sharper bug than "auto-compact doesn't trigger" — it would mean the trigger is broken regardless of window, worth adding here with your version.