Automatic failover,
so your model is never down

Pass a list of models instead of one. On Opper the model field of a /v3/call accepts an array, for example anthropic/claude-sonnet-4-6, then aws/claude-sonnet-4-6-eu, then openai/gpt-5.5, and the gateway tries them in order on retriable errors such as timeouts, 429 rate limits and 529 overload. Your plan B travels with the request, so changing it is a config change rather than a redeploy, and no retry loop lives in your application code.

Ask for measurements rather than an SLA number. What matters for a gateway is not its own uptime in isolation but how often at least one route to your model stayed up, because that is what your requests experience. The table on this page reports exactly that for the models Opper serves, over a rolling 30 day window, next to what a single route to the same model averaged. Opper adds no markup on tokens and charges a 3% fee on credit purchases, so routing across providers does not cost more than routing to one.

Point your existing OpenAI, Anthropic or Gemini SDK at https://api.opper.ai/v3/compat with one Opper key, then name models as provider/model. Many models are served by several providers at once, for example the same Claude model through Anthropic, AWS Bedrock and Azure, and the gateway balances across them for you, so a single model name keeps working when one route is busy. You can also name explicit fallbacks for full control over the order.

Yes. Opper is hosted in the EU on AWS Stockholm and routes to EU-resident model endpoints where they exist, with automatic failover between them, so redundancy does not force traffic outside Europe. You can restrict routing to EU-hosted routes and still keep more than one route for many models. GDPR applies to that processing, and a DPA is available.

Anthropic returns overloaded_error with status 529 when its API is temporarily at capacity, it signals load rather than a problem with your request. Backing off and retrying usually resolves it. On Opper the same Claude models are also served through AWS Bedrock and Azure, and the gateway treats 529 as retriable and balances across routes, so a busy hour does not have to reach your users.

A 429 means you have hit the request or token rate limit for your tier. Direct fixes are backing off, batching, or moving to a higher tier. Through Opper you can also configure a fallback chain, the gateway detects rate limits and tries the next model or route within roughly 180ms, so traffic bursts turn into slightly different routing instead of dropped requests.

Yes. Every call through Opper yields a trace with the model that answered, its latency and its cost, so a request that took a fallback route is visible at the time rather than in a post-mortem. Failover you cannot see is failover you cannot trust, which is why it is part of the same gateway rather than a separate tool.

It depends on how many independent routes a model has and how much their unavailability overlaps. The measured figures on this page show the shape of it: models served by several providers rarely lose every route at once, so any-route availability sits well above what a single route to the same model averaged over the same window. Models with one route today get no benefit from balancing and are the ones worth naming a fallback model for.

From StatusGator, the monitoring service behind status.opper.ai, which tracks each provider's official status feed alongside the Opper API. Uptime is computed over rolling windows, model route rosters are resolved live from the Opper catalog, and this page refreshes every few minutes. Per-provider status and alert subscriptions live on status.opper.ai.