Auto mode classifier sends [1m]-suffixed model without the 1M beta header; HTTP 400 is reported as "temporarily unavailable"

Summary

When the session model carries the [1m] suffix (e.g. opus[1m]), the auto-mode safety classifier sends that same suffixed model ID without the context-1m-2025-08-07 beta header. The API rejects the ID, and Claude Code renders the failure as "<model> is temporarily unavailable".

The message is misleading: the model is not unavailable. It is serving the main loop in the same session, continuously, at the same moment the classifier reports it unavailable. This has led several reports to be triaged as capacity/outage issues when the cause is a malformed request.

Because auto mode fails closed, every classifier-gated tool is blocked — Bash, Edit, WebSearch, WebFetch, Task/Agent, Skill. Only Read/Grep keep working. In practice the session becomes unusable while the main model is perfectly healthy.

Root cause

From the 2.1.220 binary. The classifier request is built as:

y = {
  model: o,
  ...
  querySource: "auto_mode",
  extraBodyParams: $Md(o),
  extraBetas: BMd(n_(o))
}

and the beta builder is:

function BMd(e){ if(e!=="firstParty") return []; if(!DH()||!Yd()) return []; return [E9i]; }

BMd returns at most a single non-context beta. So model keeps the [1m] suffix while extraBetas never includes context-1m-2025-08-07.

The binary itself documents the consequence:

1m beta (the [1m] model suffix) for these models will be rejected with a 400

The 400 is then rendered by:

zrp(e.name, W.model, W.httpStatus, W.errorKind)
  -> `${t} is temporarily unavailable, so auto mode cannot determine the safety of ${e} right now...`

W.httpStatus is available at that call site but is not surfaced, which is why an HTTP 400 presents to users as a transient availability problem.

Reproduction

1. Set "model": "opus[1m]" in ~/.claude/settings.json (or /model -> Opus with 1M context)
2. Enable auto mode
3. Run any compound Bash command, e.g. uptime && sw_vers -productVersion

Result:

claude-opus-5[1m] is temporarily unavailable, so auto mode cannot determine
the safety of Bash right now. Wait briefly and then try this action again.

Reproduces consistently, not in bursts, for as long as the [1m] model is selected. Simple single-token commands sometimes pass (they can resolve without classification); compound commands fail reliably.

Configuration that does NOT work

Tested, each with a restart, all still producing the identical claude-opus-5[1m] error:

• CLAUDE_CODE_AUTO_MODE_MODEL=claude-haiku-4-5-20251001
• CLAUDE_CODE_AUTO_MODE_MODEL=haiku
• ANTHROPIC_BETAS=context-1m-2025-08-07

CLAUDE_CODE_AUTO_MODE_MODEL is declared in the env schema and appears structurally identical to env vars that do work (e.g. ANTHROPIC_DEFAULT_OPUS_MODEL), but it does not govern the failing request. Note the classifier is two-stage (xml_s1 / xml_s2 appear in its telemetry), so an override that reaches only one stage would present exactly this way.

There is no autoMode.model setting; the autoMode block exposes only allow, soft_deny, hard_deny, environment, and classifyAllShell.

Workarounds

Both are unsatisfying:

• Drop the [1m] suffix — restores auto mode, gives up the 1M context window
• Disable auto mode — keeps 1M, gives up auto mode

Permission allow rules only partially help: auto mode deliberately strips rules granting arbitrary code execution, explicitly including package-manager run commands, so a Rust/Node/Python workflow still routes most real commands through the broken classifier.

Suggested fixes

1. Strip the context suffix before the classifier request — the classifier does not need a 1M window for a short classification prompt. This looks like the minimal fix.
2. Or include context-1m-2025-08-07 in extraBetas whenever the model retains the [1m] suffix.
3. Surface the HTTP status in the error. A 400 reported as "temporarily unavailable" sends users into retry loops and causes these reports to be triaged as outages. Even (HTTP 400) in the message would have made this self-diagnosing.
4. Consider a manual-permission-prompt fallback when the classifier cannot be reached, rather than failing closed with no path forward.

Environment

• Claude Code 2.1.220 (latest published at time of filing)
• macOS, Apple Silicon
• Model: opus[1m]
• Auto mode enabled
• No autoMode customization; no classifyAllShell

Related

• #74351 — same symptom, currently framed as classifier failure "at scale"; this appears to be the underlying cause for [1m] users
• #38537 — closed, describes suffix inheritance into the classifier model; the suffix issue persists in 2.1.220 via the missing beta header
• #68437, #49535, #69726, #38618 — same user-visible error