[BUG] Internal quota probe sends model ID with literal `[1m]` suffix → 404 not_found_error

Open 💬 2 comments Opened Jun 11, 2026 by derDa75

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

  1. Select a 1M model variant, e.g. /model claude-fable-5[1m] (also reproduced earlier with the same pattern on other [1m] variants).
  2. Run a session behind any logging proxy (or inspect request logs server-side).
  3. Observe the periodic quota probe (messages: [{"role":"user","content":"quota"}]) fail with 404 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.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗