Claude Errors Across Many Models: What To Do Now

So Claude broke. Again. If you’ve been refreshing claude.ai or staring at a terminal full of red 529s this past week, you’re looking at the same thing thousands of others saw: Claude’s “Elevated errors across many models” incident, which hit repeatedly between June 13 and June 20, 2026, before each round got marked resolved. The obvious question everyone keeps asking in Slack and on Hacker News:

Is this my fault, my API key, my code – or is Claude just down?

Short answer: almost always Claude. But there’s a specific way to confirm it in under 60 seconds, and a specific way to keep working that most tutorials miss. Let’s go.

What actually happened (and why it matters for you)

Anthropic’s status page shows a wave of “elevated errors” incidents through mid-June 2026, mostly hitting Opus 4.8 and Haiku 4.5. On June 16, between 17:23 and 18:00 UTC, all Sonnet and Opus models were affected at roughly a 10% error rate, and Opus 4.8 stayed at that rate until 19:20 UTC. A second wave hit the next morning. Then again on the 19th and 20th.

June 16 was reportedly the tenth significant Claude disruption in 12 days. The reason is not mysterious: Anthropic acknowledged to Fortune that demand has grown faster than its infrastructure can support, particularly at peak hours, attributing the problem to unprecedented user growth while noting it is expanding compute capacity through partnerships with Amazon and Google – capacity that is not yet available as of mid-June 2026.

What that means for you: this isn’t a one-off. Until that new capacity lands, expect more of the same. Plan accordingly.

The 60-second triage: is it Claude, or is it you?

When something fails, run this in order. Don’t skip steps.

1. Read the exact error code. Not the vibe – the number. Per Anthropic’s API error docs (current as of mid-2026): 529 is overloaded_error – the API is temporarily overloaded – and 429 is rate_limit_error, meaning your account hit its limit. A 429 is your problem. A 529 is theirs. They are handled differently and you should never treat them the same way.
2. Open status.claude.com in a second tab. If there’s an active incident on Opus 4.8 or “multiple models,” stop debugging. It’s not your code.
3. Try a different model. In Claude Code, type /model and switch. Per Anthropic’s Claude Code documentation, the tool tracks capacity per model and will prompt you with messages like “Opus is experiencing high load, please use /model to switch to Sonnet” – run that command and keep working.
4. If you’re on the API, grab your request-id. Every API response includes a unique request-id header containing a value like req_018EeWyXxfu5pfWkrYcMdjWG. Include it when contacting support. Without it, you have nothing to escalate with.

That’s it. Three minutes total. If status is red, go make coffee. If status is green but you’re still failing, keep reading.

The Claude Code trap nobody warns you about

This one bit me. Per Anthropic’s Claude Code documentation, the tool retries transient failures – server errors, overloaded responses, request timeouts, temporary throttles, and dropped connections – up to 10 times with exponential backoff, showing a “Retrying in Ns · attempt x/y” countdown while it works. When you finally see the error message, those retries have already been exhausted.

Translation: by the time “Repeated 529 Overloaded errors” lands in your terminal, the tool already burned roughly a minute trying. Wrapping your own loop around claude in a shell script to “retry harder” just stacks delay on top of delay. Don’t.

And there’s a sneakier one. As of June 2026 – though this may change – if ANTHROPIC_API_KEY is set in your shell, Claude Code uses that key instead of your Pro/Max subscription credentials. So if you’re sure you’re on Pro or Max but your shell exports ANTHROPIC_API_KEY, the subscription path doesn’t own the failure. Run /status in Claude Code and inspect your environment to confirm which route is active.

People rage-quit their Max plan over outages that were actually their own stray env var routing them through a pay-as-you-go API tier. Check before you cancel.

If you’re calling the API: a retry pattern that doesn’t make things worse

Here’s the minimum-viable handler. Read the comments – they’re where the actual lessons live.

import anthropic, time, random

client = anthropic.Anthropic()

def call_with_backoff(prompt, max_attempts=5):
 for attempt in range(max_attempts):
 try:
 return client.messages.create(
 model="claude-opus-4-8",
 max_tokens=1024,
 messages=[{"role": "user", "content": prompt}],
 )
 except anthropic.APIStatusError as e:
 if e.status_code == 529:
 # provider overload - back off + JITTER (this matters)
 delay = (2 ** attempt) + random.uniform(0, 1)
 time.sleep(delay)
 continue
 if e.status_code == 429:
 # YOUR account hit a limit - different problem, don't loop
 raise
 raise
 raise RuntimeError("Claude overloaded after retries - fall back")

Two non-obvious bits. First, without random jitter, every client that hit 529 at the same time retries at the exact same instant, re-creating the overload spike at 2s, 4s, 8s – always add a random offset to backoff delays. That’s the thundering herd problem: synchronised retries don’t relieve pressure, they reproduce it. Second, never wrap 429 in the same loop. A 529 is global overload at the model layer and is not specific to your account. A 429 means your account specifically needs to slow down or upgrade its tier. Same loop, different outcome.

The fallback that actually works (and the one that doesn’t)

Most guides tell you to set a fallback model. They rarely tell you that the obvious fallback is useless during the incidents you’re reading about.

The June 16 timeline proves the point: Sonnet and Opus went down together for 37 minutes. Same-vendor tier fallback wouldn’t have saved you. Cross-vendor would have.

Pro tip: If your product can’t tolerate a silent quality downgrade – legal review, code generation that ships to prod, anything where the user expects “the smart model” – don’t auto-fall-back to a smaller model. Queue the request and retry when Claude recovers. Based on community-tracked incidents through mid-2026, most 529 spikes resolve within 30 to 300 seconds, though model launch days and peak US business hours (14:00-22:00 UTC) see longer events, occasionally 5 to 15 minutes – a 60-second circuit breaker plus tier fallback rides through these without user impact.

Common pitfalls during an outage

• Reinstalling Claude Code, rotating keys, clearing cache. If you got a 529 response, your install is fine – the server reached you. You’re solving the wrong problem.
• Treating every blocked request as the same error. Per Anthropic’s release notes, as of August 11, 2025, some sharp-usage scenarios that used to return 529 overloaded_error now show up as 429 rate_limit_error instead – so the code on screen tells you which playbook to run.
• Tight retry loops with no ceiling. You’re hammering a service that’s already struggling. Cap attempts at 4-6 and stop.
• Believing “resolved” means “fixed.” As of late June 2026, Anthropic has not issued standalone public statements on any of the recent incidents beyond rolling status updates, continuing a pattern of not publishing post-incident root cause analyses. So “resolved” today doesn’t guarantee “won’t recur tomorrow.”

When NOT to bother retrying at all

If status.claude.com is showing an active multi-model incident and you’re on a short deadline, stop. Don’t retry, don’t switch tiers, don’t tune backoff. Open a second terminal and pipe your prompt to a different vendor – Anthropic’s own API docs are honest that 529 means “come back later,” and “later” can mean an hour during the bad ones.

Also skip retries for anything with side effects – payment calls, irreversible database writes, sent emails – unless your code has idempotency keys. A successful retry of a non-idempotent request is worse than a clean failure.

FAQ

Does a 529 cost me money or count against my quota?

No. Per Anthropic’s API documentation, a 529 does not count against your usage quota.

The status page is green but I keep getting 529 – what now?

Check whether you’re hitting a model-specific squeeze versus a platform issue. Run /status in Claude Code and confirm which credential and route are active – a stray ANTHROPIC_API_KEY can quietly send you through a different tier than your subscription (see the env var gotcha above). If that’s clean, try a tier-fallback (Opus → Sonnet) for one same-path retry. Still failing? Capture the request_id and file feedback. A green status page plus a repeatable same-path failure is a real support case, not a tuning problem.

Should I just route around Claude entirely?

For production systems where uptime matters more than “Claude specifically,” yes – build a multi-vendor path now while it’s calm. For personal use and side projects, probably not worth the complexity; just keep a ChatGPT or Gemini tab open as your manual fallback. The right answer depends entirely on what breaks when Claude breaks.

Your next step

Open status.claude.com right now and subscribe to email or Slack alerts. The single biggest reason people lose hours to these incidents is finding out about them after they’ve already wasted 40 minutes debugging their own code. Get notified first, debug second.