Name a model. The router picks a healthy provider for it from 16, fails over before the first token and tells you what it did.
An unknown model is a 404 that names the id. The router never swaps in a different model.
Once the first token reaches you, the request stays with that provider. If it fails then, you get one error event and decide whether to retry.
A content-policy refusal comes back to you. The router does not shop the prompt around other providers.
Keep the providers that list the exact model id you asked for. No fuzzy matching and no silent substitute.
A provider cooling down after failures sits out until it recovers.
By each provider's live listed price, unless provider.order or your key's routing policy sets the order. The first to send output serves you.
curl https://api.routerplus.com/v1/chat/completions \
-H "Authorization: Bearer $ROUTERPLUS_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "z-ai/glm-5.3-flash",
"messages": [{ "role": "user", "content": "Hello" }],
"provider": { "order": ["morphllm", "deepinfra-chat"] }
}'only limits the request to the providers you name, ignore skips them, and POST /v1/route shows the plan without sending the request. Routing docs
| provider field | Effect |
|---|---|
| order | Try these providers first, in this order. The rest stay as fallbacks. |
| only | Use only these providers. |
| ignore | Never use these providers. |
| allow_fallbacks | false keeps only the first route; if it is resting, you get a 503 with retry-after. |
| max_price | Leave out providers above a prompt or completion price per million tokens. |
| require_parameters | true returns a 400 instead of dropping a field the provider does not take. |
Per request in the body, or saved per org, workspace or key as a routing policy. Routing policies
curl https://api.routerplus.com/v1/route \
-H "Authorization: Bearer $ROUTERPLUS_API_KEY" \
-H "Content-Type: application/json" \
-d '{ "model": "z-ai/glm-5.3-flash", "provider": { "order": ["morphllm"] } }'| Header | Tells you |
|---|---|
| x-tm-provider | The provider that served the request |
| x-tm-attempts | How many providers were tried |
| x-tm-upstream-model | The id the provider received, when it differs from yours |
| x-tm-dropped-params | Fields that were dropped, by name |
GET /v1/generation?id= shows every attempt behind one request. Routing docs
A service between your code and the model providers that decides where each request goes. On RouterPlus you name the model, and the router picks a provider that serves it, fails over when one is down and reports the route it took.
It keeps the providers that serve the exact model id, drops any resting after failures, and tries the rest in order of live listed price. provider.order puts the providers you name first; a routing policy on your key keeps its saved order.
No. The router only chooses among providers of the model you asked for. An unknown model is a 404 that names the id, and a dedicated endpoint never routes to a different model.
Before any output reaches you, the router moves to the next provider with zero backoff. After output starts, it stays with that provider: you get the tokens produced plus one terminal error event, and the retry is your call.
24 models in the catalog are served by more than one provider, so the router has somewhere to fail over to. A request limited with only, or with allow_fallbacks set to false, gives that up.
Yes. A routing policy saved for an organization, workspace or key sets the order and who pays. A request's provider object can narrow a saved policy but never adds routes to it.
You pay for every settled attempt, including ones that failed over, because the provider billed for them. usage.cost on the response is the full request total and x-tm-attempts shows how many dispatches happened.