[BUG] Opus & Sonnet silently blocked on MaxPlan — only Haiku served, no user notification (14h+)

Summary

Since ~2026-03-16 22:00 UTC (now 14+ hours), claude-opus-4-6 and claude-sonnet-4-6 return HTTP 400 (invalid_request_error, "message":"Error") on a MaxPlan 5x subscription. Only claude-haiku-4-5-20251001 responds successfully. The Anthropic status page shows all systems green.

Critical: Claude Code silently falls back to Haiku when Opus/Sonnet are rejected, without any user notification. Users believe they are getting Opus-quality responses while actually receiving Haiku. This was confirmed via MITM traffic interception.

Proof: identical requests, only model field differs

Same OAuth token, same headers, same endpoint, same body — only "model" changes.

POST https://api.anthropic.com/v1/messages?beta=true
Headers:
  anthropic-version: 2023-06-01
  Authorization: Bearer sk-ant-oat01-[REDACTED]
  anthropic-beta: oauth-2025-04-20,interleaved-thinking-2025-05-14,token-counting-2024-11-01
  User-Agent: claude-cli/2.1.77 (external, cli)
  x-app: cli

| # | Requested model | HTTP | Response | Verdict |
|---|----------------|------|----------|---------|
| 1 | claude-opus-4-6 | 400 | {"type":"error","error":{"type":"invalid_request_error","message":"Error"}} | BLOCKED |
| 2 | claude-sonnet-4-6 | 400 | {"type":"error","error":{"type":"invalid_request_error","message":"Error"}} | BLOCKED |
| 3 | claude-haiku-4-5-20251001 | 200 | {"model":"claude-haiku-4-5-20251001","type":"message","content":[...],"service_tier":"standard"} | OK |

Request IDs for Anthropic investigation:

• Opus: req_011CZ8Ur3C3s52gZkrXmciG4
• Sonnet: req_011CZ8Ur5t2KgJ3GQVH6ot7o
• Haiku: msg_01DR7eFAQdz9bxHyz491HWeJ

Tested on both Claude Code v2.0.76 and v2.1.77 — same result. This is not a client version issue.

MITM proof: Claude Code silently downgrades to Haiku

At ~04:00 UTC, we intercepted Claude Code traffic (VS Code extension) using mitmproxy 11.0.2:

1. Claude Code sends "model": "claude-opus-4-6" in POST body
2. Anthropic API rejects with 400
3. Claude Code silently retries with Haiku
4. User sees a response and believes they are using Opus
5. Zero indication in the UI that a downgrade occurred

The Claude Code CLI (terminal) at least shows Haiku 4.5 · Claude Max in the welcome banner after
{EDIT: <fallback> Upgrade from v2.0.76 to v2.1.77-> changing model :/model opus4.6 -> keeping opus4.6 and still receiving haiku answer}.
But the VS Code extension shows nothing — the user has no way to know they've been downgraded.

╭─── Claude Code v2.1.77 ──────────────────────╮
│   Haiku 4.5 · Claude Max   │  ← at least the CLI is honest
╰───────────────────────────────────────────────╯

Why this is worse than a "rate limit" error

Other MaxPlan users are reporting Rate limit reached errors (#35213, #34786, #34287, #33514, #34958). Some report that "VS Code works fine" while CLI fails.

Our MITM analysis explains this discrepancy: VS Code isn't "working fine" — it's silently falling back to Haiku. These users think they're getting Opus responses but they're actually getting Haiku. They just don't know it.

This means the actual scope of this issue is likely much larger than the few users who noticed the error messages.

The error message is deliberately opaque

{"type":"error","error":{"type":"invalid_request_error","message":"Error"}}

"message":"Error" — that's it. No reason, no explanation, no suggested action. For a paying MaxPlan customer, this is unacceptable. Compare with how other APIs handle this:

• OpenAI: "The model 'gpt-4' is currently overloaded. Please try again later."
• AWS Bedrock: "ThrottlingException: Rate exceeded for model X"

Account details

• Subscription: MaxPlan (subscriptionType: "max")
• Rate limit tier: default_claude_max_5x
• OAuth scopes: user:inference, user:sessions:claude_code, user:mcp_servers, user:profile
• Network: 4G/CGNAT (shared IP with thousands of users — not IP-based)

What we expect

1. Transparency: If a model is unavailable, say so clearly in the error message, with a reason and ETA
2. User notification: If Claude Code falls back to a lower model, show it visibly — e.g. ⚠ Using Haiku (Opus unavailable)
3. Status page accuracy: Reflect actual per-model availability, not just endpoint health
4. Service restoration: We are paying for Opus and Sonnet access. 14+ hours of silent degradation is a breach of service.

Related issues

• #35213 — CLI "Rate limit reached" despite low usage, VS Code "works" (likely silent Haiku fallback)
• #34786 — Rate limit reached without any usage spent
• #34287 — API Error: Rate limit reached on Max Plan
• #33514 — Rate limit "from nowhere"
• #34958 — Opus 4.6 1M unavailable on Max 5x
• #34585 — Opus 4.6 with 1M context unavailable for Max 5x subscriber
• #34333 — Opus 4.6 with 1M context is not available on Max 5x plan

Reproduction steps (for other users to verify)

# Step 1: Get your OAuth token
TOKEN=$(python3 -c "import json; d=json.load(open('$HOME/.claude/.credentials.json')); print(d['claudeAiOauth']['accessToken'])")

# Step 2: Test Opus
curl -s -X POST "https://api.anthropic.com/v1/messages?beta=true" \
  -H "anthropic-version: 2023-06-01" -H "content-type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -H "anthropic-beta: oauth-2025-04-20,interleaved-thinking-2025-05-14,token-counting-2024-11-01" \
  -d '{"model":"claude-opus-4-6","max_tokens":20,"stream":false,"messages":[{"role":"user","content":"hi"}]}'

# Step 3: Test Haiku (control)
curl -s -X POST "https://api.anthropic.com/v1/messages?beta=true" \
  -H "anthropic-version: 2023-06-01" -H "content-type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -H "anthropic-beta: oauth-2025-04-20,interleaved-thinking-2025-05-14,token-counting-2024-11-01" \
  -d '{"model":"claude-haiku-4-5-20251001","max_tokens":20,"stream":false,"messages":[{"role":"user","content":"hi"}]}'

If Opus returns 400 and Haiku returns 200: you are affected.

Environment

• Platform: Linux 6.8.0-100-generic x86_64 (Ubuntu 22.04)
• Claude Code: v2.1.77 (tested on v2.0.76 as well, same result)
• VS Code: 1.109.5
• MITM tool: mitmproxy 11.0.2, Python 3.10.12
• Duration: 14+ hours (since ~2026-03-16 22:00 UTC)
• Status page: All green during entire incident