Anthropic went down. FastRouter didn't. 150 requests. One live outage. Zero downtime.

On September 3, 2026, Anthropic went down. Opus 5 stayed degraded for nearly three hours, elevated errors, 529 "Overloaded" responses, the works.

We ran 150 live requests through FastRouter during that exact window. All 150 succeeded.

That's not luck. Every LLM provider experiences downtime, and even a healthy headline availability of 99.5% still adds up to roughly 3.6 hours a month of degraded service, timeouts, and errors like the ones above. That isn't a criticism of any single vendor. It's the current reality of serving frontier models at scale. This is what happens when your application isn't tied to just one of them.

FastRouter reduces this exposure by decoupling your application from any one vendor's infrastructure. The same Claude model is available from Anthropic directly, Amazon Bedrock, and Google Vertex AI; FastRouter sits in front of all three and routes each request to a healthy upstream.

On 3 September 2026, we ran a routing test that happened to coincide with an active Anthropic incident. The results below are from that run.

What Anthropic's status page showed today

Anthropic's own status page (status.claude.com) logged two separate incidents on 3 September 2026:

Incident 1: Elevated errors for Claude Sonnet 5 12:37 UTC · Investigating elevated errors on Claude Sonnet 5 12:47 UTC · Fix implemented, monitoring 12:56 UTC · Resolved Duration: ~19 minutes

Incident 2: Elevated errors for multiple models 13:26 UTC · Investigating elevated errors on Claude Mythos 5.1, Fable 5.1, and Opus 5 13:41 UTC · Cause identified 13:50 UTC · Full list of affected models published: Mythos/Fable 5.1, Mythos/Fable 5, Opus 5, Opus 4.8, Opus 4.6 15:25 UTC · Update: only Opus 4.8 and Opus 5 still affected; other models recovered to baseline 16:06 UTC · Fix deployed, monitoring 16:23 UTC · Resolved; impact ended at 16:16 UTC Duration: ~2 hours 50 minutes

Anthropic API availability. Shaded regions mark the two incidents above.

Users noticed. From X this afternoon:

Source: https://x.com/cjav_dev/status/2095519763581538376 

Source: https://x.com/williamnestt/status/2095528753992696096

Source: https://x.com/IamRajs5/status/2095492463037448249

Anyone integrated directly against Anthropic's API for various models was seeing elevated errors for the better part of three hours during European and US business hours.

Why in-house failover is harder than it looks

To get genuine resilience for Claude, teams typically try to build redundancy across the three independent hosts: Anthropic Direct, Amazon Bedrock, and Google Vertex AI. In practice that means:

• SDK and credential sprawl: Separate authentication, IAM roles, and SDK interfaces for AWS, GCP, and Anthropic.
• Failover logic that has to be right under pressure: Client-side health checks, backoffs, and circuit breakers that need to behave correctly at exactly the moment an upstream is failing.
• Fragmented billing and schema differences: Three cost centres and subtly different API shapes to keep in sync.

FastRouter provides this routing layer as a service. Behind a single OpenAI-compatible endpoint, a vendor incident becomes a shift in traffic distribution rather than a production outage.

The test: 150 requests, 3 providers, during the incident

Run time: 2026-09-03 15:36–15:38 UTC (probe started 15:37:36 UTC) Incident status at that moment: Opus 5 was still listed as affected on Anthropic's status page (the fix was not deployed until 16:06 UTC). Sonnet 5 had recovered roughly 2.5 hours earlier. Sonnet 4.6 was not listed as affected.

We sent 50 requests to each of anthropic/claude-sonnet-4.6, anthropic/claude-sonnet-5, and anthropic/claude-opus-5 through FastRouter, with no provider hint, no client-side retries, and 50 distinct short prompts with known answers.

Result: 150/150 requests succeeded (100%).

Where the traffic went

The pattern is worth noting. For Opus 5, the model still under an active incident, only 2 of 50 requests went to Anthropic Direct; 48 were served by Bedrock and Vertex AI. For Sonnet 5, which had recovered hours earlier, Anthropic Direct carried 64% of the traffic. We can't see FastRouter's routing decisions directly, but the distribution is consistent with traffic being steered away from an upstream reporting elevated errors and back toward it once it recovered.

Latency held steady across providers

Median latency differences between providers were in the 100–450 ms range; comparable to ordinary network variance. Routing across clouds did not introduce a noticeable latency cost.

Answers were correct regardless of provider

Because every prompt had a known answer, we checked correctness as well as HTTP status. 149 of 150 responses (99.3%) were correct, with no difference attributable to the serving provider. The one miss was a model reasoning error on a sequence question, unrelated to routing.

What this shows, and what it doesn't

Shown:

• During a live Anthropic incident affecting Opus 5, requests for Opus 5 through FastRouter succeeded 50/50, with 96% served by Bedrock and Vertex AI.
• The same model ID was served by three independent providers with no client-side code.
• Latency and correctness were consistent across providers.

Not shown:

• A direct-to-Anthropic control run at the same moment. We didn't pin traffic to anthropic during the incident, so we can't state a precise error rate a direct integration would have seen; only that Anthropic's own status page reported elevated errors for that model at that time.
• Long-run availability. 150 requests over two minutes is a snapshot, not an uptime figure. We're continuing to run the probe on a schedule to build that dataset.

Why teams use FastRouter for this

• Drop-in OpenAI compatibility: Change a base URL and API key; no vendor-specific SDKs or wrappers.
• Live capacity routing: Traffic splits reflect current upstream health, latency, and limits rather than a fixed schedule.
• Consistent output across providers: Same model, same completions, whichever cloud served them.
• Transparent attribution: Every response includes usage.provider, and requests can carry tags for auditing and cost allocation.

Your users don't care which cloud ran their prompt; they care that the application answered. On a day when one path was degraded for nearly three hours, FastRouter kept the other two in play.

Set up multi-provider Claude routing in a few minutes at FastRouter.ai.

Reproduction: fastrouter_uptime_probe.py. Raw results (fastrouter_probe_results.csv) and the full request log are available on request.