How do OpenRouter's provider.order and allow_fallbacks fields control routing?
answer
- preference list versus hard allowlist
- one boolean decides that difference
- its default keeps you available, not exclusive
- false means fail rather than stray
- order also switches off load balancing
basics
~20 sprovider.order lists upstream providers to try in priority order for the chosen model. allow_fallbacks, true by default, decides what happens when none of them can serve: leave it on and OpenRouter tries other providers, set it false and the request fails instead.
solid answer
~50 sFor a model hosted by several upstreams, OpenRouter by default load-balances across them, weighting by price and observed reliability, and fails over automatically. The `provider` object overrides that. `provider.order: ["provider-a", "provider-b"]` makes OpenRouter attempt those upstreams first, in that sequence, instead of balancing. `provider.allow_fallbacks` decides the escape hatch: left at its default `true`, OpenRouter may still route to providers outside your list once the listed ones are exhausted; set to `false`, your list becomes a hard allowlist and the request errors out with no eligible provider rather than going somewhere you did not name. The related `only` and `ignore` filters shape the candidate pool the same way. The tradeoff is blunt: `allow_fallbacks: false` buys determinism and compliance at the cost of availability, so it belongs on requests where routing to an unapproved upstream is worse than a failed call.
code
json · 10 lines{
"model": "vendor-a/model-name",
"provider": {
"order": ["provider-one", "provider-two"],
"allow_fallbacks": false
},
"messages": [
{ "role": "user", "content": "Extract the invoice total as JSON." }
]
}go deeper
Recall that one model on OpenRouter can be hosted by several providers, and that provider.order lets you say which one you want tried first.
Explain that supplying an order replaces the default load balancing, that allow_fallbacks defaults to true, and that flipping it to false turns your list into a hard allowlist whose exhaustion is an error.
Argue the availability-versus-control tradeoff per workload, and describe the monitoring it implies: serving-provider distribution as a degradation signal and no-eligible-provider errors as an owned SLO.
Set the org-wide default — which classes of traffic may float across providers and which are fenced — and make the fenced case's reduced availability an explicit, budgeted decision rather than an accident.
## Why provider selection exists at all A single model slug on OpenRouter often maps to **several upstream providers** that host the same weights. They differ in price per token, throughput, latency, maximum context they will accept, quantization, supported request parameters, and data-handling policy. By default OpenRouter picks among them for you — balancing load with an eye on price and on how reliably each has been serving recently — and silently retries elsewhere when one fails. That default is good for uptime and bad for anyone who needs to know exactly where their bytes went. The `provider` object in the request body is the override, and `order` plus `allow_fallbacks` are its two central fields. ## order `provider.order` is an array of provider slugs. OpenRouter tries them in the order given, so index 0 is your preferred upstream, index 1 is the next, and so on. Supplying an order **disables the default load balancing** for that request: you are no longer asking for "whichever is best right now", you are asking for a specific sequence. Typical reasons to pin an order: one upstream serves the model at a longer usable context, one is measurably faster for your prompt shape, one is in a jurisdiction your legal team approved, or one has a data policy you can point at in an audit. A hidden reason is *consistency* — the same weights served with different quantization can produce noticeably different output, so pinning the provider stabilises behaviour your evals were run against. ## allow_fallbacks `allow_fallbacks` defaults to `true`. With the default, `order` is a **preference**: OpenRouter starts with your listed providers, and if none of them can serve, it continues to other providers that host the model. You keep the gateway's availability story and merely bias where traffic lands. Set `allow_fallbacks: false` and `order` becomes a **hard constraint**. If none of the listed providers can take the request, OpenRouter does not improvise — it returns an error saying no available provider meets your routing requirements. Nothing is served from an upstream you did not name. That single boolean is the whole availability-versus-control decision, and it is the field interviewers push on. Leaving it true on a compliance-fenced workload means that under load — exactly when failover kicks in — your traffic can reach a provider your policy excludes. Setting it false on a consumer chat path means a single upstream's bad hour becomes user-visible errors that the gateway could have absorbed. ## The neighbouring filters `order` is not the only way to shape the candidate pool. `provider.only` restricts routing to a named set, `provider.ignore` excludes specific upstreams, `provider.quantizations` keeps routing to weights at a given precision, and `provider.sort` (`price`, `throughput`, `latency`) replaces balancing with a ranking rule. These compose: a common production shape is a short `order` for preference plus `allow_fallbacks: true` for resilience, with `ignore` carving out the one upstream you have had trouble with. A stricter shape is `only` plus `allow_fallbacks: false` for a regulated pipeline. Note that provider preferences apply *within* a model. They are orthogonal to a `models` fallback array, which crosses to different models entirely. A well-built production request often uses both: pinned providers for the primary model, and one vetted alternative model as the outer safety net. ## Operating it Whatever you configure, record which provider served each request — OpenRouter reports the serving upstream on the response — and treat a shift in that distribution as a signal. If you pinned an order and most traffic is landing on entry two, entry one is degrading. If you set `allow_fallbacks: false`, watch the no-eligible-provider error rate as a first-class SLO, because you deliberately converted a silent degradation into a visible failure and you now own the alerting for it. ## Common mistakes Believing `order` alone guarantees exclusivity — it does not, because fallbacks are on by default. Believing `allow_fallbacks: false` makes requests fail *faster* — it changes eligibility, not timeouts. And conflating provider order with model fallback: they solve different failures and neither substitutes for the other.
- What happens if you set order but leave allow_fallbacks at its default?Your list becomes a preference rather than a rule. OpenRouter attempts your providers in sequence, and when none of them can serve it continues on to other upstreams that host the model. You bias traffic without giving up availability — which is right for most workloads, and wrong for any request that must never touch an unapproved provider.
- How does provider.order relate to a models fallback array in the same request?They operate at different layers and compose. Provider preferences choose among the upstreams hosting one model; the models array crosses to a different model when the current one cannot be served at all. A common production shape is pinned providers on a primary model plus one vetted alternative model behind it, so provider-level trouble is handled quietly and model-level trouble is handled explicitly.
- Why might pinning a provider improve output consistency, not just compliance?The same model can be served at different quantization levels and with different effective context limits depending on the upstream. Those differences show up as small shifts in wording, formatting, and occasionally in whether a long prompt fits at all. If your evaluations and your output parser were tuned against one upstream, pinning it removes a source of drift you would otherwise chase for weeks.
saying these in an interview costs you the question
- Thinks provider.order alone guarantees no other provider is used
- Believes allow_fallbacks defaults to false
- Says allow_fallbacks:false just makes failures happen sooner
- Confuses provider order with the models fallback array
- Assumes all upstreams serving one model behave identically