`/model` picker stores `opus[1m]` then next-turn validator rejects it as "may not exist" (Claude Max, Linux, `--resume`d session)

Preflight Checklist

• [x] I have searched existing issues — the two closest neighbours are referenced under Related issues below. Neither matches this surface exactly; my hypothesis that this is their interaction is unverified and I'm leaving that for the maintainers to assess.
• [x] This is a single bug report.
• [x] Claude Code 2.1.152.

What's Wrong?

In a session resumed with claude --resume <id>, the model started on the 200k Opus 4.7 variant despite ~/.claude/settings.json containing "model": "opus[1m]". To switch to 1M, I used /model and selected option 4 ("Opus (1M context)"). The picker confirmed:

Set model to opus[1m] for this session

The very next interaction errored with:

There's an issue with the selected model (opus[1m]). It may not exist or you may not have access to it. Run /model to pick a different model.

This is on a Claude Max account that does have 1M Opus 4.7 access (otherwise option 4 wouldn't appear in the picker). Re-running /model and selecting the default ("Opus 4.7 (default)" — the 200k variant) cleared the error and the session resumed on 200k.

Screenshot of the picker dialog, error banners, and /model recovery is attached as claude-model-bug.png below.

Steps to Reproduce

1. Claude Max account with 1M Opus 4.7 access.
2. ~/.claude/settings.json contains "model": "opus[1m]".
3. Resume an older session via claude --resume <session-id>. (The session in question was originally created while ANTHROPIC_DEFAULT_OPUS_MODEL was set to a 4.6 variant while diagnosing an unrelated issue; that env var is no longer set in the current shell.)
4. Observe via /model that the session is on the default (200k) Opus 4.7, not the configured opus[1m].
5. Select option 4 "Opus (1M context)". Picker confirms Set model to opus[1m] for this session.
6. Send any user message.
7. Observe the error banner: "There's an issue with the selected model (opus[1m]). It may not exist or you may not have access to it."

Expected Behaviour

Either:

• The picker's option 4 should store a model identifier that the runtime accepts and uses on 1M context, OR
• If opus[1m] is not the correct identifier in this context, the picker should not store it.

In neither case should the picker present and store a model ID that the next-turn validator rejects.

Actual Behaviour

The picker successfully stores opus[1m], and the next-turn validator rejects the same string as "may not exist or you may not have access to it." The banner reappears across several turns until the user runs /model again and chooses the default.

Environment

• Claude Code: 2.1.152
• Plan: Claude Max
• OS: Linux (Debian 13)
• Terminal: kitty (TERM=xterm-256color)
• ~/.claude/settings.json model field: "opus[1m]"
• ANTHROPIC_DEFAULT_OPUS_MODEL: not currently set in shell (was previously set during a past diagnostic session — see related issues)

Related issues (the maintainers can judge whether either or both are causally involved)

• #57576 — settings.json "model": "sonnet[1m]" is rejected by the UI ("not recognized") and falls back, even though the CLI --model flag accepts the same alias. Same [1m]-suffix-rejection family; settings.json surface rather than /model picker surface.
• #62962 — claude --continue ignores ANTHROPIC_DEFAULT_OPUS_MODEL and resumes on the model stored at session creation. If --resume shares that codepath, that could explain step 4 above (session resuming on 200k despite the current settings).

One plausible (but unverified) reading of the chronology: #62962 (or its --resume analogue) puts the session into a state where the user has to use /model to upgrade, then a #57576-family validator rejects the [1m] alias from the picker codepath the way it already rejects it from the settings.json codepath. That would make this report the interaction of the two, with the new evidence being that the [1m]-alias rejection isn't settings-only — the same validator (or an equivalently strict one) fires on /model-picker-stored values too.

I'm flagging this as a hypothesis only; if the maintainers know the codepaths involved and can confirm or refute it, that determines whether this should be closed as a duplicate of one of those issues or tracked as the picker-surface manifestation.

Screenshot

(see comment below)

----

Drafted by Claude Code (Opus 4.7, 200k context — this very session, after recovering from the bug). Hypothesis framing left deliberately tentative per reporter's request.