claude-code - 💡(How to fix) Fix Persistent HTTP 429 on auto-mode classifier (xml_s1), account-side config [1 comments, 2 participants]

Update 2026-05-18: Still reproducing on Claude Code 2.1.144 (released 2026-05-19, ~12 hrs before filing). The 2.1.144 changelog contains no auto-mode-classifier model-selection or 429 fix. The 2.1.139 evidence below remains the cleanest on-record repro; nothing about the mechanism has changed across 2.1.139 → 2.1.144.

What's happening

On my Max account, every Claude Code auto-mode safety classifier call to claude-opus-4-7 is returning HTTP 429 rate_limit_error immediately (~1.5–2 s round-trip), at stage=xml_s1. The user-facing message that Claude Code surfaces translates this to "claude-opus-4-7 is temporarily unavailable, so auto mode cannot determine the safety of Bash right now", which is misleading — the underlying response is a 429 from /v1/messages on the classifier code path.

This is not a transient Messages-API rate limit:

• Regular /v1/messages calls to claude-opus-4-7 from the same account, same authenticated session, succeed with HTTP 200 within minutes of the classifier 429s.
• I have 46 distinct classifier-path 429s in today's CLAUDE_CODE_DEBUG_LOGS_DIR debug logs alone.
• The same failure pattern persisted yesterday on a day with much lighter Opus usage.

It looks like an account-side misconfiguration: either a feature flag (tengu_auto_mode_config.model is unset in my GrowthBook profile, so the classifier falls through to the session model = Opus 4.7, which is then gated), or a per-account auto-mode-classifier rate-limit pool sized at ~0.

Same-minute proof this isn't a Messages-API pool exhaustion

All from today, 2026-05-12, same account:

If my Messages-API rate-limit pool were exhausted, the chat calls would 429 too — they don't. Different request shape, different gate, only one of them firing.

Binary-level isolation

The classifier-model selection lives in the ME7() function in the Claude Code binary (minified name, body invariant in v2.1.139):

function ME7(){let H=J$("tengu_auto_mode_config",{});if(H?.model)return H.model;return G4()}

When tengu_auto_mode_config.model is unset (my case), it falls through to G4() which resolves to the session model — claude-opus-4-7 for me.

I patched the binary in-place to hardcode the classifier model and re-ran the same probe (zoxide --version — not in my Bash allowlist, so it requires classifier escalation):

So the classifier endpoint accepts and serves my account's requests fine. Only the claude-opus-4-7 classifier code path is gated on my account.

A coworker on a comparable Max + Opus 4.7 setup is not affected.

Auto-mode gate check passes (so it isn't a precondition failure)

From my own CLAUDE_CODE_DEBUG_LOGS_DIR:

[auto-mode] verifyAutoModeGateAccess: enabledState=opt-in disabledBySettings=false 
  model=claude-opus-4-7 modelSupported=true disableFastModeBreakerFires=false 
  carouselAvailable=true canEnterAuto=true

canEnterAuto=true. Claude Code is not reporting auto mode as unavailable; the client happily enters auto mode. The failure is downstream of the gate, in the classifier API call itself.

Preconditions I've cleared

• Plan: Max (organizationType: "claude_max", tier default_claude_max_20x)
• Model: claude-opus-4-7 (per Max-plan auto-mode requirement)
• Provider: Anthropic API only (no Bedrock/Vertex/Foundry env vars)
• Claude Code: originally captured on 2.1.139; still reproducing on 2.1.144 (both well past the 2.1.83 minimum)
• skipDangerousModePermissionPrompt: true

Reproducer

mkdir -p /tmp/cc-check
CLAUDE_CODE_DEBUG_LOGS_DIR=/tmp/cc-check claude --print --debug api \
  --permission-mode auto --model claude-opus-4-7 \
  'Run the bash command `zoxide --version` exactly as-is and report what it printed.'
grep -E 'classifier_request|errorKind' /tmp/cc-check/*.txt

Expected: classifier_request_finished ... outcome=ok ... Observed on my account: classifier_request_finished ... outcome=error ... errorKind=Error:429

Substitute any Bash command that isn't in your local allowlist.

What I've already ruled out

• The [1m] suffix-propagation bug (#38537) — happens equally with and without suffix
• Effort level — low/medium/high/xhigh/max all 429 identically
• CLAUDE_CODE_EFFORT_LEVEL env var — unsetting it doesn't change behaviour
• ANTHROPIC_DEFAULT_OPUS_MODEL alias remap — classifier sends explicit model ID, not alias
• Patching cachedGrowthBookFeatures.tengu_auto_mode_config.model in ~/.claude.json — overwritten on next GrowthBook refresh
• Local proxy via ANTHROPIC_BASE_URL — disables classifier entirely (dacEnabled=n/a, per cc-switch#1678)

What I'm asking for

In order of preference:

1. An engineer to look at my account's GrowthBook tengu_auto_mode_config flag value and either set model to the correct value, or fix the classifier rate-limit pool sizing for my account.
2. Documentation of the auto-mode-classifier rate-limit pool in https://docs.claude.com/en/api/rate-limits so users can self-diagnose. Today's docs don't mention it.
3. Fix the misleading "temporarily unavailable" error message so it surfaces the actual underlying error (429 rate_limit_error).

Happy to share the full debug log bundle privately. I have already opened a support chat (conversations 215474274160046 and 215474274097794) but Fin's auto-template repeatedly terminates the chat with the "usage limit" stock response, blocking further reply. Hence this issue.

Related

• #49837 — Auto Mode Classifier uses Opus 4.7 instead of Sonnet (this is the mechanism)
• #49478 — claude-opus-4-7 temporarily unavailable blocks auto mode (this is the visible symptom)
• #38537 — Suffix-propagation bug (related but separate; ruled out as my cause)