Routing
How a model name becomes a concrete backend, and what that means for your requests.
The model you send is a name, not an address. Behind each name sits an ordered
list of backends able to serve it, and your request is given to the first one
that can. If it cannot, the next one gets it — see
Failover & retries.
You do not choose the backend, and you do not need to declare a fallback.
What your request asks for narrows the choice
Some requests can only be served by some backends. Ask for tools, reasoning,
image or file input and the request is restricted to backends advertising that
capability; a plain chat request can go anywhere the model is served. Asking for
web search restricts it to backends advertising tools, since the search is run
here rather than by the model — see Web search.
Capabilities are listed per model, not per backend
GET /v1/models reports everything a model's backends can do, combined. If two
capabilities are supported by different backends and no single one supports
both, a request asking for both is rejected with a 400 — even though the
model appeared to offer each of them.
In practice: when you need two capabilities at once, test the combination rather than trusting the model listing.
The same name can be served by different backends
One request may be answered by the network and the next by the fallback provider,
with no difference in the API. The model is the same model, but the machinery
serving it is not identical, so outputs are not reproducible token-for-token
across requests — seed will not give you that here.
If you need a run to be repeatable, capture the output rather than expecting to regenerate it.