[BUG] Regression: long sessions no longer auto-compact before the context limit, silently crossing into the 200k–1M billing tier (desktop app)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Long Claude Code sessions in the desktop app no longer auto-compact before reaching the context limit. Context grows unchecked, crosses 200k tokens, and requests begin billing in the 200k–1M pricing tier at a higher per-token rate — silently, mid-session, with no warning and no obvious user-facing setting to prevent it.

This is a regression from the prior default, where auto-compaction fired before the limit and kept long sessions in the standard (≤ 200k) tier. The change appears undocumented and has a direct, unannounced cost impact.

Usage CSV line items confirming the tier crossover (single session, one day):

2026-06-06,Claude Opus 4.8,...,200k - 1M,input_cache_read,5.40,...
2026-06-06,Claude Opus 4.8,...,200k - 1M,input_cache_write_5m,2.63,...
2026-06-06,Claude Opus 4.8,...,200k - 1M,output,0.47,...

The 200k–1M premium portion of this session was ~$11. No prompt or warning fired when the session crossed the tier boundary; I only found it by auditing the usage CSV afterward.

What Should Happen?

Long sessions should auto-compact before reaching the context limit, keeping requests in the standard (≤ 200k) pricing tier — the long-standing default behavior. A user running a long session the way they always have should not silently be billed at the higher 200k–1M tier rate. If a session is about to cross into a higher-priced tier, there should be a visible warning.

Error Messages/Logs

Steps to Reproduce

1. Open a long-running session in the Claude desktop app (claude-desktop entry point).
2. Let the conversation context grow past 200k tokens without manually running /compact.
3. Observe that auto-compaction does not fire before the context limit.
4. Check the usage CSV (Console → usage export): requests appear under the 200k - 1M context-window tier at the higher rate.

Note: I could not identify a documented setting to prevent this. Setting CLAUDE_CODE_AUTO_COMPACT_WINDOW=180000 (via launchctl so the GUI app inherits it) does cap the window and restore early compaction — confirmed working — but this is an undocumented workaround a typical user won't find.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown — auto-compaction worked as expected in earlier versions, but I didn't record the exact last-good version

Claude Code Version

2.1.167 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Documentation / support gap: There does not appear to be a user-facing setting (in the app, config.json, or ~/.claude/settings.json) to re-enable auto-compaction or cap the tier in the desktop app.

The relevant environment variable could not be reliably identified even by support:

• A compaction-related variable was observed in the desktop session's launch environment, but I could not confirm it drives this behavior.
• Two Anthropic support agents each named a different variable (DISABLE_COMPACT vs. another), and neither matched what the installed claude binary actually references. Inspecting the binary, the variables it references are DISABLE_AUTO_COMPACT, CLAUDE_AUTOCOMPACT_PCT_OVERRIDE, and CLAUDE_CODE_AUTO_COMPACT_WINDOW. So the exact lever is unclear even internally — itself a documentation gap worth closing.

Terminal vs. desktop: Terminal claude does not appear to exhibit this — auto-compaction still works there. The regression seems specific to the desktop app's launch environment.

Requests:

1. Restore a user-controllable option to enable auto-compaction in the desktop app (ideally the prior default).
2. Add a visible warning before a session crosses into a higher pricing tier.
3. Document the compaction environment variables and which one governs desktop-app behavior.