OpenRouter model routing chooses which provider endpoint serves a model request. Learn how to balance price, speed, capability, reliability, and privacy without hiding changes in the serving route.
Routing is the real value of a gateway
OpenRouter separates the model your application requests from the provider endpoint that serves it. A good routing policy balances capability, price, latency, availability, privacy, and reproducibility instead of chasing one “best” model.
Checked October 15, 2026: provider availability, pricing, and routing controls change. Confirm all fields in the official provider-routing guide.
Start with the default router
For a normal model request, OpenRouter selects an eligible provider based on availability and its current routing logic. That is the right baseline for most prototypes. Log the returned model, request ID, latency, usage, and safe provider metadata before adding constraints.
curl https://openrouter.ai/api/v1/chat/completions -H "Authorization: Bearer $OPENROUTER_API_KEY" -H "Content-Type: application/json" -d '{"model":"anthropic/claude-sonnet-4","messages":[{"role":"user","content":"Summarize this note."}]}'Choose the routing objective
| Objective | Policy idea | Risk |
|---|---|---|
| Lowest cost | Prefer inexpensive eligible endpoints | Latency or capacity may vary |
| Lowest latency | Prefer fast providers/regions | May cost more |
| Maximum uptime | Allow multiple providers and fallbacks | Outputs become less reproducible |
| Privacy | Require approved data policies such as ZDR | Fewer eligible endpoints |
| Consistency | Pin model, provider order, and parameters | Lower resilience |
Provider preferences
{
"model":"anthropic/claude-sonnet-4",
"messages":[{"role":"user","content":"Extract action items."}],
"provider":{
"order":["anthropic","amazon-bedrock"],
"allow_fallbacks":true
}
}Treat provider names and schema as live configuration. Test a deliberate primary outage and verify the request reaches the next eligible endpoint.
Use price and latency deliberately
Do not optimize only the per-token headline. A cheap slow model can cost more operationally if retries, user abandonment, or long queues rise. Track p50/p95 latency, success rate, tokens, cost per successful task, and quality acceptance.
Capability filtering
Routing cannot create capabilities an endpoint lacks. Before requesting tools, JSON schema, images, PDFs, or large context, query the models catalog and confirm supported parameters. A strict capability filter is safer than hoping a fallback behaves identically.
Privacy and Zero Data Retention
If policy requires specific provider data handling, encode that requirement in routing and verify the remaining provider pool is large enough. Privacy restrictions can reduce resilience; document the trade-off and never silently relax them during an incident.
Routing test matrix
- Primary provider healthy.
- Primary provider rate-limited.
- Model unavailable at one endpoint.
- Strict privacy filter leaves no endpoint.
- Tool or schema unsupported.
- Fallback returns different quality or price.
Record requested model, returned model/provider, stop reason, latency, usage, cost, and validation result for every case.
Common routing mistakes
- Pinning one provider and expecting gateway-level resilience.
- Allowing every provider without reviewing data policy.
- Optimizing cost before measuring task success.
- Using fallbacks that lack required tools or context.
- Failing to log which route actually served the request.
OpenRouter model routing FAQ
Should I always set provider order?
No. Start with defaults, measure, and constrain only when you have a requirement the default cannot express.
Can routing guarantee the cheapest response?
No. Prices and availability change, and retries or long latency affect real cost. Use live metadata and your own outcome metrics.
What next?
Read the fallback guide, pricing guide, and complete OpenRouter guide.
Official references
Documentation reviewed 15 October 2026. Examples illustrate the request pattern; confirm model availability and account settings before use. No uptime or performance benchmark is claimed.
