How to set up automatic fallback when the Claude API is down

As of November 2026, you can set up automatic Claude API fallback with a Requesty policy that puts Claude first and a model from another provider second. In Requesty's April 2026 data, the managed-fallback policy cohort reached 99.25% eventual success, compared with 85.01% for the direct cohort.

Set up a fallback policy

A fallback chain gives your application an ordered set of models to try. Requesty tries the primary model first and moves through the chain if a model fails; it skips a model that cannot handle the request parameters. The fallback policy documentation covers configuration and request logs.

1. 1
   Choose the model order

   In Routing Policies, select the Fallback strategy. Put your Claude model first and choose a model from another provider as the backup.

   For example, evaluate anthropic/claude-opus-5-5 as the primary and openai/gpt-6.1-sol as the backup. Both appear in Requesty's coding benchmark, though their results differ by task.

2. 2
   Set the retry budget

   Choose how many retries each model can have. Requesty allows 0 to 10 retries per model, so account for the time spent on the primary before the backup gets a turn.

3. 3
   Call the policy

   Save the policy, then call it using policy/your-policy-name as the model string, with the name you saved. Point your client at https://router.requesty.ai/v1 and use your Requesty API key.

4. 4
   Test the chain

   Test a failure on the primary and inspect the request logs to verify which model handled the request. Test an all-model failure too: Requesty returns an error with details from the last model attempted.

For an EU deployment, Requesty also has an endpoint at https://router.eu.requesty.ai/v1. Its routing page describes region-pinned chains that stay within the selected region.

A same-model route is another option: Requesty serves Claude 5.5 models from Anthropic, Bedrock and Vertex AI, so a chain can try anthropic/claude-opus-5-5 first and bedrock/claude-opus-5-5 next.

Which errors deserve a retry?

A 529 overloaded_error means Anthropic is experiencing high traffic across users. For a transient 529, use a bounded retry with backoff and a tested backup route.

Anthropic's error documentation notes that a 429 can have several causes, including a rate limit or a spend cap. A tier spend-cap 429 has no retry-after header and persists until access resumes, so retries will not clear it. Another provider can add spend: use that route only when the spend is approved.

A short wait may help with a transient rate limit; an invalid request or an expired key needs a fix. Our 429 guide covers rate-limit causes, and our Claude API errors guide covers each Anthropic error.

Before calling the policy, validate inputs and confirm that the API key and account have access. Fix invalid requests, access errors and safety blocks at the source, and approve any added provider spend before sending traffic to a backup.

The Requesty policy documentation says the policy moves to the next model when a model fails and skips models that cannot handle the request parameters. The table describes application-level handling; it does not describe per-status rules applied by the policy.

If a request must not move to another provider after a 400, 403 or safety block, send it on a separate path your application controls (a direct model string rather than the policy), and use the fallback chain only where moving to the next model is acceptable.

Requesty's April 2026 provider-origin data shows which errors were most common. The 429s accounted for 65.83% of failures, 400s for 19.40% and 403s for 9.41%. The listed 5xx codes added up to about 4.8%, including 0.52% for 529.

Rate limits deserve attention in a fallback design, but the 400 share is also a reason to fix bad requests instead of sending them around the chain.

How much can fallback change the result?

Requesty's eventual success data measures the best result across attempts for each request ID. The direct cohort includes non-policy provider requests.

Take a feature that handles 100,000 requests per month. At the April rates:

• Direct: 100,000 × (1 - 0.8501) = 14,990 failed requests.
• Policy: 100,000 × (1 - 0.9925) = 750 failed requests.
• Difference: 14,990 - 750 = 14,240 fewer failed requests in the policy scenario.

These are cohort averages, not a before-and-after measurement of the same traffic. At January's rates, the gap is 3,000 failed requests: 5,500 direct versus 2,500 through the policy.

Keep retries from piling up

Retries can stack. Anthropic's SDK retries transient failures twice by default, with exponential backoff. If an application wrapper and a job queue also retry, the number of provider calls can multiply.

In one published post-mortem, three SDK attempts, four wrapper attempts and three queue attempts allowed 36 calls for one failing job. Decide which layer owns retries and include the gateway's per-model retry budget when you set the application's deadline.

Requesty's retry design describes delays from 500 ms to 4 seconds with jitter. Jitter varies the wait between attempts, reducing the chance that retries arrive together. For repeated failures, a circuit breaker can pause calls to a failing route and test it again later; include that behaviour in your own incident design and drills.

Switch models in Claude Code

Claude Code has a --fallback-model option for switching automatically. According to Whizi's guide, the switch applies to the current turn, and the next message tries the main model again.

You can also use /model to switch manually if Claude Code reports a 529. The Claude Code error reference says capacity is tracked per model, so another model may have capacity when the one you selected is overloaded.

For a gateway setup, our guide to connecting Claude Code to Requesty covers the integration.

Test the full failover path

An HTTP 200 does not always mean a streamed answer will finish. Anthropic documents that an overloaded_error can arrive inside an SSE stream after the initial response, so test how your application handles a partial answer and a subsequent error event.

Gateway behaviour can differ here. By default, Portkey's Anthropic documentation says its retry, fallback and circuit breaker do not fire on an overload event inside a 200 stream. Its "Catch Overloaded Error on Stream" flag converts the event to a 529; include 529 in the retry or fallback status codes to use those rules.

Test the complete stream on whichever route you use, including what the user sees if the answer stops partway through. The backup answer needs testing too. Requesty's coding benchmark, updated October 2026, measured performance on 129 private Go backend tasks:

Those results give you a starting point for a coding workload. Run your own prompts through the backup, including any structured output or tool calls your application depends on, before relying on it during an incident.

Run a failover drill

Use the policy's Live Performance panel and filter Analytics by policy name to see latency, success and how often fallback occurred. The policy documentation also describes request logs for failures across the chain.

Start with one feature, run the drill, and inspect the policy's request logs before expanding the chain. If 429s are the failure you see most often, our guide to provider rate limits covers the next steps.