[BUG] Internal quota probe sends model ID with literal `[1m]` suffix → 404 not_found_error
Environment
- Claude Code version: 2.1.173 (external, cli)
- Platform: macOS (darwin, arm64), Node v24.3.0
- Model:
claude-fable-5[1m](1M-context variant selected via/model) - Auth: claude.ai subscription (OAuth)
Description
While a 1M-context model variant ([1m] suffix) is selected, Claude Code's internal quota probe — a tiny non-streaming POST /v1/messages with the single user message "quota" — sends the model ID literally as claude-fable-5[1m]. The API does not recognize this ID and responds:
{
"type": "error",
"error": { "type": "not_found_error", "message": "model: claude-fable-5[1m]" },
"request_id": "req_011CbwyyprravS7yyPACCpq6"
}
Regular session requests are unaffected: the CLI correctly normalizes them to the base ID claude-fable-5 and passes the context-1m-2025-08-07 beta header. Only the quota-probe code path appears to skip this normalization, so the probe fails on every poll while a [1m] model is selected (observed several times per day), and the CLI presumably never receives fresh quota/rate-limit data in that state.
The bug is easy to miss because the probe fails silently — no user-visible error in the CLI.
How it was observed
Via a local logging proxy (ANTHROPIC_BASE_URL → localhost) that captures the CLI's request verbatim and forwards it unchanged to api.anthropic.com; the 404 above is the upstream response. The captured request is unambiguously the CLI's own (user-agent claude-cli/2.1.173, stainless/node headers).
Captured request (redacted)
Headers:
accept: application/json
authorization: Bearer [REDACTED]
content-type: application/json
user-agent: claude-cli/2.1.173 (external, cli)
x-claude-code-session-id: [REDACTED]
x-stainless-arch: arm64
x-stainless-lang: js
x-stainless-os: MacOS
x-stainless-package-version: 0.94.0
x-stainless-runtime: node
x-stainless-runtime-version: v24.3.0
anthropic-beta: claude-code-20250219,oauth-2025-04-20,context-1m-2025-08-07,interleaved-thinking-2025-05-14,redact-thinking-2026-02-12,thinking-token-count-2026-05-13,context-management-2025-06-27,prompt-caching-scope-2026-01-05,mid-conversation-system-2026-04-07
anthropic-version: 2023-06-01
x-app: cli
Body (relevant fields; non-streaming, no system prompt, no tools):
{
"model": "claude-fable-5[1m]",
"stream": false,
"messages": [{ "role": "user", "content": "quota" }]
}
Note that context-1m-2025-08-07 is present in anthropic-beta — the request would presumably succeed if the model ID were normalized to claude-fable-5 like regular session requests.
Steps to reproduce
- Select a 1M model variant, e.g.
/model claude-fable-5[1m](also reproduced earlier with the same pattern on other[1m]variants). - Run a session behind any logging proxy (or inspect request logs server-side).
- Observe the periodic quota probe (
messages: [{"role":"user","content":"quota"}]) fail with404 not_found_error: model: <id>[1m].
Expected behavior
The quota probe normalizes the model ID the same way regular requests do (base ID + context-1m beta header), or probes with a fixed known-good model ID.
Actual behavior
Every quota probe returns 404 not_found_error while a [1m] model variant is selected.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗