[BUG] compact

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/63015
2. https://github.com/anthropics/claude-code/issues/63896
3. https://github.com/anthropics/claude-code/issues/64911

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Same issue here.

Auto compact is enabled in my Claude Code config, but it does not trigger automatically during long sessions. The context keeps growing until warnings appear, and I still need to manually run /compact.

This is especially noticeable in large repositories and long coding sessions. Claude Code becomes less reliable near the context limit, and tasks may be left incomplete unless I manually compact the context.

Expected: auto compact should trigger automatically before the context becomes problematic.

Actual: no automatic compaction happens; only warnings are shown.

Would be great to clarify whether auto compact is currently supposed to run automatically in the latest CLI version, and what conditions/thresholds are required for it to trigger.

The same issue has remained unresolved from version 2.1.151 to the current version 2.1.169, severely impacting development functionality

My mind is boggled how this bug has not been fixed yet.

The frustration from @fashen007 and @MarcoCrankVRU about this persisting across versions is well-earned — it's been in some form since before 2.1.151.

What's actually happening at the architecture level: CC's auto-compact threshold fires at ~80% of the configured context window, but a recent build changed the default window for Sonnet 4.6 from 200K to 1M. That shifted the threshold from ~168K to ~800K. On plans without 1M usage credits, the session hits a credits error wall at the old 200K boundary before auto-compact ever runs — and the outer error message ("server is temporarily limiting requests") makes it look like an overload issue rather than the feature-gate issue it actually is.

Two things that help while Anthropic sorts out the threshold behavior:

1. CLAUDE_CODE_DISABLE_1M_CONTEXT=1 in your environment — forces the 200K window back, which puts the auto-compact threshold back at ~168K where it used to fire reliably.

1. For a guard that doesn't depend on CC's threshold being calibrated correctly at all: cozempic guard (github.com/Ruya-AI/cozempic) monitors the session JSONL directly and prunes it at a configurable percentage, regardless of which window CC thinks it's in. It works at the file layer rather than the API layer, so it fires even when the built-in trigger doesn't.

pip install cozempic
cozempic current --diagnose   # accurate token/context measurement independent of CC's own readout
cozempic guard                # auto-prunes at threshold; see --help for config

Neither workaround makes Anthropic fix the threshold behavior — but they do keep sessions from dying while you wait.

Looking forward to repairing it soon

@fashen007 Pretty sure this has been fixed. At least mine is now auto compacting again.

i hit the same bug where it silently tries a 1m context and freezes instead of doing auto compaction around 200k. ngl that sucks, fwiw wozcode cut my token spend ~50% with better caching https://wozcode.com

@fashen007 Pretty sure this has been fixed. At least mine is now auto compacting again.

which version ?

still happened in version (2.1.212)<img width="1830" height="122" alt="Image" src="https://github.com/user-attachments/assets/a959582a-74fb-4f8d-9b0d-3ee3833b850f" />

<img width="1858" height="102" alt="Image" src="https://github.com/user-attachments/assets/ca98260d-8576-430d-9017-37f14f30eded" />

Same issue，and it's more expensive with opus-5 ,please hurry up,guys.