Routing
Understand route selection and failover for a model.
You choose a model. The platform selects a route supporting that model and your request protocol. A model can have multiple routes, whose number and health can change.
From request to route
The platform checks the model, protocol, and parameter requirements, then selects an available route using health and priority. Alternatives must support the same protocol; failover does not silently translate between Chat, Responses, and Messages.
Session affinity can influence eligible routes within the same priority. Priority does not permanently bind a supplier or guarantee the cheapest route on every call.
Failover
After a retryable upstream failure, upstream rate limit, or unavailable route, the platform can try another suitable route. If no alternative exists or attempts still fail, the request returns an error. Retries are not unlimited, and an already-started stream is not guaranteed to resume seamlessly.
Failover cannot repair invalid caller parameters. Applications must still check completion and handle failures using errors and limits.
Parameter requirements and provider selection
provider.require_parameters requires routes to declare support for relevant tool and sampling parameters in the request. It narrows eligible routes; it does not add model capabilities or guarantee a tool call or particular answer. Requests can be rejected when no route meets the requirements. See the Chat API reference for parameter support.
Provider-selection options order, only, and ignore within provider are BYOK-only. Capability constraints such as require_parameters are not provider selection. The platform chooses routes for platform models. BYOK is coming soon; do not depend on it to select platform suppliers.