[BUG] /model mid-session switch to Opus [1m] wrongly reports "not available for your account" — verdict depends on the current session's window flavor, not the account

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?

Summary

On a Claude Max plan whose account demonstrably serves Opus with 1M context, the /model slash command refuses to switch to claude-opus-4-6[1m] / claude-opus-4-8[1m] when the current session is running a 200k-window model, with:

Opus with 1M context is not available for your account. Learn more: https://code.claude.com/docs/en/model-config#extended-context-with-1m

The same command on the same account succeeds when the current session is already on a 1M-window model. The gate appears to key on the source session's context-window flavor, while the error message blames the account — which makes the message misleading and the behavior inconsistent with every other model-selection surface.

Environment

• Claude Code CLI 2.1.206 (latest at time of filing), observed identically on macOS (darwin, arm64) and Ubuntu VPS
• Claude Max plan (banner shows (1M context) · Claude Max when launching Opus [1m] directly)
• No --model flag, no ANTHROPIC_MODEL env in the failing sessions

Evidence matrix (all same account, same CLI version, same day)

| # | Current session model | Command | Result |
|---|---|---|---|
| 1 | claude-fable-5 (bare, 200k) | /model claude-opus-4-8[1m] | ❌ "Opus with 1M context is not available for your account" (reproduced ×3) |
| 2 | claude-fable-5 (bare, 200k) | /model claude-opus-4-6[1m] | ❌ same rejection |
| 3 | claude-fable-5[1m] (1M) | /model claude-opus-4-6[1m] | ✅ "Set model to Opus 4.6 and saved as your default…" |
| 4 | claude-fable-5[1m] (1M) | /model claude-opus-4-8[1m] | ✅ accepted |
| 5 | claude-fable-5 (bare, 200k) | /model claude-fable-5[1m] (same-family upgrade) | ✅ accepted |
| 6 | claude-sonnet-5 (native 1M) | /model claude-fable-5[1m] | ✅ accepted |
| 7 | — (startup) | claude --model 'claude-opus-4-6[1m]' | ✅ banner (1M context) · Claude Max |
| 8 | — (startup) | claude --model 'claude-opus-4-8[1m]' | ✅ works |
| 9 | — (settings.json "model": "claude-opus-4-6[1m]") | start session | ✅ ran a real session up to 812k context tokens over several days |

Rows 1–2 vs 3–4 isolate the variable: the only difference is the window flavor of the source session. Row 9 proves the account entitlement is real (an 812k-token context reading cannot happen on a 200k window).

Steps to reproduce

1. On a Max plan account that can run Opus [1m] (verify: claude --model 'claude-opus-4-6[1m]' shows (1M context) in the banner), start a session on a bare/200k model: claude --model claude-fable-5 (or claude-sonnet-4-6).
2. Send one message so the session has history.
3. Type /model claude-opus-4-6[1m] → rejected with the "not available for your account" message.
4. Now type /model claude-fable-5[1m] (accepted), then /model claude-opus-4-6[1m] again → accepted.

Same command, same account, opposite verdicts, 30 seconds apart.

Expected behavior

Either of these would be consistent:

1. /model <opus>[1m] succeeds from any source session (matching --model and settings.json behavior), or
2. If cross-family switching into [1m] from a 200k-flavor session is intentionally unsupported, the error should say that (e.g. "switching to a 1M variant requires restarting the session"), not claim the account lacks an entitlement it demonstrably has.

The current message sent us on a multi-hour false trail auditing plan entitlements.

Possibly related (adjacent, none identical)

• #50803 — --model/env with a plain model ID silently strips 1M
• #73423 — /model picker shows Fable 5 as disabled while --model claude-fable-5 works
• #70019 — /model does not display sonnet[1m]/opus[1m] despite availability
• #74433 — /model rejects an available model (stale cached emergencyTip hypothesis)

All look like symptoms of the same family: the window-variant/entitlement handling differs across the CLI's model-selection surfaces (startup flag / settings.json / /model command / picker).

Notes

• The transcript records the rejection as a type:"system", subtype:"local_command" event; the session is otherwise healthy.
• Happy to provide sanitized transcript excerpts.

What Should Happen?

Either of these would be consistent:

1. /model claude-opus-4-6[1m] (and claude-opus-4-8[1m]) succeeds from any source session — matching the behavior of the --model startup flag and the settings.json path, which both accept these models on this account; or
2. If cross-family switching into a [1m] variant from a 200k-flavor session is intentionally unsupported, the error should say that (e.g. "switching to a 1M variant requires starting a new session"), instead of claiming the account lacks an entitlement it demonstrably has.

The entitlement verdict for the same target model should not depend on which model the current session happens to be running — and if it must, the error message should blame the actual condition, not the account. The current wording sent us on a multi-hour false trail auditing plan entitlements.

Error Messages/Logs

Steps to Reproduce

1. On a Max plan account that can run Opus [1m] (verify: claude --model 'claude-opus-4-6[1m]' shows (1M context) in the banner), start a session on a bare/200k model: claude --model claude-fable-5 (or claude-sonnet-4-6).
2. Send one message so the session has history.
3. Type /model claude-opus-4-6[1m] → rejected with "Opus with 1M context is not available for your account."
4. Now type /model claude-fable-5[1m] (accepted — same-family window upgrade), then /model claude-opus-4-6[1m] again → accepted this time.

Same command, same account, opposite verdicts, 30 seconds apart — the only variable is the current session's window flavor. Full evidence matrix in the description above (9 combinations tested, including --model startup and settings.json paths which always accept, and a real 812k-token session on claude-opus-4-6[1m] proving the account entitlement).

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.206 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_