[BUG] CLAUDE_CODE_DISABLE_1M_CONTEXT ignored in 2.1.156

For anyone met similar issues, setting below variables to settings.json temporarily work arounds this issue on my instance -

"CLAUDE_CODE_AUTO_COMPACT_WINDOW": 200000

This will explicitly bring back the previous behavior as if the model context is 200K

My environment: v2.1.156/Windows/Opus 4.8 with CLAUDE_CODE_DISABLE_1M_CONTEXT=1

After switching to Opus 4.8 this behavior seems to be working as intended on 2.1.156. Maybe the bug is limited to Opus 4.7? Edit: I also see sessions still doing the wrong thing on 4.8, so this still seems to be am issue.

Confirming this on macOS, and adding data: the regression is not limited to 2.1.156. I reproduced it on 2.1.156 and 2.1.157, both with claude-opus-4-8.

Environment

• OS: macOS
• Model: Opus 4.8 (claude-opus-4-8)
• Versions affected: 2.1.156 and 2.1.157
• export CLAUDE_CODE_DISABLE_1M_CONTEXT=1 set in shell profile, present in the session's environment

Confirmation the flag is actually set on the running process

The env var is genuinely inherited by the live session, this is not a "forgot to export" case:

$ ps eww -o command= -p <pid> | grep -o 'CLAUDE_CODE_DISABLE_1M_CONTEXT=[0-9]*'
CLAUDE_CODE_DISABLE_1M_CONTEXT=1

Reproduction (two independent sessions)

I measured total context per turn directly from the session transcript JSONL
(input_tokens + cache_read_input_tokens + cache_creation_input_tokens) and
checked for compaction boundaries with jq.

Session A (long-running, 2.1.156): total context climbed monotonically to ~760k tokens and stayed there. With the flag honored it should have compacted near 200k roughly three times over.

Session B (fresh, 2.1.157): I loaded a large file in chunks to force growth. Context climbed
99k -> 174k -> 175k -> 250k -> 274k with no interruption, and /context reports 273.8k / 200k (137%).

In both sessions, zero compaction events occurred:

# isCompactSummary / compact_boundary entries in the transcript:
$ jq -rc 'select((.isCompactSummary==true) or (.subtype=="compact_boundary")) | .timestamp' \
    ~/.claude/projects/<project>/<session-id>.jsonl
(empty)

A 200k-window model cannot physically hold a ~760k-token request, so the sessions are demonstrably running the 1M window despite CLAUDE_CODE_DISABLE_1M_CONTEXT=1. Expected behavior: the flag should force the 200k window and autocompact near the default threshold (~190k).

Related display bug

The same sessions also hit #63447: /context and the statusline hardcode context_window_size: 200000 for claude-opus-4-8, so the indicator clamps to "100% context used" (and here, a nonsensical "137% full / autocompact will trigger soon" that never fires) while the true 1M window is mostly free. The two bugs compound: the flag is ignored (true window is 1M), but the UI insists the window is 200k.

Workaround

Manual /compact is currently the only working way to cap context size, since the env var no longer constrains it.

Having to manually /compact all the time is getting to be really frustrating.

It might sound stupid, but I just gave this thread (and related mentions, such as BUG #63861 and #63015) to Claude, and it fix it for me. I confirmed this with several sessions now. Don't ask me how, but it did set all the suggested environment variables in settings.json and so on. Using /compact and/or /clear all the time was not a viable solution to me. I feel like it's a bug that was introduced with the 1M context window and conflicting logic. I hope it gets officially resolved soon, this could trigger a lawsuit because, with Claude, cost is proportional to context and being above 200K costs exponentially more. I'm just saying.

But this was Claude's summary/takeaway if it can help anyone:

Issue #63015 — Autocompact threshold reached but never fires (macOS, Max plan, v2.1.153, CLAUDE_CODE_DISABLE_1M_CONTEXT=1)

This one directly mirrors our situation. Key findings:

• Statusline correctly shows 100% context, but zero compact_boundary events appear in the JSONL
• Manual /compact still works — different code path
• Expected trigger: ~83.5% (~167K tokens); actual: never fires
• Suspected root cause: tengu_compact_cache_prefix = true GrowthBook feature flag — new prompt-cache-prefix-based compaction has a bug where the threshold detection

(working) is disconnected from the compaction action invocation (broken)

• Related to #17292 from earlier versions (same pattern, was closed as not-planned — now recurring)

Bottom line for us: Our CLAUDE_CODE_DISABLE_1M_CONTEXT=1 + CLAUDE_CODE_AUTO_COMPACT_WINDOW=200000 env vars are the right approach, but they may not be sufficient if the tengu_compact_cache_prefix feature flag is also affecting your Claude Code version. The trigger detection may still be broken at the dispatch level — a Anthropic-side bug, not a config issue.

Practical implications:

1. Do not rely on autocompact firing automatically — use /compact manually when context approaches 70%+
2. new-task-detector.py now provides proactive warnings before you hit that wall
3. Watch the statusline — when it shows 70%+, run /compact manually
4. Issue #63015 is open and active; follow it for a fix

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

What a joke. It's only inactive because Anthropic ignores customers.

How to become profitable as an AI company:

1. Create the "best" models
2. Create the best harnesses
3. Create a tokenizer that increases tokens by 30%
4. Remove the ability to auto-compact and reduce token count
5. Make the models default to 1 million tokens to print that money, yo
6. ?