Backboard now supports OpenRouter automatic model selection (openrouter/auto) and per request provider selection. Here is how both work, with JSON examples for the Backboard API.
Short answer
Backboard now gives you two independent routing controls for OpenRouter requests:
-
Automatic model selection. Set
llm_providertoopenrouterandmodel_nametoopenrouter/auto. OpenRouter classifies the prompt and picks the model. You pay the standard rate of the model it chooses, with no additional router fee. -
Provider selection. Pin a specific model to a specific upstream provider with the
openrouter.providersarray, and keepallow_fallbackson so the request still completes when that provider is unavailable. Both are live now in the Backboard API and in the Python and TypeScript SDKs from v1.5.16 onward.
Why model routing is now two decisions, not one
Most LLM routing writeups treat "which model" as the whole question. It is not.
OpenRouter aggregates 17,000+ models, and many of those models are served by more than one upstream provider. The same model weights can sit behind different pricing, different throughput, different context handling, and different uptime depending on who is running them. So there are two decisions in every request:
- Which model should answer this prompt?
- Who should run that model? Until this release you answered the first question and inherited an answer to the second. Now you can set both, or delegate both, per request.
How do you let OpenRouter choose the model automatically?
Set the model name to openrouter/auto. OpenRouter classifies the incoming prompt and routes it to a model it judges appropriate for that class of work.
{
"llm_provider": "openrouter",
"model_name": "openrouter/auto",
"openrouter": {
"cost_tier": "low"
}
}
This is useful when your traffic is mixed. A support inbox that receives one line acknowledgements and multi page technical escalations does not need the same model for both. Automatic selection sizes the model to the prompt instead of forcing you to build that classifier yourself.
Does openrouter/auto cost extra?
No. You pay the standard rate of whichever model OpenRouter selects. There is no additional router fee layered on top.
How do you constrain automatic model selection?
Automatic does not have to mean unbounded. Three fields inside the openrouter object narrow the candidate set before selection happens.
| Field | What it does | Example |
|---|---|---|
allowed_models |
Restricts selection to a list or pattern of models | ["anthropic/*"] |
excluded_models |
Removes specific models from consideration | ["some-vendor/experimental-model"] |
cost_tier |
Caps how expensive a model the router may reach for, from low to max
|
"low" |
allowed_models: ["anthropic/*"] limits automatic selection to that vendor family. That pattern matters for teams with a procurement, residency, or vendor approval constraint. You get automatic selection inside a boundary you defined, rather than automatic selection across everything.
cost_tier is the blunt lever. Set it to low for high volume, low stakes traffic. Raise it for work where an extra few cents per call is irrelevant next to the cost of a wrong answer.
How do you choose which provider serves a model?
Pass a providers array inside the openrouter object. The request is routed to that provider for the model you named.
{
"llm_provider": "openrouter",
"model_name": "moonshotai/kimi-k3",
"openrouter": {
"providers": ["together"],
"allow_fallbacks": true
}
}
Here the model is fixed and the provider is fixed. You chose moonshotai/kimi-k3, and you chose who runs it.
This matters when you have benchmarked providers against each other and found a real difference, when one provider's pricing for a given model is materially better, or when you have an existing commercial relationship with one of them.
What happens when your chosen provider is unavailable?
That is what allow_fallbacks is for. With allow_fallbacks: true, the request can fall back to another provider serving the same model when your selected provider is unavailable. Your preference is honored when it can be, and the request still completes when it cannot.
Set it to false when the provider choice is a hard requirement rather than a preference, and you would rather see the request fail than silently run somewhere else.
Which option should you use?
| Your situation | Use |
|---|---|
| Mixed prompt complexity, no strong model preference |
openrouter/auto with a cost_tier
|
| Vendor family is constrained but model choice is not |
openrouter/auto with allowed_models
|
| You know exactly which model you want | Pin model_name, leave provider unset |
| You know the model and the provider you want | Pin model_name plus openrouter.providers
|
| Provider choice is a hard requirement |
providers with allow_fallbacks: false
|
These are per request settings, not account level settings. Different endpoints in the same application can make different choices.
How do you know which model actually ran?
The response tells you. Backboard returns the provider and model that handled the request alongside token counts, so automatic selection does not become a visibility gap. You can log what ran, attribute cost to it, and audit routing behavior after the fact.
That is the practical objection to automatic routing, and it is the reason the response carries the answer rather than leaving you to infer it.
Where can you see which providers serve a given model?
The Backboard Model Library now surfaces provider options for OpenRouter models, alongside pricing, context limits, uptime, and other model information.
Browse it here: https://app.backboard.io/dashboard/model-library
Check the library before you hardcode a provider name. Provider availability for a given model changes.
What do you need to use this?
- A Backboard API key from https://app.backboard.io
-
llm_providerset toopenrouter - Backboard API, or the Python or TypeScript SDK at v1.5.16 or later Backboard's free tier includes $5 in memory credits and requires no credit card. Inference is billed separately.
Full parameter reference: https://docs.backboard.io/concepts/messages
FAQ
What is openrouter/auto?
It is a model identifier that hands model selection to OpenRouter. Instead of naming a specific model, you name openrouter/auto, and OpenRouter classifies the prompt and selects a model for it.
Does automatic model selection add a fee?
No. You pay the standard rate of the model that gets selected.
Can I limit automatic selection to certain models?
Yes. Use allowed_models to restrict the candidate set, excluded_models to remove specific models, and cost_tier to cap price, on a scale from low to max.
Can I choose which provider serves a model on OpenRouter?
Yes. Pass a providers array inside the openrouter object in your Backboard request body.
Does provider selection work with automatic model selection?
Provider selection applies to a model you have named. If you delegate model choice to openrouter/auto, you are also delegating the provider that serves it.
What does allow_fallbacks do?
With allow_fallbacks: true, a request can move to another provider serving the same model when your selected provider is unavailable. With it off, the provider choice is strict.
Which SDK versions support this?
Python and TypeScript SDK v1.5.16 and later, plus the Backboard API directly.
How do I find out which model handled my request?
The API response reports the provider and model that ran, so automatic selection stays auditable.
Summary
-
model_name: "openrouter/auto"delegates model choice to OpenRouter at no extra fee. -
allowed_models,excluded_models, andcost_tierkeep that delegation inside boundaries you set. -
openrouter.providerspicks who serves a named model, andallow_fallbacksdecides whether that pick is a preference or a rule. - The response reports what actually ran.
- Available now in the Backboard API and in the Python and TypeScript SDKs from v1.5.16. Choose the model. Choose who runs it. Backboard handles the rest.
Top comments (1)
The nice part here is that model selection and provider routing become something you can control without giving up OpenRouter’s flexibility. ~