[Bug] Auto mode classifier fails with API 400: "A maximum of 4 blocks with cache_control may be provided. Found 5"

Bug Description
Claude Code version: 2.1.245

Summary: Auto mode's action-classifier is repeatedly failing with an Anthropic API 400 error, causing it to fail-closed (automode-unavailable) on otherwise normal tool calls.

Error:
400 Bad Request: "A maximum of 4 blocks with cache_control may be provided. Found 5."

Evidence it's the classifier, not the main assistant turn:
Every failing request has streaming=false; every normal assistant turn in the same sessions is streaming=true and returns 200. This strongly suggests Auto mode's classifier is building a request that reuses a transcript already at the 4-cache_control-breakpoint cap and then appends its own breakpoint (e.g. for its own system prompt), pushing the total to 5 and getting rejected outright by Anthropic's API — before the classifier can render any verdict.

Frequency: 58 occurrences across 4 sessions between 2026-08-18 and 2026-08-25 (still recurring today).

Setup used to isolate this: Claude Code points at a local passthrough proxy I run (ANTHROPIC_BASE_URL=http://127.0.0.1:4000) that forwards requests unmodified to https://api.anthropic.com and logs the raw upstream response. This let me confirm the 400 is coming straight from Anthropic's API, not from anything in my proxy — the proxy is a pure pass-through with no header/body rewriting.

Example log line:
2026-08-25T15:53:43.928269Z WARN ... LLM request failed wire_format=anthropic_messages status=400 requested_model="claude-sonnet-5" selected_model="" streaming=false session_id="[REDACTED]" error="A maximum of 4 blocks with cache_control may be provided. Found 5."

Claude Code itself also wrote a local debug dump when this occurred (auto-mode-classifier-error.txt in one of my project transcript folders), showing the same 400 alongside a context comparison: classifier context ~32.5k tokens vs. main-loop context ~158k tokens for that turn — consistent with the classifier assembling its own reduced-but-still-cached view of a transcript that's already at the breakpoint cap.

Ask: Is this a known bug in how Auto mode's classifier constructs its cache_control breakpoints relative to the main session's transcript? Is there a workaround short of disabling Auto mode entirely (e.g. capping classifier context, or not inheriting the session's own cache breakpoints)?

Environment Info

• Platform: darwin
• Terminal: ghostty
• Version: 2.1.245
• Feedback ID: a0dad025-eb40-4433-ab5a-61525b9c9157

Errors

[]