[Bug] Auto-compact never triggers despite statusline reporting "100% context used" (v2.1.153, Max sub, 200K mode)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/52390
2. https://github.com/anthropics/claude-code/issues/57627
3. https://github.com/anthropics/claude-code/issues/30400

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

Not a duplicate of the three issues the bot flagged. Different root cause, different version, different trigger condition.

#52390 (v2.1.118) and #57627 (v2.1.137) both depend on CLAUDE_AUTOCOMPACT_PCT_OVERRIDE being set in settings.json and not taking effect — i.e. the env-override path is broken. This report has no such env var set anywhere; the default auto-compact trigger itself is failing. Different code path.

#30400 (v2.1.63) is from March on a much older version and is accompanied by a stack of network/transport errors (HTTP 429, request-pipeline failures). This session has no such errors in the transcript — the client is healthy, the trigger dispatch is the only thing that doesn't fire.

Symptoms unique to this report that none of the three duplicates exhibit:

• v2.1.153 regression marker — same workload reliably triggered auto-compact on the version immediately prior.
• Built-in system statusline visibly reports "100% context used" while the session keeps growing past the buffer line. The client has clearly identified that the threshold was crossed; only the compaction action never runs. (Filed by /feedback, transcript attached server-side — Feedback ID 39674a54-5584-44fa-8656-6fbc7e51ab32.)
• Suspected root cause is the new tengu_compact_cache_prefix=true GrowthBook flag, which appears to introduce a cache-prefix compaction implementation. Manual /compact still works, presumably via the older code path. None of the three flagged issues mention this flag or this transition.

Please keep this issue open for separate triage. 👎 on the auto-duplicate notice to prevent the 3-day auto-close.

Your tengu_compact_cache_prefix hypothesis lines up with a broader pattern we've been tracking: GrowthBook A/B feature flags being sync'd from the server and overriding client-side behavior between releases, without changelog entries. The macOS Desktop variant was decisively traced by @amicicixp in #62205, where tengu_permission_friction and tengu_quill_harbor were observed flipping the user's settings.json permissions.defaultMode from bypassPermissions back to acceptEdits on a ~9-minute cadence. The compaction case you've identified looks like the same shape on a different surface (compaction dispatch vs. permission mode).

If you want to confirm whether the rollout group is your specific account, three reads might help:

1. Inspect the cached flag values directly. On macOS the GrowthBook cache is at ~/Library/Application Support/Claude/cachedGrowthBookFeatures (Desktop) and ~/.claude.json carries a smaller subset for CLI. Search for tengu_compact_cache_prefix — if it's present and value: true, you're in the experimental group. The bug shape you describe (statusline correctly identifies the threshold, dispatch never fires) matches a new-code-path failure rather than a config one, which is consistent with a flag-gated rewrite.

1. Watch the cache for re-sync. stat -f %m ~/Library/Application\ Support/Claude/cachedGrowthBookFeatures every 30s for ~15 minutes will show whether the file is being rewritten on the same ~9-minute cadence #62205 documented. If so, even if you manually delete the flag, it'll come back from the server.

1. Diff your session's compact_boundary events against transcripts from the prior version. Since the regression marker is precise (worked on v2.1.152, fails on v2.1.153), comparing a v2.1.152 transcript's compact_boundary event count vs. a v2.1.153 transcript of similar length is the cleanest local confirmation of the dispatch path being silent.

Operator-side, the surface for this kind of failure is unfortunately narrow — neither hooks nor settings.json overrides reach the dispatch path. The actual fix has to be upstream (flag rollback or dispatch-path fix). The only durable defense is monitoring: a Stop hook that watches token totals and surfaces a warning when usage crosses ~85% without a recent compact_boundary event in the transcript. That at least gives the operator the option to run /compact manually before exhaustion.

I've been tracking this broader GrowthBook-override pattern in cc-safe-setup's cluster tracker — your finding is a clean addition to the existing surface and I'll fold it into the cluster summary once #62205 gets the same level of confirmation from a second independent reporter. Thanks for the thorough write-up; the timestamps + token deltas table is the kind of evidence that makes triage tractable.

Shipped the Stop hook discussed above as PR #402: compact-dispatch-watchdog.sh (296 lines including 38 passing tests).

What it does:

• Stop hook. Reads transcript_path from input.
• Pulls the latest message.usage block, sums input-side tokens (input_tokens + cache_read_input_tokens + cache_creation_input_tokens).
• Computes ratio against a configurable window (default 200K, env-overridable to 1M).
• Scans the trailing 200 transcript lines for compact_boundary.
• When ratio ≥ 0.85 AND no recent compact_boundary is found, prints a one-screen stderr advisory citing this issue and Cluster 10. Exits 0 — never blocks.

It's exactly the operator-side surface we discussed: it moves you from silent exhaustion to a flagged threshold. It cannot dispatch compaction on your behalf (the dispatch path isn't reachable from any hook or settings.json override — same observation #62205 made for the permission-mode case).

To wire it in:

// ~/.claude/settings.json
{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          { "type": "command",
            "command": "$HOME/.claude/hooks/compact-dispatch-watchdog.sh" }
        ]
      }
    ]
  }
}

If you're running with CLAUDE_CODE_DISABLE_1M_CONTEXT=1 (200K mode, as your report shows), defaults are correct. Otherwise CC_COMPACT_WATCHDOG_WINDOW=1000000 for 1M mode. Threshold and lookback are configurable too — see the hook header.

I also folded the broader pattern into the cc-safe-setup cluster tracker as Cluster 10 in PR #401, with your finding and #62205 as the two representative issues and the five-override-path summary. The tracker is updated continuously as the cluster evolves — happy to add anything from your subsequent debugging if useful.

Thanks again for the precision in the original report; the tengu_compact_cache_prefix hypothesis + the timestamp/token table is what made building the hook well-scoped instead of speculative.

Also affected on v2.1.156 (macOS, GLM-5.1 model, 200K context)

Confirming this regression persists on v2.1.156 (latest as of 2026-05-29).

Environment

• Platform: macOS Darwin 25.5.0
• Claude Code: v2.1.156
• Model: GLM-5.1 (200K context)
• Subscription: Max
• Terminal: fish shell

Reproduction

1. Long session with heavy tool usage (MCP tools, file reads, contract compilation)
2. Context reaches 91% — /context shows "182.7k / 200k (91%)"
3. Statusline warning appears: Context is 91% full — Autocompact will trigger soon
4. Continue working — context crosses 95%, 98%, reaches 100%
5. Autocompact never fires. Session continues past the buffer limit
6. Had to manually run /compact to recover

GrowthBook flags from cachedGrowthBookFeatures

Relevant flags on my account:

• tengu_compact_cache_prefix: false (not in experimental group)
• tengu_sm_compact: false
• tengu_cold_compact: false

Key observation

The statusline correctly identifies the threshold is crossed and even displays the warning, but the compaction dispatch action never executes. This matches the hypothesis that the trigger detection code path works, but the new dispatch path (likely gated behind tengu_compact_cache_prefix) silently fails when the flag is off.

Manual /compact always works, confirming the compact engine itself is functional — only the automatic trigger is broken.

Workaround

Manual /compact when context exceeds ~90%. No env var override (CLAUDE_AUTOCOMPACT_PCT_OVERRIDE) has been tested as the default threshold should suffice if the trigger worked correctly.

@phpmac — thank you for the v2.1.156 data point, and for posting the GrowthBook flag values. You've refuted the flag-gated hypothesis I floated on 2026-05-28. I owe you and the thread a correction, and an updated read.

What your data point breaks

In my earlier comment I framed the failure as consistent with a flag-gated rewrite — tengu_compact_cache_prefix introducing a new dispatch path that silently fails when enabled. Your reproduction is the exact counterexample:

• All three relevant flags are false in your cachedGrowthBookFeatures (tengu_compact_cache_prefix, tengu_sm_compact, tengu_cold_compact).
• Same symptom: statusline correctly identifies the threshold crossed, dispatch never fires.
• Version is newer (v2.1.156, vs. the original v2.1.153 report).

If the bug were flag-gated, your "not in experimental group" reading would have left auto-compact working. It didn't. So either (a) the new dispatch path is now the default in v2.1.156 (and the flag became dead code), or (b) a different code path entirely is failing. Either way, "flag-gated" is no longer a useful model of this failure.

What stays load-bearing

Three pieces of the original analysis survive your reproduction:

1. The trigger detection works, the dispatch action doesn't fire. The statusline crossing 100% is the client correctly identifying threshold; the missing compact_boundary event in the transcript is the dispatch failing. The split between "detection" and "dispatch" is still the cleanest framing.
2. Manual /compact still works. This confirms the compaction engine is intact; only the auto-trigger path is broken. The break is in the dispatch layer, not the engine.
3. The cross-version progression is real. v2.1.153 (original report) → v2.1.156 (your data point). At least four releases in between (.154, .155, .156) didn't fix it. The regression is now persistent across the active release range.

Possible new hypotheses worth pinning

The GLM-5.1 angle in your reproduction is potentially significant and I want to flag it without overclaiming:

• Model-router specificity. GLM-5.1 routes through Claude Code's model-router rather than Anthropic's first-party path. If the auto-compact dispatch reads model metadata (max-context, prompt structure) before deciding to fire, the router's translation layer could be losing the field the dispatcher needs. Manual /compact would still work because the user explicitly invokes it without dispatch-layer gating.
• Quiet code-path divergence at the dispatcher. Your false flag values, combined with the symptom persisting, suggests the new dispatch code is now the active default (flags became no-ops). The bug would then be in the new code itself, not in the flag rollout.
• Subscription-tier × context-mode interaction. Both you and the original reporter are on Max subscription in 200K mode with CLAUDE_CODE_DISABLE_1M_CONTEXT=1. The dispatcher may have a path that misreads the window in this specific mode. Worth testing on Pro or with CLAUDE_CODE_DISABLE_1M_CONTEXT unset.

I don't think any of the three is decisive yet. They are testable hypotheses, not conclusions.

Diagnostic asks (if you can run them)

If you have the broken session's .jsonl handy, two reads would narrow this fast:

1. grep -c compact_boundary <session>.jsonl — confirm zero across the session (the no-fire signal).
2. grep -c '"type":"system"' <session>.jsonl | head -50 and inspect any compact_* or summary_* system entries — checks whether the dispatcher is being invoked but failing silently (writing an attempt entry but no boundary), vs. never being invoked at all. The first is a bug in the new code; the second is a bug in the trigger-to-dispatch wire.

If you can also share whether /feedback was sent during the failing turn (Feedback ID is fine without contents), the internal triage team can correlate the server-side logs.

The defense layer is unchanged

The compact-dispatch-watchdog.sh Stop hook from PR #402 still applies — it triggers off the symptom (token usage past threshold with no recent compact_boundary), not the flag state. Your reproduction confirms that targeting the symptom is the right scope; the underlying cause being unflag-gated doesn't change the operator-side surface (a stderr advisory at the threshold so the operator runs /compact manually).

I've updated the cluster tracker to reflect the refutation (PR #473, merged 2026-05-30):

• Removed the "flag-gated dispatch rewrite" framing from the cluster overview.
• Added v2.1.156 + GLM-5.1 + all-flags-false as the canonical counterexample, with cross-release (.153 → .156) and cross-model-path (first-party Anthropic + model-router via GLM-5.1) persistence noted.
• Updated the representative-issue entry to pin the dispatch layer rather than flag-rollout group membership as the failure surface.
• Clarified that the compact-dispatch-watchdog.sh hook's scope is unchanged because it targets the symptom, not the cause.

Thanks for the precision in your reproduction — it's the kind of evidence that prevents a wrong hypothesis from compounding. The flag-gated read was wrong; your data made it visible.

We hit the same 'statusline says 100% but auto-compact never fires' wall and ended up building cozempic (github.com/Ruya-AI/cozempic) for it. Its guard daemon tracks the real token count (summed from the usage frames, not the statusline estimate) and prunes + reloads when you cross a threshold — so you're not stranded at 100% waiting for a compaction that doesn't come. pipx install cozempic and it auto-runs. Curious whether it catches the exact case here — feedback very welcome.

@junaidtitan — thanks for surfacing cozempic, this is a much more developed answer to the problem than the watchdog hook I shipped. Looking at your README (319 stars, 50k+ downloads, 18 pruning strategies, guard daemon, MCP plugin route), you've built the intervention layer the hook side was missing. I want to articulate the relationship honestly so anyone reading this thread can pick the right tool for their case.
Layer 1 (detection-only, what compact-dispatch-watchdog.sh does): a Stop hook reads transcript_path, sums cache_creation + cache_read + input + output from the latest message.usage, checks for compact_boundary events in the last N turns, and emits a stderr warning when usage crosses a threshold (default 85% of the 200K window) without a recent boundary event. It does not touch the session. It does not prune anything. It just tells the operator: "auto-compact's dispatch path looks silent — your turn to act."
Layer 2 (intervention, what cozempic does): the guard daemon actively prunes bloat across 18 strategies (gentle 5 / standard 11 / aggressive 18), with compact-summary-collapse claiming 85-95% savings by removing pre-compaction messages already in the summary, plus Agent Teams checkpointing and behavioral-digest persistence so "don't do X" corrections survive the prune.
The hook gives the operator a signal; cozempic resolves the underlying state. If a user already runs cozempic, the hook is redundant — cozempic's pruning means they never sit at 100% in the first place. If a user is hook-only, the hook is the warning before they get stranded. The two compose: hook fires → operator sees the warning → operator triggers cozempic (or its treat route) instead of waiting for the silent dispatch.

• bash-only operators who don't want a Python install on the box.
• Read-only audit constraints (some teams' AI usage policy forbids any tool that modifies session state on its own; warnings are allowed, mutations are not).
• Diagnosing the dispatch path itself rather than working around it — a compact_boundary-event absence signal is what gets passed back to Anthropic for the underlying GrowthBook flag investigation.
• Already at 100% and stuck — the hook can't help here; cozempic's overflow recovery is what unstalls the session.
• Long-running Agent Teams — checkpoint-through-compaction is something a Stop hook simply cannot provide.
• Multiple-session users wanting consistent pruning policy across all sessions — cozempic's auto-init via SessionStart hook is the right shape, not 17 separate Stop hooks.
• **Anyone who wants the problem solved, not just signalled.**

When tengu_compact_cache_prefix was the working hypothesis (now refuted by @phpmac on v2.1.156 with the flag values reported), the hook's compact_boundary absence detection was the load-bearing signal. With the flag-gated hypothesis broken, the question is what cozempic's guard daemon is actually catching in the wild on v2.1.153–v2.1.156 — is it always the "dispatch went silent" case, or are there sessions where dispatch did fire but the resulting compaction was a no-op (kept the same context size)? If you have telemetry on the daemon's pre/post token deltas across versions, that data point would tighten the failure-mode catalog significantly.
Either way: I'm linking cozempic from the cc-safe-setup README and the relevant cluster-tracker entry as the recommended intervention layer for this failure mode. The hook stays as the detection layer for the narrow audit-only / bash-only / diagnose-the-bug-itself cases. No reason for the two to compete.
(Disclosure: I maintain cc-safe-setup and compact-dispatch-watchdog.sh is PR #402 there, ~296 lines incl. 38 tests. This thread is not a competition.)

Confirmed on v2.1.158 with GLM-5.1 (third-party proxy, 200K context)

Environment

• Claude Code: v2.1.158
• Platform: macOS Darwin 24.6.0
• Model: GLM-5.1 via Anthropic-compatible proxy (ANTHROPIC_BASE_URL=https://open.bigmodel.cn/api/anthropic)
• Context window: 200K (correctly detected — /context shows 78.6k / 200k)
• Subscription: Max

Reproduction

Had a long session editing a WeChat article (wechat-article-writer + de-ai-polish skills). The session grew to 4.4MB transcript, 219 user messages, 310 assistant messages with zero compact events. The session ended with:

API Error: The model has reached its context window limit.

Evidence from transcript

Analyzed the project session JSONL (33764457-005a-4c71-a2fc-75780eb3b8a8.jsonl, 1263 lines):

• Zero compact_boundary or compaction events in the entire session
• The session went from start to full context exhaustion without a single auto-compact trigger
• The only mentions of "compact" / "compaction" in the transcript are from the skills list descriptions, not actual compaction operations
• Manual /compact works fine in other sessions

/context output from a healthy session

glm-5.1
78.6k / 200k tokens (39%)

System prompt:    2k    (1.0%)
System tools:   13.7k   (6.9%)
MCP tools:      12.2k   (6.1%)
Custom agents:   576    (0.3%)
Memory files:    1.2k   (0.6%)
Skills:          9.6k   (4.8%)
Messages:       39.4k  (19.7%)
Free space:    121.3k  (60.6%)

Context window detection is correct. The issue is purely that auto-compact dispatch never fires.

GrowthBook flags (from cached features)

• tengu_compact_cache_prefix = true
• tengu_hawthorn_window = 200000
• tengu_hawthorn_steeple = false
• tengu_post_compact_survey = false

This aligns with the flag values reported by @phpmac on v2.1.156, further confirming the regression persists across v2.1.153 → v2.1.158.

Really appreciate the Layer-1/Layer-2 framing, @yurukusa — that's exactly right, and thanks for linking it from cc-safe-setup. Detection + intervention compose; nobody should have to choose.

On your question: the guard doesn't actually diagnose why auto-compact didn't fire. It sums the same components you do (input + cache_creation + cache_read + output from the last main-chain assistant frame) and prunes + reloads when that crosses a configurable threshold — so it catches both modes you describe (silent-dispatch and 'dispatch fired but the compaction was a no-op'), because it keys on the live token count, not on whether a compact_boundary event appeared. From the daemon's side they're indistinguishable; it just acts.

I won't overclaim telemetry: we don't track a per-version silent-vs-no-op split, so I can't give you that breakdown honestly — counters are aggregate (~191K prune cycles, ~16.5B tokens reclaimed across installs). The cleanest signal for your failure-mode catalog would be the per-cycle pre/post token delta, which we'd expose via the privacy-safe pruning receipt tracked in #101 — happy to make the delta part of that.

(Since you care about session safety: as of 1.8.18 the guard never rewrites a live transcript — it prunes only at the terminate→resume boundary, so it can't race the harness's writes.)

same issue confirm on 2.1.158 with kimi-k2.6 and deepseek v4 pro

I ran into this issue as well! What fixed it for me was disabling experimental betas in my settings.

You can do this by adding the following to your ~/.claude/settings.json file:

"env": {
"CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS": "1"
}

Seeing same behavior on 2.1.159 with standard models. Regularly stuck at 100% context usage and never auto-compacts. Seeing the same behaviors.

Has anyone confirmed if 2.1.160 fixes this?

Confirming on v2.1.158, with a downstream consequence worth noting

Additional data point: long session (9 hours, claude-sonnet-4-6, Max sub, 200K mode, macOS), with 3 successful manual /compact invocations throughout. The JSONL confirms compactMetadata.trigger: "manual" for all three — no trigger: "auto" event fired at any point in the session.

On the final context fill the user did not reach /compact in time, and auto-compact again failed to fire. Context grew to 270,582 tokens (135% of the 200K limit).

What happens next matters: once context crosses the 200K boundary without compaction, both continuation and manual /compact fail with:

API Error: Usage credits required for 1M context · turn on usage credits at 
claude.ai/settings/usage, or use --model to switch to standard context

The recovery tool is gated behind the same tier requirement that caused the overflow. The session is unrecoverable without starting fresh. Filed separately as #64911 (the /compact deadlock) and #64912 (the specific API error being silently replaced by a generic "Server is temporarily limiting requests" message in the UI).

Your suspected root cause (tengu_compact_cache_prefix) is consistent with what we see: three manual compactions completed normally, but the auto-trigger dispatch never fired.

Workaround: CLAUDE_CODE_AUTO_COMPACT_WINDOW works on v2.1.161

Environment: v2.1.161 (Linux WSL2), GLM-5.1 via third-party Anthropic-compatible proxy, 200K context.

Adding to ~/.claude/settings.json:

"env": {
  "CLAUDE_CODE_AUTO_COMPACT_WINDOW": "200000"
}

Confirmed effective — auto-compact now fires reliably at the threshold across 3+ sessions.

Why it works (traced from v2.1.161 binary): the dispatch guard is V6H() && !cc() && !x8$(). For third-party proxy users, cc() returns false (feature flag tengu_amber_redwood3 never served). Setting CLAUDE_CODE_AUTO_COMPACT_WINDOW makes x8$() return true (source becomes "env"), breaking the guard condition. No other env var (DISABLE_EXPERIMENTAL_BETAS, DISABLE_NON_ESSENTIAL_MODEL_CALLS) was needed to fix this.

终于找到正确的方法了
"CLAUDE_CODE_AUTO_COMPACT_WINDOW": "200000"
这个配置可以正常使用了

Reproducing on Linux too — Fedora 43, v2.1.160/161. Context hits 100% and just sits there, no auto-compact triggers.

Can confirm the CLAUDE_CODE_AUTO_COMPACT_WINDOW env var workaround works. Set export CLAUDE_CODE_AUTO_COMPACT_WINDOW=200k and auto-compact fires as expected.

Environment:

• Platform: Windows 11 Pro (10.0.26200)
• Claude Code version: 2.1.162 (CLI)
• Shell: PowerShell

Settings audit (nothing overriding autocompact):

• autoCompactEnabled: true in global ~/.claude/settings.json
• No CLAUDE_CODE_DISABLE_1M_CONTEXT or any context-related env vars set
• No project-level autoCompactEnabled overrides in any settings.json

Note: Running Claude Code CLI on Windows (not macOS like the original report) on v2.1.162, which is 9 versions past the reported regression in v2.1.153. Auto-compact has not visibly fired in long sessions. Flagging the Windows platform in case the regression scope extends beyond macOS or the fix hasn't fully landed cross-platform.

+1 — reproduced on v2.1.161 and v2.1.162.

• Platform: macOS Sequoia 15.7.7, Max subscription, 200K mode (CLAUDE_CODE_DISABLE_1M_CONTEXT=1)
• Models: both claude-opus-4-7 and claude-opus-4-8 affected
• Local session (not Remote-Control)
• autoCompactWindow was unset in ~/.claude/settings.json (the K__ short-circuit condition from #64520)

Same symptoms as OP: statusline pins at 100%, sessions grow well past 200k without auto-compact ever firing. Manual
/compact works fine. Compaction itself is intact, only the auto-trigger is broken.

~/.claude/daemon.log shows zero compact/autocompact entries across multiple stuck sessions.

Has now persisted across at least seven point releases (2.1.153 → 2.1.162)

<img width="2066" height="202" alt="Image" src="https://github.com/user-attachments/assets/3df71622-e5ae-4d17-884a-92468d968623" />

+1

Reproduzindo no v2.1.165 com subscrição Max. O autocompact não dispara mesmo com a statusline em 100%, forçando uso do /compact manual a cada sessão longa. A saída do autocompact quando acionado manualmente também está confusa.

Ambiente: Linux, claude-sonnet-4-6.

Still reproducing on v2.1.167 — new data: AWS Bedrock auth path + larger overshoot

Adds two things not yet in this thread: a newer version (the thread tops out at 2.1.165) and a distinct auth/model path (AWS Bedrock application-inference-profile, which isn't Max/OAuth, direct API, or a third-party proxy — relevant since the workaround analysis above turns on which feature-flag path the dispatch guard takes).

Environment

• Platform: macOS (darwin)
• Claude Code version: 2.1.167 (latest published)
• Model: Opus 4.8 via AWS Bedrock — model.id = arn:aws:bedrock:<region>:<account>:application-inference-profile/<id>, model.display_name = "Opus 4.8"
• Context window: 200K (context_window_size: 200000)
• autoCompactEnabled: not disabled anywhere (global/project settings.json, settings.local.json)

First-party evidence (raw context_window object from the statusLine stdin payload — Claude Code's own accounting, not a derived figure):

"context_window": {
  "total_input_tokens": 226947,
  "total_output_tokens": 189,
  "context_window_size": 200000,
  "current_usage": {
    "input_tokens": 2,
    "output_tokens": 189,
    "cache_creation_input_tokens": 2135,
    "cache_read_input_tokens": 224810
  },
  "used_percentage": 100,
  "remaining_percentage": 0
},
"exceeds_200k_tokens": true,
"version": "2.1.167"

Earlier in the same session I captured total_input_tokens: 645943 (~323% of the 200K window) from the identical payload source — larger than the worst figure documented above (135%). The session remained usable and used_percentage stayed pinned at 100 / remaining_percentage: 0 while running well past the window. Nearly all of it is cache_read_input_tokens.

Confirms the regression persists at least through 2.1.153 → 2.1.167, and now on the Bedrock auth path in addition to the Max/OAuth and proxy cases already reported.

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.

I’m one of the above reporters. Having now had the experience of having control over when the compact happens, I actually prefer the current (basically non-auto) behavior. Even if the old behavior is returned, I’d like the option to disable it, or at least to set the threshold of where the auto compaction fires. Previous to this, in any 200k session (ie Hakiu 4.5 or Sonnet 4.6), the indicator would go yellow and then I OFTEN did not get the opportunity to arrange matters for a compaction. Probably 50% or so of the time, the auto compaction would fire on the VERY NEXT turn. The other 50% or so it would fire very shortly thereafter, no more then 2-3 turns. Basically that was an enforced brick in the face, or watch it like a hawk (click to inspect before every turn?)

I am well aware that accuracy declines as the context window fills above 80% or so, but many of the “tidy up” operations necessary to continue operating smoothly AFTER the compact are both relatively inexpensive and also not very dependent on the context window accuracy. A skilled user can operate carefully at the margins and be quite successful. (I retrospectively analyze my logs on a routine basis, so I have a pretty good idea of how successful these operational experiments are.)

Closing — fixed as of approximately v2.1.126.

Reporter confirmation (2026-06-10): auto-compaction has fired successfully multiple times in recent sessions on a Max subscription, including on 200K-context models.

The most likely fix is the v2.1.126 entry:

Fixed Opus 4.7 sessions showing inflated /context percentages and autocompacting too early — Claude Code was computing against a 200K context window instead of Opus 4.7's native 1M

The root cause (wrong context window size in compaction math) is the same bug with opposite sign depending on model: a 200K model computed against a 1M window never reaches the compaction threshold; a 1M model computed against 200K triggers too early. The v2.1.126 fix corrected the window-size lookup, resolving both failure modes.

Closing as fixed.

2.1.174 still not work

2.1.178 still not working on mac. Opus 4.8, 1M context disabled.