Handling provider downtime

​

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 in addition.
• Provider status, live. 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.
• Anything else. Write to security@aireserve.com; the inbox is monitored by our team around the clock, as is your shared Slack channel.

​

How we keep you running

​

Keep a direct provider path ready

​

Ride out a provider incident without leaving the gateway

• 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.

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)

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<OpenAI.ChatCompletionCreateParamsNonStreaming, "model">;

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);

• 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

​

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, 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.
• 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