iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Set model to openrouter/auto to let OpenRouter choose a model for each request. To influence which host serves the selected model, add a separate provider object. Model selection answers “which model?”; provider routing answers “which provider serves it?” These controls work at different layers, and a provider must offer a compatible endpoint for the model Auto Router selects.
Let OpenRouter choose the model
Send openrouter/auto as the request’s model value. Auto Router evaluates the prompt and selects from its current candidate models. The response’s model field identifies the model that answered. Because the candidate pool can change, check the current catalog rather than treating any example list as permanent. OpenRouter’s Auto Router documentation describes this behavior.
Auto Router is useful when a workload varies and different prompts may be better served by different models. A fixed model slug is more predictable when you need a known model for a particular task, output style, or application requirement.
Choose or constrain the provider separately
Add a provider object in the request body to express provider preferences or restrictions. This structural example prefers one provider but permits fallback routing:
#1 Best Overall
{
"model": "openrouter/auto",
"messages": [{"role": "user", "content": "..."}],
"provider": {
"order": ["preferred-provider"],
"allow_fallbacks": true
}
}The example does not guarantee that the named provider hosts every model Auto Router might select. The chosen model needs a compatible endpoint there. OpenRouter’s Provider Routing documentation describes the available controls.
ordersets an explicit provider sequence to try.onlyrestricts routing to an allowlist.ignoreexcludes specified providers.allow_fallbackscontrols whether other providers may be tried if the preferred route fails.
If you disable fallbacks, the request may have no route when the selected provider is unavailable or lacks a compatible endpoint. For strict provider control, make both the eligible providers and fallback policy explicit.
Know what provider routing does by default
When provider sorting and ordering are unset, OpenRouter documents a price-oriented balancing strategy that also accounts for recent instability. Providers with significant outages in the previous 30 seconds are moved behind stable endpoints. Among low-cost stable providers, the documented example uses inverse-square price weighting: a provider priced at $1 per million tokens is nine times as likely to be tried first as one priced at $3, all else equal. Remaining providers can serve as fallbacks. This is an explanation of the documented strategy, not a promise about the route for any particular live request.
Free tools Windows power users keep installed
One-click scans. No signup required.
Setting provider.sort or provider.order disables that default load balancing and makes routing follow the specified sort or order.
Rank #3
Choose a routing preference that fits the request
| Goal | Setting | What to expect |
|---|---|---|
| Lower price | sort: "price" |
Prioritizes lower-priced providers. A max_price ceiling can leave no eligible endpoint and cause the request to fail. |
| Higher throughput | sort: "throughput" |
Prioritizes throughput. |
| Lower latency | sort: "latency" |
Prioritizes lower latency. |
| Specific provider sequence | order: [...] |
Tries providers in the stated order rather than using default load balancing. |
| Restricted provider set | only or ignore |
Limits eligible providers by allowing or excluding them. |
Performance preferences such as minimum throughput or maximum latency are soft: endpoints outside the preferred range are moved later, not ruled out, so the setting does not guarantee a threshold. Other eligibility and policy filters include data_collection, zdr, and require_parameters. For privacy- or compatibility-sensitive use, confirm current endpoint metadata and account-level policies before relying on a route.
OpenRouter also documents the :nitro and :floor model suffixes as shortcuts: :nitro sorts for throughput and permits priority-tier endpoints, while :floor sorts for price and permits flex-tier endpoints. These variants affect service-tier eligibility as well as sorting, so they do more than set provider.sort.
Use model fallbacks when the model itself may need to change
Provider fallback keeps the requested model and tries another host for it. Model fallback changes the model: supply a models array in priority order, and OpenRouter can try the next model after documented errors such as context-length validation, moderation flags, rate limits, or downtime. The final model used is returned in the response and determines the request’s model pricing. Do not confuse this array with provider.order, which specifies providers rather than models. See OpenRouter’s model fallback documentation.
For the Anthropic Messages API, the documented fallbacks field is a separate option: it cannot be combined with models, accepts at most three entries, and is handled by OpenRouter’s routing.
Check available models and verify the route
Use the live Models API to find current choices. Its filters cover query or name, category, parameter support, modality, context, price, author, hosting provider, ZDR, and region; it also supports sorting by price, context length, throughput, latency, popularity, weekly activity, recency, and benchmark indices. Model slugs, pricing, capabilities, and endpoint availability can change, so verify them when implementing and whenever requirements change.
Quick Recap
- Send the request with
model: "openrouter/auto"and the provider preferences or restrictions your application needs. - Inspect the response’s
modelfield to identify which model answered. - For provider-sensitive behavior, consult current endpoint documentation and the request/response metadata available to your integration; do not infer a provider solely from the selected model.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
