Errors

Errors reach you unchanged. We do not rewrite them, retry them, or reroute around them.

No capacity

The most common failure. It means we could not serve that model at that moment. It is not a problem with your key, your request, or your balance.

It arrives as HTTP 424:

{"error": {"code": "provider_error",
  "type": "api_error",
  "message": "Provider error (request id: ...)"}}

Match on the HTTP status, never on the message text. The message is deliberately neutral and carries no detail about what went wrong. Keep the request id: it is the only handle support can trace.

Capacity usually returns on its own. Retry on your own schedule, with backoff and jitter, and bound the attempts.

A 424 does not always mean the service is down. Request parameters are not validated before being forwarded, so a request that the model rejects — an out-of-range temperature, for example — comes back as the same 424 provider_error as a genuine outage. We measured this: temperature: 1.5 returns 424 while 1.0 succeeds in the same minute.

Retrying that is a loop that can never succeed. Before treating a 424 as an outage, re-send a known-good minimal request on the same model. If that works, the fault was in the original request.

Balance exhausted

Requests are rejected once the key's prepaid balance reaches zero. Top up to resume.

A client-side timeout still costs money. If you disconnect while a request is running, the work continues, completes, and is billed. Retrying on timeout can pay twice for one answer. Set a timeout longer than you think you need — over a minute is normal for long generations.

Failed requests are free

A request that genuinely fails — including a no-capacity error — is not billed. Only completed work is charged.