Auto mode classifier (claude-opus-4-8) repeatedly unavailable — blocks Bash/Write/Edit

[syk82]

Env: Windows 10, Claude Code v2.1.157, VS Code extension, Opus 4.8 (1M context), Claude Max

Symptom: In auto mode, tool calls fail with

claude-opus-4-8 is temporarily unavailable, so auto mode cannot determine the safety of Bash right now.

Bash/PowerShell/Write/Edit all blocked; only read-only ops pass.

/permissions → Recently denied tab is EMPTY (outage isn't logged as a denial), so there's no in-product trace of why work stalled.

Related: #62170, #49535, #39259.

Request: stabilize the classifier model, and/or improve fallback so a classifier outage doesn't silently block all work.

[jadams777]

Same issue here.

[pierremrtn]

same issue with opus 4.8

[ugurtarlig]

Same failure on Claude Max (20x), and I've eliminated every client-side cause by test — including the [1m] fix from #38537. The real error is a 429 rate_limit_error, not a model outage.

Environment: Claude Max (20x) · macOS (Apple Silicon) · Claude Code v2.1.177 (also reproduced on 2.1.173) · started ~2026-06-12 21:00 UTC, persisted 12h+.

The actual error. The UI text ("<model> is temporarily unavailable") is misleading. claude --debug api shows the classifier side_query getting a 429 rate_limit_error, retried 5× then fail-closed:

[auto-mode] context comparison: classifierChars=46622 (sys=46049 tools=85 user=488)
classifier_request_started reqId=… tool=Bash model=claude-opus-4-8[1m] stage=xml_s1
[API REQUEST] /v1/messages source=side_query        (x5 retries over 12s)
classifier_request_finished outcome=error durationMs=12187 errorKind=Error:429
  {"type":"error","error":{"type":"rate_limit_error"},"request_id":"req_011CbzrAP8gRHnJYqT3M9Nuj"}
Auto mode classifier unavailable, denying with retry guidance (fail closed)

This is not the plan quota — session was ~2% / weekly 0% at the time.

Everything ruled out by test:

Tested	Result
Plan quota	0% weekly — not it
Model: opus-4-8[1m], non-1M opus-4-8, sonnet-4-6	all 429 (so it's not just the [1m] passthrough from #38537 — non-1M fails too)
CC version 2.1.173 → 2.1.177	all fail
skipAutoPermissionPrompt removed (per #38618)	no change
OAuth token (full logout/login)	no change
System clock / NTP	in sync
Concurrent sessions / background API consumers	none; killed all — still fails
Network family: forced IPv4 (networksetup -setv6off)	still fails

Cross-machine smoking gun: the same Max account on a Hetzner server (different IP/region) runs the classifier fine (Allowed by auto mode classifier) at the same time the Mac consistently 429s. So it's account/region/edge-side, not the client, model, or my network.

The architectural issue (per @danmana, @DavidPluxia in #38537) stands: pinning the safety classifier to a single flagship model with no fallback turns any per-account/region rate-limit or capacity blip into a total auto-mode outage — and it fails closed silently (the /permissions "Recently denied" tab stays empty). "Fixed in v2.1.112" did not resolve it.

Asks:

1. Add a fallback classifier model (e.g. non-1M Sonnet) when the primary returns 429/5xx — a SPOF on one model is the root design flaw.
2. Surface the real underlying error (429 rate_limit vs overload) in the UI instead of a generic "temporarily unavailable."
3. Investigate why side_query/classifier requests get 429'd at ~0% plan usage for specific accounts/regions while normal generation on the same account/IP succeeds.

Happy to share the full --debug api log and request IDs.

[Estrellajer]

Same issue here.