All systems operational
Checked live at Thu, 22 Oct 2026 10:29:06 UTC. Latency is the round trip of that check from our servers. We do not publish an uptime percentage until we have the incident history to back one.
/v1/chat/completions, /v1/responses, /v1/completions and /v1/embeddings — every synchronous path, streamed or not. Checked against the gateway on each load.
No video model is served yet. The asynchronous submit-and-poll endpoints. Shown as not offered while no video model in the catalogue is served by an upstream.
Sign-in, API key creation, usage history and account settings. Nothing here affects requests already in flight.
Checkout, top-ups and crediting. A billing incident delays new credit landing; it never removes credit you already hold.
How a degraded upstream reaches your code
It arrives as an error you can branch on, never as a different model's answer.
When a model provider degrades, the request fails with the upstream status and a machine-readable code. There is no automatic cross-model fallback: substituting a model changes the output, the price and the licence terms of what you receive, so an honest error is preferable to a quiet substitution you find out about in production. If you want a fallback, implement it against the codes below — that way you choose the replacement model.
| What you get back | What it means | What to do |
|---|---|---|
| 429 · insufficient_credits | Your prepaid balance is exhausted. Nothing was charged for the request. | Top up. Backing off will not help. |
| 429 · rate_limit_exceeded | You are being rate limited upstream. | Back off exponentially with a cap. Topping up will not help. |
| 401 / 403 | The key is missing, invalid, or not permitted to use that model. | Check the Authorization header, then the key's restrictions. |
| 404 · unknown model id | The id does not resolve. Model ids are namespaced provider/model-name. | Send the full id from GET /v1/models. |
| No available channel | The model is catalogued but no upstream currently serves it. | Pick a model that is served today, or watch the changelog. |
| 5xx | An upstream failed or timed out mid-request. | Retry with exponential backoff and a ceiling. Failed requests are not billed. |
One translation happens on the way out: the gateway answers an exhausted balance with its own 403, and we restate it as 429 with insufficient_credits, because a client written against the OpenAI contract treats 403 as permanent and 429 as retryable — and “top up and try again” is the retryable case. The full table is in the media API reference.
When a request fails, check in this order
Four of the five most common causes are visible from your own side.
- 1
Read error.code, not just the status. On a 429 it is the only thing separating an empty balance from a rate limit, and the two remedies are opposites.
- 2
Confirm the model is served. 7 of the 24 catalogued models are callable today; GET /v1/models with your key is the authoritative list for your account.
- 3
Check your balance in the dashboard. The balance is a hard ceiling enforced on every request, so exhaustion presents as a sudden, total failure rather than a gradual one.
- 4
Check this page, and the changelog for anything tagged Changed — a contract change that affects code you already wrote is tagged so it can be found without reading every entry.
- 5
If none of those explain it, send us the model id, the full error body and a UTC timestamp. That set is usually enough to answer on the first reply.
What we commit to, and what we do not
Pay-as-you-go accounts have no contractual uptime or latency target. Contractual SLAs exist only inside negotiated enterprise agreements, and we would rather say that plainly here than publish a number nothing obliges us to meet. What does hold for every account: a failed request is not billed, your balance cannot be exceeded, and a model we cannot serve is marked unavailable in the catalogue before you call it rather than after.
For anything this page does not explain, the fastest route is support.