Opus 4.6 (1M context): autocompact triggers at ~76K tokens — 92% of context window wasted #34332

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   area:core

   on Mar 14, 2026
2. yurukusa commented on Mar 14, 2026

   

   yurukusa

   on Mar 14, 2026

   More actions

   I've been tracking context usage across 471+ sessions with a context monitoring tool and can confirm the threshold behavior you're describing.

   What I've observed

   On 200K context, autocompact triggers around 150K tokens (~75%). The issue is that on 1M, the threshold doesn't scale — it still uses an absolute token count rather than a percentage of the window.

   Workaround: manual compact with monitoring

   Until this is fixed, you can prevent premature autocompact by running /compact manually at a point you choose. The trick is knowing when you're getting close to the threshold.

   A PostToolUse hook that tracks approximate context consumption:

   #!/bin/bash
   # PostToolUse — context usage estimator
   SIZE_FILE="/tmp/cc-ctx-$$"
   INPUT=$(cat)
   CURRENT=$(cat "$SIZE_FILE" 2>/dev/null || echo 0)
   NEW_BYTES=$(echo "$INPUT" | wc -c)
   TOTAL=$((CURRENT + NEW_BYTES))
   echo "$TOTAL" > "$SIZE_FILE"
   
   # ~4 chars per token. Adjust threshold for your window size.
   # 200K window: 300000 bytes ≈ 75K tokens (threshold zone)
   # 1M window:  1500000 bytes ≈ 375K tokens
   EST_TOKENS=$((TOTAL / 4))
   
   if [ "$EST_TOKENS" -gt 60000 ]; then
     echo "Context estimate: ~${EST_TOKENS} tokens. Autocompact may trigger soon."
     echo "Run /compact manually to control what gets preserved."
   fi
   exit 0

   This gives you a heads-up before the 76K autocompact fires, so you can /compact with intention rather than losing context to the automatic trigger.

   The real issue

   You're right that the threshold should be percentage-based. On 1M, compacting at 7.6% is actively harmful — you lose conversation history that you're paying for (both in the Max subscription and in the tokens already spent building that context). The 1M window's value is zero if compaction fires at the same absolute point as 200K.

   The CLAUDE_AUTOCOMPACT_PCT_OVERRIDE env var you suggest would be a straightforward fix. Even without that, a simple threshold = contextWindow * 0.75 in the compaction logic would resolve this for all window sizes.

   👍React with 👍1Reacted by TJ Ruff
3. junaidtitan commented on Mar 22, 2026

   

   junaidtitan

   on Mar 22, 2026

   More actions

   We built and open-sourced cozempic which prevents premature compaction — it runs a guard daemon that soft-prunes bloat at a configurable threshold (default 45% of context window) so you never burn compaction budget unnecessarily. Token thresholds auto-scale for 1M context. Feedback welcome.

   👍React with 👍1Reacted by TJ Ruff

   👎React with 👎1Reacted by Michael Shields
4. junaidtitan commented on Mar 26, 2026

   

   junaidtitan

   on Mar 26, 2026

   More actions

   This is Cozempic's core thesis. The JSONL session file accumulates a lot of token-heavy noise — tool output envelopes, progress bar ticks, repeated file reads, thinking blocks — that inflates the apparent token count without adding useful context. So autocompact fires at 76K when the meaningful content might be 20K.

   We built Cozempic to prune exactly this noise out of the JSONL. After treatment a session that was showing 76K often drops to 15-25K of real content. We use it internally on all our 1M context sessions and open-sourced it because this specific problem kept wasting 92% of the window.

   pip install cozempic && cozempic treat current -rx aggressive

   For 1M models you can also set: COZEMPIC_CONTEXT_WINDOW=1000000

   Curious what your token count looks like after a treatment — would be good data to share back here.

   👎React with 👎1Reacted by Michael Shields
5. okas commented on Apr 7, 2026

   

   okas

   on Apr 7, 2026

   More actions

   +1

   👍React with 👍1Reacted by TJ Ruff
6. TJ-NomoAI commented on Apr 28, 2026

   

   TJ-NomoAI

   on Apr 28, 2026

   More actions

   +1 for me. It didn't start happening to me until the last 2 days or so for me. Literally could get to 70%, sometimes 80%, before the first auto-compaction. Now, I'm having it happen to me at 30% routinely, even 20%
7. hiddenlayer1 commented on May 23, 2026

   

   hiddenlayer1

   on May 23, 2026

   More actions

   Hi @mackmother — adding a data point because I think your "76K trigger / 92% of 1M wasted" report and my situation are the same bug, and the math from my side may reframe what "92% wasted" actually means.

   Repro on my side: Claude Code Desktop v2.1.141, Windows 11, Max plan, Opus 4.7 [1m] selected (UI shows 1.0M). Auto-compaction triggers at ~190K, then cascades every turn after that.

   Trigger math, verified live (my env: CLAUDE_CODE_AUTO_COMPACT_WINDOW=1_000_000, PCT_OVERRIDE=95):

   trigger = min(WINDOW_env, detected) × PCT
           = min(1_000_000, ~200_000) × 0.95
           = ~190_000
   

   The only way that resolves to ~190K is if detected ≈ 200K. So the runtime is reading the served window as ~200K, not 1M.

   Applying the same math to your 76K trigger (with the same PCT=0.95): min(1M, detected) × 0.95 = 76K → detected ≈ 80K. That suggests the actual served window for your account at that time was ~80K, not 1M. From that lens, the "92% wasted" framing is technically right — but the more useful framing is "the runtime never had access to 1M in the first place; it was served ~80K and faithfully reported 92% of the advertised 1M as wasted."

   If true, the fix is not "raise the auto-compact threshold" (a client-side workaround we've tried — six client-side mitigations have all failed). The fix is "make the served window actually be 1M for Max-plan 1M-context models." That has to come from Anthropic's side.

   Comprehensive 30-day evidence (607 compaction events, 99 of 114 multi-compaction sessions thrashing, worst single session 29 compactions) on the primary tracker #55504: #55504 (comment). Raw 120KB JSONL available on request.

   Parallel support@anthropic.com ticket filed as Max-entitlement-not-delivered (the docs at code.claude.com/docs/en/model-config#extended-context promise Max auto-upgrades Opus to 1M).

   Thank you for the original report — the absolute-token framing (76K specific) is what made the math tractable.
8. rezzminator commented on Sep 26, 2026

   

   rezzminator

   on Sep 26, 2026

   More actions

   If what you're seeing is Claude Code asking to compact early, a plugin can refuse it. sub-agent-compact (disclosure: mine, MIT) holds every compaction back until the party reaches a point you set. With this, the main chat isn't compacted before ~600k on a 1M model:

   {
     "env": { "CLAUDE_CODE_ENABLE_FUNCTION_HOOKS": "1" },
     "pluginConfigs": {
       "sub-agent-compact@sub-agent-compact": { "options": { "mainAutoCompact": "600k" } }
     }
   }

   Install: claude plugin marketplace add rezzminator/sub-agent-compact, then claude plugin install sub-agent-compact@sub-agent-compact.

   Two honest caveats:

   • I haven't reproduced your 76K trigger. Set the logFile option: every compaction the plugin holds or lets through is logged with the context size, so you can check it's this path.
   • If the loss is tool results being cleared rather than a compaction (see [BUG] Silent context degradation — tool results cleared without notification on 1M context sessions this issue documents three separate mechanisms (microcompact, cached microcompact, session memory compact) #42542), a plugin can't stop that. Claude Code's own hard limit also still applies.