Reliability

Failover before you ever see an error

Most models are available from more than one provider. A request walks them in order, cheapest first. If a provider answers with a 429, a timeout or a 5xx, we quietly move to the next one — nothing in your response reflects this, except the provider field in the log.

A provider that fails repeatedly is temporarily taken out of rotation (a circuit breaker) and stops slowing down subsequent requests until it recovers. You only get a 503 once every route has been tried and every one of them failed.

What is not replayed

If a provider has already accepted a request and started billing it on their side — say, it created an async generation task — we do not resend the request to a second provider, even if the first one then dies. Otherwise you would pay twice for one image. In that case the error comes back to you as-is.

A moderation rejection is not replayed either: if one provider refused the prompt, another provider of the same model will refuse it too. Such a request returns a 400 content_policy_violation immediately and costs no credits.

Timeouts and cancellation

• A request that outruns its deadline ends in a 504 timeout. The credits held for it are returned to your balance.
• If you drop the connection — cancelling a stream, say — the request is marked 499 client_closed in the log. That is not a service failure.
• A hold whose process died is released automatically — money never gets stuck.

Honest expectations

We provide access to models below official API prices, and part of that difference is dealing with providers, each with its own stability. Failover smooths their outages but does not abolish them: our availability is ours plus that of at least one route to your model. For models with a single provider there is, by definition, no fallback.

Plan for that in production: retry 5xx with backoff, respect retry-after on a 429, and keep a fallback model for the critical path. The status codes are broken down in Errors.