Service levels are agreed per account
Start with what this page is not. There is no published uptime percentage and no historical availability chart, because a number on a marketing page has no contract behind it. The service level for an account is written into its order form. What follows is how Router behaves today, which is the claim we can stand behind for everyone.
What Router does when a provider fails
Each model is served by one provider today, so when that provider fails, the failure reaches your application. Router makes it a failure you can handle:
- Errors keep the OpenAI shape and HTTP status. The retry and fallback logic your SDK already has keeps working, because what arrives is what an OpenAI-compatible client expects.
- Every response carries a request id, in the
X-Runix-Request-Idheader and inside error messages, so a failed call can be traced to one request rather than argued about. - Streams pass through, not buffered. A stream that stops at the provider stops for you at the same moment, instead of after a replay, and Router waits up to 15 minutes for an answer, so a slow-thinking model is not cut off at the gateway.
Failover between providers
Moving a request to a second provider is only safe when that provider serves the same model under terms you would accept. Where an account needs it, failover between providers is set up for that account, with the models it covers and the providers it may use named in writing. Until that is in place for yours, treat each model as served by one provider and keep your own retry logic.
What you can verify yourself
The request id, the usage object on every response and the request log in
the console are the same records we use. The Router quickstart
documents the error shape, the limits a key carries and what happens when a provider fails.
What is not here yet
A continuously updated public status feed is not live. When it is, it will report measured availability rather than an aspiration. Until then, the honest answer to "what is your uptime" is that we will tell you what we have measured for your workload, and we will not quote a number we cannot evidence. If availability guarantees are a procurement requirement for you, say so in your first message.