Auto mode classifier persistently unavailable — 2+ weeks, reproduces across accounts, machines, OSes, and CLI versions

Same failure here, and I think I have the missing piece: the classifier request is getting HTTP 429 rate_limit_error, on an account that is nowhere near its limits.

Claude Code already writes a dump on every classifier failure. I have not seen one posted in any of these threads:

• Windows: %LOCALAPPDATA%\Temp\claude\auto-mode-classifier-errors\<session-id>.txt
• macOS/Linux: $TMPDIR/claude/auto-mode-classifier-errors/<session-id>.txt

First line of every one of mine:

429 {"type":"error","error":{"type":"rate_limit_error","message":"Error"},"request_id":"req_011CdnDbbdJ39ji62phPuACR"}

What the dumps show

8 dumps, one per session, 2026-08-01 through 2026-08-06. All 8 are the same 429, across four different model IDs:

| Date | classifier model | classifierTokensEst |
|---|---|---|
| 2026-08-01 | claude-sonnet-5[1m] | 40258 |
| 2026-08-02 | claude-opus-5[1m] | 51534 |
| 2026-08-03 | claude-opus-4-8 | 33299 |
| 2026-08-06 | claude-opus-5 | 29243 |

Identical 429 with and without the [1m] suffix, which rules out the long-context variant as a cause. That theory comes up in #83227 and #82653, and I chased it myself for days.

Why this is not the account's own usage

• Claude Max 5x, organizationRateLimitTier: "default_claude_max_5x".
• At the time of the failures: about 90% of the 5-hour window remaining and about 40% of the weekly. It also fails at 100% remaining.
• It fails on the first classifier call of a fresh session, and a single isolated tool call fails exactly like a batch of five. So it is not a burst of my own making.
• The main loop keeps working on the same model throughout. The model is up and the account is not limited.
• The body is "message":"Error", not the descriptive message the API returns for a genuine plan limit.

One observation that may or may not be relevant: my ~/.claude.json has overageCreditGrantCache reporting available: false, eligible: false. If classifier traffic is routed through a pool that requires overage, an account without it would be rejected 100% of the time regardless of remaining quota. That is a guess, but it matches the shape of what I see.

Two separate client bugs, verified in 2.1.223

1. The status code is computed and then discarded. The unavailable branch has it:

if (W.unavailable) return ..., { behavior: "deny",
  message: Jxp(e.name, W.model, W.httpStatus, W.errorKind) }

but the formatter that should render it is a stub:

function HFp(e, t) { return "" }
function Jxp(e, t, r, n) { return `${t} is temporarily unavailable${HFp(r, n)}...` }

So a 429 reaches the user as "<model> is temporarily unavailable", which points everyone at model availability and local config. Surfacing httpStatus would have ended my investigation on day one instead of day five.

2. The fallback to prompting cannot engage on unavailability. This confirms the hypothesis in #82653 at code level: tengu_auto_mode_fallback_to_ask is emitted only in the transcriptTooLong branch, while the unavailable branch returns behavior: "deny" directly. Availability errors therefore never count toward the documented 3-strike threshold, which is why nobody ever sees the fallback fire.

Scope of the block, in case it helps triage

Working, because they never reach the classifier: read-only tools (Read, Grep, Glob), anything matching a permission allow rule, acceptEdits mode, and simple Bash commands that clear the local fast path (uname, hostname, node --version, pipes, globs).

Blocked 100%: every PowerShell tool call not matching an allow rule, WebFetch on non-allowlisted domains, all MCP tool calls, and Bash commands the fast path will not clear. Note that node --version succeeds through Bash and fails through PowerShell, same command, which isolates the difference to whether the call reaches the classifier at all.

Suggested fixes

1. Include httpStatus and errorKind in the user-facing message. At minimum, distinguish "rate limited" from "model unavailable".
2. Count unavailability toward the fallback-to-ask threshold, or fall back to prompting immediately on a 429.
3. Server side: if classifier traffic has its own quota or capacity pool, a 429 from it should not be indistinguishable from a plan limit, and it should not fire while the account's own quota is 90% unused.

Environment: Claude Code 2.1.223 (native installer), Windows 11 Pro 26200, Claude Max 5x, session models claude-opus-5 and claude-fable-5. Happy to share more request IDs or the full dump metadata if that helps.

---

If you pull your own dumps: the file contains your full session transcript below the error block. Only the first two lines are needed.

I encountered the same failure in my Claude Code:

⎿ Error: 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. If it keeps failing, continue with other tasks that don't require this action and come back to it later. Note: reading files, searching code, and other read-only operations do not require the classifier and can still be used.

Environment: macOS, Claude Code v2.1.220

As a temporary workaround, running claude --permission-mode bypassPermissions helps bypass this failure.

I encountered the same after I swap the AI model provider from Anthropic to Amazon Bedrock. THe cause is not known yet.