claude-code - 💡(How to fix) Fix [BUG] Model picker shows Opus 4.7 (200K) but session silently runs in 1M context — burned 18% of 5-hour Max limit on a small prompt [2 comments, 3 participants]

Preflight Checklist

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

What's Wrong?

Claude Code's model picker and runtime context window are out of sync. The picker shows Opus 4.7 (the 200K context variant) selected with a checkmark, while the session is actually running in 1M context mode. The context window indicator confirms this by showing /1.0M instead of /200k.

There is no warning, no banner, no indicator on the picker itself that the session is operating in 1M mode. The user believes they are in 200K because that is what the picker says.

The cost of this desync is severe. A single small orientation prompt, the kind of lightweight "remind me where we left off" message that should consume a trivial slice of plan usage, burned 18% of a 5 hour Max plan limit in one shot. That is roughly 5x the consumption rate the picker advertises, lost silently before any real work began.

Running /model claude-opus-4-7 (no [1m] suffix) repeatedly does not resync the runtime to the picker. The context window indicator continues to show 1.0M capacity. The only reliable workaround appears to be quitting and relaunching the app entirely.

The core defect: the model picker is not the source of truth for what is actually loaded, but it is the only signal the user has. This means plan usage can be drained at 5x the expected rate without the user's knowledge or consent, and standard recovery commands do not restore the intended state.

had blocked off a large part of my day for heavy work and was planning to use close to 100% of my 5 hour context window on that work. Instead, 18% was cut off the top before I typed a single letter, because of a UI bug that hid which model variant was actually loaded. That is real lost productivity on a paid Max plan, caused entirely by a defect in Claude Code, with no way for me to detect or prevent it in advance.

What Should Happen?

The model picker should always reflect the runtime state of the session. If Opus 4.7 (200K) is selected with a checkmark, the session must actually be running in 200K context mode, and the context window indicator must show /200k, not /1.0M.

If a session is running in 1M mode, that should be made obvious. The picker should show the 1M variant as the selected option, and there should be a clear visible indicator (a banner, a badge, a label on the picker itself) so the user knows their plan usage is being consumed at the higher rate.

Switching the picker from 1M to 200K should actually move the runtime to 200K. If that is not technically possible mid session, the app should refuse the switch and show an explicit message explaining why, instead of silently keeping the session in 1M while displaying the 200K selection.

Plan usage consumed during a state where the picker and runtime disagree should be refunded. A user cannot consent to 5x consumption when the UI is actively telling them they are on the 1x variant.

Error Messages/Logs

he session ran in 1M mode silently, with no warning, no log entry, no banner, and no indication in the model picker that the runtime did not match the displayed selection. The only visible signal of the issue was the context window indicator showing /1.0M instead of /200k, which I had to open manually to discover the bug existed at all. By that point, 18% of my 5 hour Max plan limit had already been consumed.

If there had been any error, warning, or visible log entry stating "session is running in 1M context despite 200K being selected," I would have caught this before doing anything that consumed significant plan usage. The absence of any error signal is what made this bug expensive.

Steps to Reproduce

1. Have a prior session that was running in 1M context mode (Opus 4.7 1M selected at some point).
2. Start a new Claude Code session, or resume the prior session.
3. Open the model picker. Observe that Opus 4.7 (the 200K variant, option 1) is selected with a checkmark, NOT Opus 4.7 1M (option 2).
4. Open the context window indicator at the bottom of the screen.
5. Observe the mismatch: the picker says Opus 4.7 (200K) but the indicator shows the session running with /1.0M total capacity instead of /200k.
6. Send any message that references prior conversation context, such as an orientation or "remind me where we left off" prompt.
7. Observe that plan usage jumps significantly more than expected for a message of that size, because the runtime is loading and billing at the 1M rate even though the picker advertises 200K.
8. Try running /model claude-opus-4-7 (no [1m] suffix) to force the runtime back to 200K.
9. Observe that the context window indicator continues to show /1.0M and the runtime stays in 1M mode.
10. The only reliable fix is to fully quit and relaunch the Claude Code app.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

Claude Code (desktop app session): 2.1.119

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

I use Claude Code on two platforms: the Claude desktop app on macOS and the CLI inside iTerm2. I do not know whether one installation is overriding the other, whether there is a compatibility issue between the two, or whether session state from one is bleeding into the other. I am flagging both platforms in case it is relevant to reproducing the bug.

Versions I am running:

Claude desktop app session: Claude Code 2.1.119, app build 1.4758.0 iTerm2 CLI: Claude Code 2.1.120 OS: macOS (Darwin 25.3.0) Plan: Max (5x).

Just did a little digging.

I use Claude Code on two platforms: the Claude desktop app on macOS and the CLI inside iTerm2. Both are running version 2.1.119, but they expose different model options.

In the desktop app, the model picker offers two separate Opus 4.7 entries: Opus 4.7 (200K context, option 1) and Opus 4.7 1M (option 2).

In the CLI, the picker only offers one Opus option: Default (recommended) Opus 4.7 with 1M context. There is no 200K Opus 4.7 entry. The CLI banner on launch also explicitly states the session is running in 1M context mode by default. A CLI user cannot select 200K Opus 4.7 even if they want to.

This is likely the root cause of the desync I reported. When session state is established through the CLI, the runtime is locked into 1M context. When that same session is then opened or referenced in the desktop app, the desktop picker displays Opus 4.7 (200K) as selected, because the desktop UI assumes the 200K variant is the default, but the underlying runtime is still in 1M from the CLI side. The picker becomes a lie about what is actually loaded.

Possible questions for the maintainers:

1. Why does the CLI not expose the 200K Opus 4.7 variant as a selectable option?
2. Is the CLI overriding the desktop app's session state, or vice versa, when both are active?
3. Why do two installations of the same Claude Code version (2.1.119) expose different model lists?
4. If 1M context is the only Opus option in the CLI, users on the CLI are being silently billed at the higher consumption rate without any way to opt down. That should be made explicit at minimum, and ideally a 200K option should be added to match the desktop app.