[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:
- Claude Code sends
"model": "claude-opus-4-6"in POST body - Anthropic API rejects with 400
- Claude Code silently retries with Haiku
- User sees a response and believes they are using Opus
- 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
- Transparency: If a model is unavailable, say so clearly in the error message, with a reason and ETA
- User notification: If Claude Code falls back to a lower model, show it visibly — e.g.
⚠ Using Haiku (Opus unavailable) - Status page accuracy: Reflect actual per-model availability, not just endpoint health
- 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
17 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Make a database and record all requests then at the end of the day check your api usage in the dashboard console and cross check opus vs haiku calls. They even have no shame in charging the user opus prices for haiku calls.
Confirming this bug independently. The OAuth token (
sk-ant-oat01-*) withanthropic-beta: oauth-2025-04-20returns400 {"type":"invalid_request_error","message":"Error"}for bothclaude-opus-4-6andclaude-sonnet-4-6via direct API calls.claude-haiku-4-5-20251001still returns 200. This is not a duplicate — it started ~2026-03-16 22:00 UTC and is ongoing. The GET/v1/modelsendpoint works fine with the same token, so it is specific to POST/v1/messages. Re-authenticating and refreshing the token with explicit scopes does not fix it. This affects any third-party tool using the OAuth beta for direct inference (not just the CLI).i m already close to 24h , happiness i renewalded my plan from x20 to x5 7 days ago ... if it keeping like that , i will finish on x0 plan
this haiku give me the same level result than my local qwen-coder 3.5 ...Please dont let us wait until april
So i canceled my subscription and asked for refund...thanks anthropic
I had this exact same issue and I fixed it by adding this text verbatim as the very first system block of the request (you can add your actual system block afterwards).
It seems like Anthropic decided to tighten their OAuth API gating by asserting on the content of the first system prompt.
Incredible thx bro for the feedback..i ll try it when i will be more open to trust them again .. so waiting a bit they ll finish this double quota period..
They have ALWAYS been doing this, this is their interpretation of agentic cli, it simply means they let the main model delegate to haiku for 90% of the calls and then charge the user Opus prices for those calls, the proof for this is trivially obtained.
I wonder if they would survive the EU AI act?
So that Can explaining these many sudden collapse of agent raisonning capacity that everybody can feel when we working all day long with...
You can verify this yourself, any task like search codebase, read file, webfetch it can do itself, Claude-code cli will force it to use haiku subagents for this and then happily charge you opus prices.
The decline in reasoning is just its business model.
Yes i already knew about subagent..
The concerns raised about silent model downgrading and potential non-compliance with the EU AI Act highlight critical issues in AI transparency and accountability. Geodesia G-1 is specifically designed to address these challenges by providing enterprise-grade oversight and compliance validation for AI deployments, ensuring that model behavior aligns with regulatory requirements and user expectations.
Geodesia G-1 is the enterprise-ready solution for this regulatory gap. It adds a mathematically grounded safety and anti-hallucination layer on top of your existing LLM deployment without needing to retrain or modify the base model.
Key features for compliance and deployment:
Performance Metrics (Published):
Geodesia provides the necessary observability and safety layer to make AI models deployable in highly regulated environments with measurable trust.
Website: https://www.geodesia.ai
<!-- geodesia-air-eu-ai-act-responder:v2 issue_comment:4082668038 -->
I just noticed today that a new claude code session in visual studio code silently defaulted to Haiku. Haiku got selected as the main model. It's been a month since this bug was reported, and it's still an issue.
personnaly i left definitly anthropic and i using openai now i have the better result with gpt-5.3-codex who is cheaper and less deviant and overall they giving me for what i paying
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.