[BUG] CLI 2.1.145 sends literal "claude-opus-4-7[1m]" as model name on session resume, hits 404, silently falls back to 200K

Summary

Selecting "Opus 4.7 (1M context)" in the /model selector causes Claude Code CLI v2.1.145 to send claude-opus-4-7[1m] verbatim as the model name in the API request body on session resume. Anthropic API returns HTTP 404 (not_found_error: model: claude-opus-4-7[1m]). The CLI then silently falls back to bare claude-opus-4-7 (200K) for all subsequent traffic in the resumed session.

Environment

• OS: macOS 25.4.0 (Darwin), arm64
• Claude Code CLI: v2.1.145 (claude --version confirms)
• Plan: Max
• Reproduces: every claude --resume of a session that was originally created with 1M-context selection (or claude --continue). Also reproduces on /compact-triggered SessionStart hook execution path.
• No suppressing env vars set:
• CLAUDE_CODE_DISABLE_1M_CONTEXT — unset
• CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC — unset
• ANTHROPIC_MODEL — unset
• ~/.claude/settings.json has no model field set (selection persists elsewhere in CLI internal state).

Evidence (intercepted via local HTTP proxy at ANTHROPIC_BASE_URL=http://127.0.0.1:8787)

Request body

{
  "model": "claude-opus-4-7[1m]",
  "messages": [/* 1 message, ~9 tokens (probe request) */]
}

Request headers

anthropic-beta: claude-code-20250219,oauth-2025-04-20,context-1m-2025-08-07,interleaved-thinking-2025-05-14,redact-thinking-2026-02-12,context-management-2025-06-27,prompt-caching-scope-2026-01-05
anthropic-version: 2023-06-01
user-agent: claude-cli/2.1.145 (external, cli)
x-stainless-arch: arm64
x-stainless-os: MacOS
x-stainless-package-version: 0.94.0
x-stainless-runtime: node
x-stainless-runtime-version: v24.3.0

Note: context-1m-2025-08-07 beta header IS correctly included.

Response (HTTP 404)

{
  "type": "error",
  "error": {
    "type": "not_found_error",
    "message": "model: claude-opus-4-7[1m]"
  },
  "request_id": "req_011CbE6iCwMt41bR967dEEQG"
}

Confirmation: silent fallback to 200K

Across the same 24-hour window on this machine:

• 9 requests sent claude-opus-4-7[1m] → all returned 404
• 5697 requests subsequently sent bare claude-opus-4-7 → all succeeded

Each session resume produces exactly one 404 probe followed by ~hundreds of bare-name requests. The probe failure is invisible to the user — no error surfaces in the CLI; subsequent requests just use the 200K variant.

Steps to reproduce

1. Run /model and select "Opus 4.7 (1M context)" in a Claude Code CLI v2.1.145 session.
2. Exit the session.
3. Resume with claude --resume <session-id> (or just claude --resume and pick the session from the menu). Same behavior occurs when /compact triggers SessionStart hooks.
4. Inspect outgoing HTTP traffic to api.anthropic.com (or use a local intercepting proxy).
5. Observe first probe request body contains "model": "claude-opus-4-7[1m]" and receives 404.
6. Run /context — denominator is /200k, not /1m.

Root cause hypothesis

The [1m] suffix appears to be a Claude Code internal alias for the 1M-context variant. The CLI should strip the suffix before serializing the model field into the API request body, and rely on the context-1m-2025-08-07 beta header (which IS being sent correctly) to enable the 1M window on the bare claude-opus-4-7 model.

v2.1.145 appears to be sending the bracketed alias literally — Anthropic API does not recognize claude-opus-4-7[1m] as a valid model name.

Tested workaround that did NOT work

Tried the workaround from <https://github.com/anthropics/claude-code/issues/34143#issuecomment-4241018253>:

{
  "model": "claude-opus-4-7[1m]"
}

placed in ~/.claude/settings.json. After restart, behavior unchanged — /context still shows /200k and proxy logs confirm the same 404-then-fallback pattern. Possible I entered it incorrectly; happy to retry if there's a known-good schema.

Related issues

• #55504 ("Opus 4.7 ([1m] variant) capped at 200K context in Claude Code Desktop on Max plan") — potentially the same root cause from the Desktop surface. That report is currently flagged for auto-close as duplicate but no underlying issue has been closed/fixed; the API-level evidence in this report may help identify the actual mechanism.
• #50803 (--model flag silently drops [1m] suffix) — related, different code path. That report attributes the bug to launcher flag handling; this report shows the same [1m] corruption occurs through /model + --resume with no flag involvement.
• #53031 (silent direction swap to [1m] on 200K selection, v2.1.119) — opposite direction symptom, may share underlying alias-handling code.

What's unique in this report vs the existing ones

1. Raw API evidence — 404 status code, exact error message body, and request payload. Existing reports speculate about cause based on /context output; this one shows the API rejection directly.
2. Specific version — v2.1.145 (latest as of filing).
3. macOS CLI — existing reports are Windows or Desktop.
4. Resume-specific trigger — claude --resume and /compact SessionStart hooks both reproduce. Fresh sessions may not exhibit it (haven't tested fresh-session path exhaustively).
5. anthropic-beta header is correct — rules out beta-header malformation as cause; the bug is specifically in the model field serialization.

Happy to provide additional proxy captures, full request/response dumps, or test specific candidate fixes if helpful.