OpenRouter first identifies providers that can serve the selected model and satisfy the request, then orders the eligible endpoints. For ordinary requests, its default routing load-balances across top providers to improve uptime and is primarily price-weighted. For requests that include tools, Auto Exacto runs by default and can reorder providers using tool-call reliability and real-time performance signals.
If the preferred provider cannot serve the request, OpenRouter can try another provider for the same model when fallbacks are allowed. That is different from a model fallback, which changes the model itself.
The shortest accurate routing sequence is:
- Choose or resolve a model.
- Remove providers that cannot satisfy model, parameter, policy, or user restrictions.
- Order the eligible providers using default routing, explicit preferences, or Auto Exacto for tool requests.
- Try an allowed provider.
- If it fails, follow the configured provider or model fallback behavior.
This is a model-serving pipeline, not a complete Agent loop. For the surrounding layers, see the model, provider, and agent-harness distinction.
Last verified: 2026-08-27. Default provider ordering, Auto Exacto signals, routing fields, and fallback behavior can change. Recheck OpenRouter's current routing documentation before deploying a fixed policy.
Model and provider are different choices
A model is the capability and API identity requested by the application. A provider is an endpoint operator that serves inference for that model. OpenRouter can expose more than one provider endpoint for the same model.
The distinction matters because two endpoints serving the same model can differ in:
- current price;
- latency and throughput;
- uptime and rate limits;
- quantization or service tier;
- supported request parameters;
- data-collection and retention policies;
- geographic availability.
Choosing a model therefore does not always fix the endpoint. It defines the model-level contract, and provider routing decides where that contract is served.
Model selection and provider selection should also be measured separately. If a task suddenly becomes slower, more expensive, or less reliable, the cause may be a different model, a different provider, a tool change, or the Agent harness itself.
How default OpenRouter provider routing works
OpenRouter’s Provider Selection documentation says requests are load-balanced across top providers by default to maximize uptime. Its Auto Exacto documentation adds that normal routing without Auto Exacto is primarily price-weighted, with a strong preference for lower-cost providers.
That is more precise than saying, “OpenRouter always picks the cheapest provider.” Default routing balances availability and price across eligible endpoints. A provider must first be able to serve the selected model and satisfy the request’s constraints.
Eligibility can change when a request requires:
- a parameter that is not implemented by every provider;
- a particular data policy or Zero Data Retention endpoint;
- a provider allowlist or blocklist;
- a maximum price;
- a quantization level;
- a specific region or service tier.
Once restrictions are applied, the cheapest endpoint in the full catalog may no longer be eligible. That is expected behavior, not necessarily a routing error.
Provider fallback versus model fallback
The word “fallback” covers two distinct mechanisms.
Provider fallback keeps the model
The allow_fallbacks field in OpenRouter’s provider object defaults to true. If the preferred provider is unavailable, a backup provider can be attempted for the same model.
This improves availability, but the replacement endpoint may have different performance, policy, or price characteristics. If exact provider identity is part of the workload’s contract, allowing an unrestricted fallback can undermine that requirement.
Model fallback changes the model
OpenRouter’s Model Fallbacks documentation describes a models list that can try another model when the primary route fails. Documented triggers include rate limits, downtime, moderation refusals, and context-length validation errors.
A model fallback changes more than the endpoint. It can change tokenizer, context capacity, tool behavior, output style, price, and task quality. Treat it as an application-level policy that needs its own acceptance tests.
If reproducibility is more important than availability, narrow the provider set, disable fallbacks, or stop for review. That tradeoff should be explicit: stricter routing can make a request fail sooner.
Why tool calls change provider ordering
OpenRouter says Auto Exacto runs by default on every request that includes tools. It reorders providers for the chosen model using three classes of signal:
- real-time throughput;
- tool-calling success rate;
- results from OpenRouter’s provider benchmark harness.
The tool-calling success signal is derived from the Tool Call Error Rate shown on a model page’s Performance tab. OpenRouter validates returned tool-call arguments against the schemas supplied by the caller and uses those observed errors as one routing input.
Auto Exacto deprioritizes endpoints that underperform on its signals and moves stronger endpoints forward. It does not prove that every tool call will be correct. A valid JSON payload can still choose the wrong tool, use a semantically wrong value, or pursue a bad plan.
The benchmark and traffic signals are also OpenRouter routing inputs, not a universal ranking of models or providers for every repository. Use them to understand the platform’s ordering, then validate the complete task in your own environment.
Tool calling does not mean the provider executes your tools
The Tool Calling guide defines the standard loop clearly: the model proposes a tool call, the caller executes the tool, and the caller sends the result back to the model.
OpenRouter standardizes the model interface and routes the inference request. Your application or Agent harness still owns the actual file read, shell command, database query, API request, approval step, and result validation.
This boundary matters for debugging. An invalid argument may point to model or provider behavior. A command that ran in the wrong directory belongs to the harness or tool environment. A failed unit test may reveal a bad code change rather than a routing failure.
Auto Exacto can improve which provider is tried first for tool-calling traffic. It does not turn the model-routing layer into a complete Coding Agent.
How to control OpenRouter provider selection
The provider object exposes controls for different operational goals. Do not add every field by default; begin with the requirement that matters.
Require request parameters
Set require_parameters: true when every parameter in the request must be supported by the endpoint. This is useful for workflows that depend on tools, structured output, reasoning controls, or another parameter that is not consistently available across providers.
Without the requirement, an endpoint can still be eligible even when it does not support every optional parameter. That may be acceptable for simple chat, but risky for a strict Agent contract.
Prefer, allow, or exclude providers
ordersupplies provider slugs in the order you want tried.onlyrestricts the request to an allowlist.ignoreexcludes named providers.allow_fallbacks: falseprevents backup providers from being used.
These controls improve predictability but reduce the pool available during downtime or rate limits. Keep the list as broad as the actual policy allows.
Sort by price or performance
OpenRouter supports provider sorting and preferences for price, throughput, and latency. Performance preferences do not necessarily guarantee a threshold; the documentation distinguishes preferences from a hard max_price restriction that can prevent a request from running.
For explicitly price-first routing, OpenRouter also provides a :floor shortcut. The documentation notes that :floor is broader than simply setting provider sort to price because it also makes flex service-tier endpoints eligible.
On tool-calling requests, explicitly sorting by price or using :floor opts out of Auto Exacto and restores price-weighted ordering. That can lower the selected endpoint price, but it removes the quality-aware provider reordering that Auto Exacto applies to tools.
Enforce data-policy requirements
The provider object can restrict data collection and require Zero Data Retention endpoints. These are policy filters, not marketing labels. Verify that the selected settings match the organization’s actual data requirements, and expect a smaller eligible pool.
An illustrative request policy might look like this:
This example does not identify the right policy for every workload. It demonstrates that capability, fallback, and retention requirements belong in routing configuration rather than in an informal assumption.
A routing checklist for coding agents
Use one reproducible task before changing provider policy across a production workload.
- Fix the model ID and Agent harness configuration.
- Define required parameters, tool schemas, data policy, and allowed regions.
- Decide whether provider fallback may change price or policy characteristics.
- Decide separately whether model fallback is allowed.
- Record request ID, returned model, provider information when available, usage, latency, and errors.
- Count invalid tool calls, retries, test failures, and accepted results.
- Compare price-first, performance-first, and default routing only under the same task conditions.
- Keep the least restrictive policy that still satisfies the workload’s requirements.
If cost is the first constraint, start by learning how to compare OpenRouter coding models by price and tools. If automatic model selection is under consideration, first separate Auto Router from the Free Models Router. Those choices happen before or alongside provider routing; they are not substitutes for it.
Frequently asked questions
Does OpenRouter always choose the cheapest provider?
No. Ordinary default routing is primarily price-weighted but also load-balances across top eligible providers for uptime. Restrictions can remove cheap endpoints, and tool-calling requests use Auto Exacto unless price-first behavior is explicitly requested.
What happens when an OpenRouter provider fails?
With provider fallbacks allowed, OpenRouter can try another eligible provider for the same model. If the application also supplies model fallbacks, qualifying errors can cause a different model to be tried.
Does tool calling change OpenRouter routing?
Yes. OpenRouter says Auto Exacto runs by default on requests that include tools and can reorder providers using throughput, tool-call reliability, and its benchmark-harness signals.
Does Auto Exacto execute tools?
No. In the standard tool-calling loop, the model proposes a call and the caller executes it. Auto Exacto changes provider ordering for the inference request.
Can I force a specific provider?
The provider object supports order, only, and ignore, and fallbacks can be disabled. Tighter controls reduce flexibility and can increase failures when the permitted endpoint is unavailable.
Conclusion
OpenRouter provider routing is a sequence of eligibility, ordering, and fallback decisions. Default requests balance uptime with a strong price preference; tool-calling requests add Auto Exacto’s reliability and performance signals. Explicit routing fields can narrow that behavior when parameters, data policy, cost, speed, or provider identity matter more.
The practical next step is not to configure every option. Choose one coding task, state its hard constraints, log the actual route and tool errors, and compare a small number of policies under the same acceptance test. Keep model choice, provider choice, and Agent harness behavior separate so the result remains explainable.