v2.1.92 regression: autocompact threshold reduced to 400k on Opus 4.6 (1M context)

Traced this through the npm package source (diffing cli.js between v2.1.91 and v2.1.92).

The autocompact window calculation function gained a new code path in v2.1.92 that checks a GrowthBook experiment called tengu_amber_redwood. When a user is enrolled in the experiment, the window is overridden to whatever value the experiment specifies (400k in this case), taking precedence over the model default but not over the env var or settings overrides.

v2.1.91 flow:

1. Check CLAUDE_CODE_AUTO_COMPACT_WINDOW env var → use if set
2. Check user settings → use if set
3. Fall through to model context window (1M for Opus 4.6)

v2.1.92 flow:

1. Check CLAUDE_CODE_AUTO_COMPACT_WINDOW env var → use if set
2. Check user settings → use if set
3. New: check GrowthBook experiment tengu_amber_redwood → use if enrolled
4. Fall through to model context window

There's already a post-compaction notification built into v2.1.92 that says:

compacted at 400k · override with CLAUDE_CODE_AUTO_COMPACT_WINDOW=1000000

Workaround: export CLAUDE_CODE_AUTO_COMPACT_WINDOW=1000000 overrides the experiment and restores the full 1M window.

Thank you. I can confirm that works. Seems an odd thing for Anthropic to randomly enforce when [1M] is a major advertising feature....

The 400K threshold regression is frustrating. Cozempic v1.6.11 works around it — the guard daemon proactively prunes at configurable thresholds (25%/55%/80%) so the session never reaches CC's autocompact trigger, regardless of what CC sets internally.

Auto-detects 1M context for Opus/Sonnet 4.5/4.6. 18 pruning strategies keep sessions lean. The guard runs automatically via SessionStart hook.

pip install cozempic && cozempic init

Adding another data point on macOS:

• Claude Code v2.1.92, native arm64 build at ~/.local/share/claude/versions/2.1.92 (Mach-O 64-bit executable arm64)
• Model: claude-opus-4-6[1m] (1M variant active in /model)

I have both of these set, verified present in the live claude process environment via ps eww -p <pid> | tr ' ' '\n' | grep CLAUDE_:

CLAUDE_CODE_AUTO_COMPACT_WINDOW=1000000
CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=80

Despite this, /context consistently reports Auto-compact window: 400k tokens and the bar fills against 400k, not 1M. The documented WINDOW=1000000 workaround from this thread does not restore 1M for me on v2.1.92. This appears to be a second failure mode beyond the experiment override @qozle traced — possibly the Math.min cap referenced in #31806, or a different code path on the native build.

Downgrading to v2.1.91 (kept locally as a sibling versioned binary) as a workaround. The downgrade did successfully restore the 1M autocompact window for me.

Confirming this regression persists three weeks later on the latest channel, now also affecting Opus 4.7 with the 1M context window — not just 4.6.

Environment

Claude Code v2.1.119 (running, latest channel, native install)
Commit: 6f6855483975
Platform: darwin-arm64
OS: macOS 26.4.1 (25E253)
Model: claude-opus-4-7[1m]
Plan: Claude Max

Channel state at time of report:
  latest: 2.1.119  (currently running, broken)
  stable: 2.1.112  (confirmed workaround — see below)

Symptom (identical to OP)

Opus 4.7 (1M context)
claude-opus-4-7[1m]
591.8k/400k tokens (148%)

Denominator is 400k, same as the OP's reproduction on Opus 4.6 in v2.1.92.

Note re. recent release notes

The official changelog states:

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

That fix targeted the 200K → 1M code path. The 400K cap described in this issue is a different value and is clearly not covered by it. The same symptom now reproduces across two model generations (4.6 and 4.7) and over twenty-five releases (v2.1.92 through v2.1.119), strongly suggesting the threshold derivation for [1m] variants has multiple unfixed branches.

Workarounds tried

• CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=90 — no effect (capped by Math.min, see #31806).
• Switching to stable channel (v2.1.112) via /config → Auto-update channel: stable → "Allow possible downgrade" → restored full 1M denominator. This is the only confirmed workaround.

Cross-platform / install-method note

This issue is currently labeled platform:linux, but the same symptom reproduces on macOS 26.4.1 (Apple Silicon) with the native installer, complementing the OP's Linux + npm/native testing. The bug appears to be in core threshold-derivation logic, not platform- or install-method-specific.

Related

• #50204 — different symptom (UI percentage / actual token mismatch on Opus 4.7 [1m])
• #50716 — Opus 4.7 capped at 200K in the VS Code extension
• #31806 — CLAUDE_AUTOCOMPACT_PCT_OVERRIDE cannot raise threshold above default (~83%)

i've watched this exact pattern play out three times now on the Max plan: silent server-side knob change, no release notes, and the only way to confirm is rolling back binaries on a second machine like you did. the autocompact threshold isn't the only one either. the rolling 5h window quota got tightened in late march, weekly limits showed up around the same time, and none of it landed in changelogs. the /context readout reads from a server-truth value, not anything baked into the binary, which is why 2.1.91 vs 2.1.92 makes it look client-side when really both versions just render whatever the server hands back. nice repro work though, two-machine A/B is the only way these get acknowledged.

Confirming CLAUDE_CODE_AUTO_COMPACT_WINDOW=1000000 workaround still works on v2.1.119 / Opus 4.7 [1m] / Windows

Environment

• Claude Code v2.1.119
• OS: Windows 11
• Model: claude-opus-4-7[1m]

Before (no autocompact-related env overrides set):
``
Opus 4.7 (1M context) · claude-opus-4-7[1m]
30.4k/400k tokens (8%)
Free space: 336.6k (84.2%)
Autocompact buffer: 33k tokens (8.3%)
`
No Auto-compact window:` line shown.

After adding CLAUDE_CODE_AUTO_COMPACT_WINDOW=1000000 to the env block of ~/.claude/settings.json and
restarting:
``
Opus 4.7 (1M context) · claude-opus-4-7[1m]
60.2k/1m tokens (6%)
Free space: 905.9k (90.6%)
Autocompact buffer: 33k tokens (3.3%)
Auto-compact window: 1m tokens
``

@jimovonz and all --> the solution proposed by @qozle saved my bacon.

It 100% worked for me. I implemented this fix in about 5 minutes and I'm back. I've tested it with concurrent sessions on multiple worktrees going deep into context windows, I've seen a session let me get to 70% of the session context without autocompact, all since updating last night. I'll keep pushing the session limit, but the fix is just so new I haven't had a reason/session that needed to go much past about 700k / 1m. Thank you Qozle!

Hi @jimovonz — adding a data point because I think this issue and #55504 / #47019 / #35677 / #34143 are all the same underlying defect, just observed at different "stuck threshold" values across CC versions.

Your v2.1.92 regression observed a 400K auto-compact trigger on Opus 4.6 with 1M context advertised. My v2.1.141 measurement on Opus 4.7 [1m] (Max plan, Windows 11) shows the trigger has regressed further to ~190K — and the math reveals why:

trigger = min(CLAUDE_CODE_AUTO_COMPACT_WINDOW_env, detected) × PCT_OVERRIDE
        = min(1_000_000, ~200_000) × 0.95
        = ~190_000

Verified live: my env is correctly WINDOW=1_000_000 and PCT=95. The trigger lands at ~190K because the detected value is ~200K, not 1M — i.e. the runtime is misreading the served window for the [1m] variant on Max.

If the same trigger formula applied at the time of your 400K report, then detected was ~420K (min(1M, 420K) × 0.95 = ~400K). Different detected value, same root mechanism: whatever computes detected is reading the served entitlement wrong, and the value it returns has drifted further from 1M with each successive version.

That's significant signal for Anthropic: this is not random regression noise, it's a progressively-worsening server-side entitlement misread.

Comprehensive 30-day evidence (607 compaction events, 99 of 114 multi-compaction sessions thrashing, worst session 29 compactions) is on the primary tracker #55504: https://github.com/anthropics/claude-code/issues/55504#issuecomment-4525687708. Raw 120KB JSONL available on request.

Parallel support@anthropic.com ticket filed framing this as Max-entitlement-not-delivered, since code.claude.com/docs/en/model-config#extended-context documents the 1M auto-upgrade.

Thank you for tracking the regression carefully — your specific version pin (v2.1.92 → 400K) is what makes the "progressively worse" pattern visible.

+1

Ainda ocorrendo no v2.1.165. O threshold reduzido em Opus sessions com contexto maior continua causando compactações prematuras e comportamento inconsistente.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.