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

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.

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.

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.

+1

+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%

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: https://github.com/anthropics/claude-code/issues/55504#issuecomment-4525687708. 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.