Fallbacks
allow_fallbacks decides whether a failed request moves on to the next endpoint of the same model. Switching is your call, and the platform does not switch by default.
Default: locked to the first endpoint
allow_fallbacks defaults to false. The platform orders endpoints by the default routing rules or your provider settings and tries only the first one. If it fails you get the error; the request does not move to another endpoint, let alone another model.
Failed attempts are free. Upstream errors and timeouts return 502 upstream_failed; upstream rate limiting returns 429 capacity_exhausted with Retry-After.
Turning it on
Set "allow_fallbacks": true in provider, or enable it in the account or key default preferences. The effective value is decided by request, then key, then account, then the platform default (false).
Once it is on, a failed first endpoint moves the request to the next one in order, and a request tries at most 3 endpoints. These errors trigger a switch:
- Connection failures and timeouts
- HTTP 429 and HTTP 5xx
- Upstream authentication failures
- Errors specific to that endpoint: context length exceeded, an unsupported parameter, or a refusal under the provider's own content policy
Other request errors, such as a plain 400 or 413, do not switch; you get them directly, since another endpoint would answer the same way. When every attempt fails, you get 502 upstream_failed.
Only the attempt that succeeds is billed, at the price of the endpoint that served it; failed attempts are free. See Attempts and settlement. If the client disconnects, the platform closes the upstream connection right away and does not switch.
Streaming requests
A streaming request can switch only before the first content event, which is the first event carrying non-empty text, reasoning or a tool call. Empty events the upstream sends before it are not forwarded to you. If the upstream breaks off after content has started, the platform ends the response with an SSE error event, does not switch, and bills the usage produced so far.
Timeouts
Until the first content event arrives, all attempts share one total timeout, 600 seconds by default; once it runs out no new attempt starts. After the first content event that total no longer applies. The idle timeout between events takes over, 120 seconds by default, so the request times out only when the upstream goes 120 seconds without a new event. Streams also have a 60-minute cap on total duration. A non-streaming request, all attempts included, must finish within the 600-second total.
Switching never loosens constraints
Every attempt comes from the same candidate set: data policy, data processing region, quantization and other limits apply to each attempt, and attempts stay within the same model's endpoints.