> ## Documentation Index > Fetch the complete documentation index at: https://docs.aireserve.com/llms.txt > Use this file to discover all available pages before exploring further. # Handling provider downtime > Your continuity plan for the gateway: how you would know about an incident, how we keep you running through a provider incident, how you switch to a direct provider connection if the platform itself is down, what you never lose, and what we commit to. No gateway can route around its own outage, and we would rather say so than imply otherwise. What we can do is make an outage visible fast, make the switch to a direct provider connection a configuration change rather than a migration, and leave nothing of yours stranded. The platform side of the story, what is redundant and what is not, is on [Reliability](/reliability). ## How you would know * **Incident updates from us.** For any incident that affects your traffic we post in your shared Slack channel and email your organization's administrators: a first update within 30 minutes of our detection, further updates at least hourly until it is resolved, an all-clear, and a written post-incident review within ten business days. The 30 minutes does not depend on anyone noticing: detection is automated (external checks on the API every 60 seconds, a platform-health sweep every 5 minutes, the provider status feed) and pages the engineer on duty at any hour, and the first update is deliberately short, focusing on what is affected, what we know, and when the next update will come, so that you are never waiting for information. Security incidents involving personal data follow the notice terms of the [Data Processing Agreement](https://aireserve.com/legal/dpa) in addition. * **Provider status, live.** [aireserve.com/status](https://aireserve.com/status) aggregates the status pages of every provider behind the catalog, so you can see in one place whether the incident is upstream of us. * **Your errors say which it is.** During a platform incident the API answers `503` with a stable `SERVICE_UNAVAILABLE` code and a `Retry-After` header, or stops answering at all; a provider incident surfaces as a provider-attributed error with `error.source` set, so your code can tell the two apart without waiting for a human. See [Errors](/api-reference/errors). * **Anything else.** Write to [security@aireserve.com](mailto:security@aireserve.com); the inbox is monitored by our team around the clock, as is your shared Slack channel. ## How we keep you running Two layers do this. During a provider incident the gateway itself keeps your requests flowing: same-model failover to a sibling provider and the fallback chains you configure, described in the next section, all without you changing anything. If the platform itself is unavailable, the second layer is yours: the API is wire-compatible with OpenAI (Chat Completions and Responses), Anthropic (Messages) and the Bedrock SDK surface, so a client that points at AI Reserve can point at the provider directly by changing a base URL and a key, with no code change. Keep that switch ready before you need it. ### Keep a direct provider path ready | If you use | Direct-provider switch | | - | - | | OpenAI SDK (Python, TypeScript, others) | Drop the `base_url` override and use your OpenAI key. OpenAI model ids are unchanged (`gpt-5.5`). | | Anthropic SDK | Drop the `base_url` override and use your Anthropic key. Claude model ids are unchanged (`claude-sonnet-4-6`). | | Claude Code | Unset `ANTHROPIC_BASE_URL` and `ANTHROPIC_AUTH_TOKEN`, then set `ANTHROPIC_API_KEY` to your Anthropic key. | | Codex CLI | Set `model_provider` back to the built-in `openai` entry in `~/.codex/config.toml`, with `OPENAI_API_KEY` in the environment. | | Cursor, Zed, Cline, Continue, Aider, Roo | Clear the custom base URL; the tool uses its built-in provider with your own key. | | AWS SDK (Bedrock surface) | Remove the endpoint override; your AWS credentials talk to Bedrock directly. | | Any other OpenAI-compatible provider (xAI, Google Gemini, Alibaba Cloud Model Studio, Mistral, DeepSeek, Fireworks, Groq, …) | Point the same OpenAI SDK client at that provider's OpenAI-compatible endpoint with its key. Use the model id from the [catalog](/models), which names the provider behind every entry. | For first-party models (OpenAI, Anthropic, Google, xAI) the catalog id is the provider's own model id, so nothing else changes. For open-weight models served by a third-party host, the [catalog](/models) names the provider behind each entry; use that provider's id for the same weights. The one shape that does not transfer is a provider-native SDK the gateway does not speak (for example Google's GenAI SDK): keep an OpenAI-compatible client as the direct path for those providers. ### Ride out a provider incident without leaving the gateway Most incidents are upstream of us: one provider is down or throttling while the rest of the catalog is fine. Two things stand between that and your users, and both run on our side: * **Same model, another provider, automatically.** Several models are served by more than one provider with identical weights and paired for failover (the Claude models on Anthropic and on Amazon Bedrock, for example). Once failover is on for your organization, a request that fails at the primary provider is retried on the sibling provider by the gateway, same model, same request, with nothing to configure per model and nothing for your code to do. The response names the leg that served in `x-aireserve-served-model` (for example `claude-sonnet-4-6-bedrock`), and `x-aireserve-served-provider` as well when the request rode a configured pin or pool. * **Your fallback chain.** For a model you have chained, the gateway walks the chain of models you accept, in order, on the same failures (put the sibling provider first to keep the same weights ahead of a different model). You set it once per model in the portal under Inference → Router, or per request with `models: [...]`; a model you have not chained gets the sibling failover above and nothing more. Both are off until you turn them on: configuring any fallback chain in the portal (or sending `models` on a request) switches failover on for your organization, and requests on your own provider keys ([BYOK](/capabilities/byok)) never fail over to another provider. Every attempt goes through AI Reserve on your key, so billing, usage history and policy are unchanged. Details and edge cases: [Fallback models](/capabilities/fallbacks). The rest of this section is the same chain written on your side, for teams that prefer to own it in code. The gateway relays provider incidents as provider-attributed errors (`error.source` is `provider`), and the fix is to switch models, not endpoints: keep a short chain of models you accept, one per provider, and walk it in order. The SDK's built-in retries handle blips on their own (connection errors, 408, 429 and 5xx with backoff, honoring `Retry-After`). Move to the next model only when a model is still failing after those retries. Never move on a 4xx: that is a request you need to fix, and a `402` is a spend cap doing its job. If `error.source` is `platform`, the chain cannot help and the [direct-provider switch](#keep-a-direct-provider-path-ready) above applies instead. ```python Python theme={"dark"} import os from openai import OpenAI, APIConnectionError, APITimeoutError, InternalServerError client = OpenAI(base_url="https://api.aireserve.com/v1", api_key=os.environ["AIRESERVE_API_KEY"]) # One model per provider, in order of preference. Every attempt goes through the gateway. CHAIN = ["claude-fable-5-1", "gpt-5.5", "kimi-k3-fireworks"] def complete(**request): # `request` is the whole call (messages, temperature, tools, stream, ...). # Only `model` changes between attempts; the chain owns it, the caller owns the rest. last = None for model in CHAIN: try: return client.chat.completions.create(model=model, **request) except InternalServerError as err: if (err.body or {}).get("error", {}).get("source") == "platform": raise # the gateway itself is failing: switch endpoints, not models last = err # provider still failing after the SDK's retries: next provider except (APIConnectionError, APITimeoutError) as err: last = err raise last response = complete( messages=[ {"role": "system", "content": "Answer in two sentences."}, {"role": "user", "content": "Summarize ticket #4821."}, ], temperature=0.2, max_tokens=300, ) print(response.model, response.choices[0].message.content) ``` ```typescript TypeScript theme={"dark"} import OpenAI from "openai"; const client = new OpenAI({ baseURL: "https://api.aireserve.com/v1", apiKey: process.env.AIRESERVE_API_KEY }); // One model per provider, in order of preference. Every attempt goes through the gateway. const CHAIN = ["claude-fable-5-1", "gpt-5.5", "kimi-k3-fireworks"]; type Request = Omit; function platformFault(err: unknown): boolean { return err instanceof OpenAI.APIError && (err.error as { source?: string } | undefined)?.source === "platform"; } function providerFault(err: unknown): boolean { if (err instanceof OpenAI.APIConnectionError) return true; return err instanceof OpenAI.APIError && typeof err.status === "number" && err.status >= 500; } export async function complete(request: Request) { // Only `model` changes between attempts; the chain owns it, the caller owns the rest. let last: unknown; for (const model of CHAIN) { try { return await client.chat.completions.create({ ...request, model }); } catch (err) { if (platformFault(err) || !providerFault(err)) throw err; // ours to fix, or yours: a 4xx last = err; // provider still failing after the SDK's retries: next provider } } throw last; } const response = await complete({ messages: [ { role: "system", content: "Answer in two sentences." }, { role: "user", content: "Summarize ticket #4821." }, ], temperature: 0.2, max_tokens: 300, }); console.log(response.model, response.choices[0].message.content); ``` The same chain with no code: send `models: [...]` on the request and the gateway walks it for you, naming the model that answered in the `x-aireserve-served-model` header. See [Fallback models](/capabilities/fallbacks). Two practical notes: * **Streaming.** The same chain applies to streamed requests; move to the next model only when the stream fails before its first token. A stream that breaks mid-answer is a retry of the same request, not a reason to change models. * **Test the chain.** Run every model in it from staging once a quarter, the same way you would test a backup restore. A fallback nobody has exercised is a hope, not a plan. ### Your own provider keys With [BYOK](/capabilities/byok), requests ride your own OpenAI, Anthropic or other provider account through AI Reserve. Those keys work with us and without us, so the direct-provider switch above needs no second account and no new billing relationship. Customers on platform keys should keep a provider account on standby for the models that matter most; we are glad to help set one up and to size its rate limits against your traffic. ## What you never lose * **Your keys and credentials** are yours. AI Reserve keys can be rotated or revoked by your administrators at any time; BYOK keys stay in your provider account. * **Your usage history.** Every request is a row in your usage analytics, with requested and served model, tokens, cost, status and latency, exportable as CSV from the portal's analytics or through the [MCP usage tools](/connect/mcp-tools), so a finance close or an audit never depends on a single moment of uptime. * **Your data.** API prompts and responses pass through the gateway in memory only and are never written to disk; what is stored is usage metadata. Content that the optional web chat stores for history is deleted within 14 days of a verified request. The authoritative statements are on [privacy.aireserve.com](https://privacy.aireserve.com). * **No lock-in by format.** Because the wire formats are the providers' own, there is no AI Reserve-specific request shape to unwind. ## What we commit to | Commitment | Detail | | - | - | | Honest errors | Platform faults, provider faults and caller errors are distinguishable by code and `error.source`; a failure that was ours is never dressed as yours. | | Incident communication | First update within 30 minutes of detection, updates at least hourly, an all-clear, and a written review within ten business days for affected customers. | | Personal-data incidents | Notice per the Data Processing Agreement's incident terms. | | No charge for failures | A request that fails at the gateway or at the provider is not billed; the wallet reservation is released. | | Published measurements, not a paper SLA | We publish measured availability on [Reliability](/reliability) and will publish a service-level agreement with credits once cross-region failover is in place and exercised. | | Your exit | Keys, usage history and the direct-provider switch above are available at any time, incident or not. | This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.