opusplan downgrades plan mode to Sonnet past 200k — Claude Code regression (it previously auto-compacted at 200k and kept Opus)

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?

With --model opusplan on long sessions, two connected regressions show up in recent Claude Code versions:

1. New plans are generated by Sonnet once context exceeds ~200k. In plan mode, as soon as the session passes ~200k tokens, plan-mode responses are produced by Sonnet instead of Opus. The status bar reflects it (e.g. Sonnet 4.6 · 204.2k/200k — over 100% of the shown 200k), but nothing signals this is an opusplan downgrade rather than a deliberate choice. On the earlier Claude Code version — the one whose opusplan used Opus 4.7 for plan mode — plan mode stayed on Opus and did not downgrade.

2. Plan execution now runs on Sonnet with up to ~1M context. On the latest Claude Code version, after exiting plan mode the plan is executed on Sonnet with context allowed to grow up to ~1M. In previous Claude Code versions, plan execution ran on Sonnet capped at ~200k.

What Should Happen?

Plan mode under opusplan must stay on Opus — keeping Opus for planning is the entire point of the preset, so the switch to Sonnet should not happen at all, and the planning model should never be silently swapped mid-session.

Two ways to fix it:

• Restore the earlier Claude Code behavior: auto-compact at ~200k when running opusplan, so context never crosses the threshold and Opus is retained in plan mode.
• Or add an explicit opusplan[1m] preset that embraces the 1M window — Opus[1m] in plan mode (no downgrade to Sonnet) and Sonnet[1m] for plan execution.

Error Messages/Logs

Steps to Reproduce

1. claude --model opusplan on the current Claude Code version (opusplan uses Opus 4.8 for plan mode).
2. Grow a plan-mode session past ~200k tokens.
3. Plan-mode replies are now produced by Sonnet; status bar shows e.g. Sonnet 4.6 · 204.2k/200k.

(On the earlier Claude Code version — the one that used Opus 4.7 for plan mode — the same session auto-compacted at ~200k and stayed on Opus.)

Claude Model

Other

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.162

Platform

Other

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Regression across Claude Code versions: on the earlier Claude Code version — the one whose opusplan used Opus 4.7 for plan mode — context was compacted at ~200k in both modes. Plan mode therefore stayed on Opus (it never crossed the threshold), and execution ran on Sonnet capped at ~200k. On the current Claude Code version (opusplan now uses Opus 4.8 for plan mode) this 200k compaction no longer fires — execution runs on Sonnet with the full ~1M window, and plan mode, once context exceeds 200k, downgrades from Opus to Sonnet.

Mechanism (reverse-engineered from the bundled CLI JS — symbol names paraphrased, treat as a lead rather than gospel): the plan-mode model selector keeps Opus only while an "exceeds 200k tokens" guard is false; that guard compares the most recent assistant turn against a hardcoded 200000 literal. Once usage is no longer compacted below 200k, the guard trips and plan mode falls back to Sonnet.

Why this is counterintuitive: choosing opusplan is an explicit request for Opus-quality planning, yet the longer/more complex the session — exactly when Opus matters most — the more certain the fallback to Sonnet. The status bar shows the active model, but nothing connects it to an opusplan policy downgrade, so it reads as expected behavior.

After the downgrade the session continues on Sonnet with the ~1M window, so context keeps accumulating toward ~800k.

Workaround that restores Opus planning (re-creates the earlier Claude Code behavior): set CLAUDE_CODE_AUTO_COMPACT_WINDOW=200000 so context is compacted before the 200k guard trips. Note CLAUDE_CODE_DISABLE_1M_CONTEXT=1 alone is not sufficient — only the auto-compact window actually caps usage below the threshold.