Default WorkspaceGuides
429 fallback, coding agents & gateway comparisons

OpenAI to Claude & Multi-Provider Failover: Keep LLM Apps Up During Outages

Published · Facts and limits are dated; check the linked sources.

Retrying the same provider during a regional outage or an organization-wide rate limit only burns time before returning an error to your user. True resilience requires failing over to a second provider—such as moving from OpenAI to Claude (via OpenRouter), Gemini or Groq—when the primary returns HTTP 429 or 5xx. This guide covers what breaks when you switch models mid-flight, how to keep request shapes compatible, and how to automate failover with SentioGate. We build SentioGate, so we note both what it handles and what it doesn't.

As of 2026-10-26. Check the linked provider documentation for current model IDs and rate-limit headers.

What makes cross-provider failover tricky

Calling two providers isn't just swapping an URL:

  1. Different native APIs. OpenAI uses /v1/chat/completions; Anthropic's native API uses /v1/messages. To fail over cleanly from one client, you need an OpenAI-compatible layer in front of the backup model.
  2. Process-local state wastes requests. If you run 10 app workers and OpenAI starts returning 429 with Retry-After: 30, naive in-memory fallback makes all 10 workers hit OpenAI first before falling back. Cooldown state needs to be shared.
  3. Output differences. A prompt tuned for gpt-4o-mini may format JSON or markdown slightly differently on Claude or Gemini. Only fail over across models you have tested against your prompt.

How SentioGate handles multi-provider failover

SentioGate is a hosted, OpenAI-compatible BYOK router. You add your direct keys (OpenAI, Gemini, Groq, Mistral, DeepSeek, xAI) and/or an OpenRouter key (which reaches Anthropic Claude models over an OpenAI-compatible endpoint) in the encrypted Vault.

Note on Claude: SentioGate does not expose an Anthropic /v1/messages endpoint and does not forward direct Anthropic API keys today; to include Claude in your SentioGate failover pool, add an OpenRouter key and enable the Claude models you want in the Vault.

When you call /v1/chat/completions with model: "auto":

  • Shared cooldowns. When a model on a key returns 429, SentioGate records the cooldown across requests and honors Retry-After.
  • Key failover, then model failover. It tries your next key for the same provider first, and then moves to the next healthy model in your enabled Vault list.
  • Pinned models stay pinned. If you send a specific provider/model instead of "auto", SentioGate only fails over across your keys for that provider; it will never silently swap in a different model.
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.sentiogate.dev/v1",
    api_key=os.environ["SENTIOGATE_API_KEY"],
)

resp = client.chat.completions.create(
    model="auto",  # routes across the models you enabled in your Vault
    messages=[
        {"role": "system", "content": "Reply with valid JSON only: {"summary": string}"},
        {"role": "user", "content": "Customer states checkout button is unresponsive on iOS."},
    ],
)
print(resp.model, resp.choices[0].message.content)

With the SentioGate Python or TypeScript SDK (X-Router-Metadata: enabled), the response includes router.attempts so your logs show whether the primary answered or a fallback took over. You can also test provider degradation in the live outage sandbox on the benchmarks page.

Checklist before enabling a backup model

  • Test structured outputs. Verify that every enabled model in your Vault follows your system prompt and JSON formatting rules.
  • Align context limits. Don't fail a 100k-token request over to a model with a smaller context window.
  • Avoid double retries. If you use the OpenAI SDK's default retries and router retries, a total outage multiplies wait time. Keep client retries low when the router already fails over across providers.

SentioGate's limits

See also our OpenAI 429 guide and OpenRouter 429 guide.

Sources

All accessed 2026-10-26.