claude --continue ignores ANTHROPIC_DEFAULT_OPUS_MODEL, resumes on 200K instead of configured 1M — wastes tokens on failed context load

Additional concern: wasted tokens on model mismatch

When --continue resumes a session that was originally on 1M context but loads it on 200K (due to the stored model issue above), the full conversation history is sent to the API and tokens are consumed — only to immediately hit "Context limit reached."

The user then switches to 1M via /model → Default, and the next prompt re-sends the entire conversation context to the 1M model. This means the conversation's context tokens are billed twice: once for the failed 200K attempt, once for the successful 1M attempt.

Since the user was originally on 1M and is merely trying to resume that session, this token waste is entirely avoidable. The --continue command should detect that the configured default (ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-4-6[1m]) differs from the stored session model and upgrade before sending any API calls.

Confirming this reproduces for us too — on a different platform and a newer build, so it's not macOS-specific or limited to 4.6:

• Claude Code v2.1.153, WSL2 on Windows 11. (Issue is tagged platform:macos, but we hit it on Windows/WSL.)
• Model: Opus 4.7 (claude-opus-4-7[1m]). New sessions correctly load "Opus 4.7 (1M context)". claude --continue / -r silently restores the bare 200K claude-opus-4-7 — the statusline drops the "(1M context)" label and the context gauge goes negative on a >200K transcript.
• In our case the resumed sessions were originally created on 1M (not stale pre-config sessions), and resume still drops the 1M variant — so the restore path appears to discard the [1m] extended-context flag regardless of the configured default. New chats need no override to get 1M; only resume breaks.

Manual /model → Default after each resume is the only workaround we've found. +1 for "upgrade to the configured default (or at least warn)".

Yes; this appears to be one of the consequences of a broader #63376

me too. Could you guys fix this bug ASAP? Thanks a lot.

Additional reproduction: opusplan mode + Databricks custom model names

Hitting the same root cause in a different scenario.

Setup:
ANTHROPIC_DEFAULT_HAIKU_MODEL=databricks-claude-haiku-4-5
ANTHROPIC_DEFAULT_OPUS_MODEL=databricks-claude-opus-4-7
ANTHROPIC_DEFAULT_SONNET_MODEL=databricks-claude-sonnet-4-6
settings.json → "model": "opusplan"

Steps:

1. Start a fresh session — works fine, resolves to databricks-claude-sonnet-4-6 for non-plan turns
2. /exit
3. claude -c to resume
4. Send any message → error: "There's an issue with the selected model (claude-sonnet-4-6). It may not exist or you may not have access to it."

Why: In opusplan mode, the sonnet leg stores the bare name claude-sonnet-4-6 in the session transcript. On resume, that bare name is used literally
— the ANTHROPIC_DEFAULT_SONNET_MODEL substitution is never applied — so the request goes out as claude-sonnet-4-6 instead of
databricks-claude-sonnet-4-6, which doesn't exist on our Databricks endpoint.

Same fix applies: session resume should re-apply ANTHROPIC_DEFAULT_* substitutions to any stored model name, same as initial model selection does.

Environment:

• Claude Code v2.1.x
• Windows 11
• Databricks-hosted Claude endpoint

Workaround: writing /model opusplan manually when resuming a session.

Still reproduces on v2.1.186 (macOS 26.5.1, arm64, standalone installer), and it turns out to be broader than "ignores the configured 1M id" — the default 1M selection itself is dropped on resume, even with no model configuration at all.

Minimal repro (no env vars, no settings.json model, no --model flag)

1. Fresh claude in an empty dir → /model shows option 1 "Default (recommended) — Opus 4.8 with 1M context" selected; statusline reads "Opus 4.8 (1M context)". ✅
2. Send one message so the session records an assistant turn, then exit.
3. claude --continue → /model now shows a new entry "Opus 4.8 ✔ (claude-opus-4-8)" selected = the 200k variant; the "(1M context)" label is gone. ❌ Working immediately hits "Context limit reached" on a large transcript.

So this is not limited to sessions created before configuring a 1M id (the original framing here): a session that started on the plain default 1M also drops to 200k on resume.

One nuance that explains why it looks intermittent: a session that has not yet produced an assistant turn (still "thinking" on its first reply) resumes correctly at 1M — there's nothing recorded to reconstruct from. Only sessions that have already completed at least one turn drop to 200k.

Not proxy-specific

Reproduces both on pure first-party (direct to api.anthropic.com) and through a custom ANTHROPIC_BASE_URL.

Likely mechanism

The session journal only ever stores the bare response model id claude-opus-4-8 (never the [1m] suffix). On resume the model is reconstructed from that bare id and treated as an explicit 200k pick, so the 1M-context selection is lost. (Consistent with #64771 / #63376 and the closed-then-regressed #60548.)

Automatable workaround

If you wrap or script Claude Code, launch the resume with --model default:

claude --continue --model default

The --model flag uniquely (a) resolves the default alias to the current 1M default (claude-opus-4-8[1m]) and (b) overrides the reconstructed session model. Notes from testing:

• ANTHROPIC_MODEL=default does not work — it's taken literally as a custom model named "default".
• --model opus resolves to the 200k plain variant, not 1M.
• --model default is version-agnostic, so it keeps tracking the recommended default across model updates.

update your config ~/.claude/settings.json maybe work also : @Gab-CosmoLabs @ANogin

    "ANTHROPIC_MODEL": "aws.claude-opus-XX",

more info: https://thinkycx.me/files/notes-pub/2026-07-09-claude-code-resume-model-bug-analysis-en-pub.md