Today we’re launching the next generation of Auto Router. Taking all we’ve learned from running Auto Router for the past 3 years, we rebuilt it from the ground up on an entirely new technical foundation that outperforms the old router by up to 4× depending on the benchmark, with a routing step that is 3× faster at the p90 in our live test (0.65s against 1.96s).
It’s easier for a router to score well on benchmarks than to perform well in practice. Auto Router sees over 2.5T tokens from over 100k people every month, so it has to hold up in the real world.
This launch includes a brand new router specialized for coding work, Auto Code (openrouter/auto-code), alongside our flagship general purpose Auto Router (openrouter/auto).
Try it now by setting model to openrouter/auto or openrouter/auto-code in any request, or open Auto Router in the chatroom. Check out the Auto Router docs for all the details.
What’s new in this generation
The previous Auto Router relied on a couple of imprecise signals, such as task type, to drive model selection, a limit required to keep latency low and judgments consistent. The new Auto Router and Auto Code choose models by weighing eleven factors about each request and combining them with live pricing, provider health, and cache status.
This new process lets Auto Router work with any set of models. You can apply any governance policies, including guardrails, zero data retention requirements, provider restrictions, allowed model lists, and BYOK keys. Auto Router makes efficient choices from the models available to you.
We introduced the new Auto Code router based on feedback about what it was like to use a general purpose router in a coding harness. This router is tuned from the ground up for coding performance by including a higher tier of coding models and optimizing for latency. Across the five benchmarks below, Auto Code scores in line with Claude Opus 5.5 while costing 74% less per task.
In the previous generation, we also observed that the remarkable efficiency of the lowest cost models had caused Auto router to drift lower on cost per task, leaving out many exceptional models. We made a decision with this release to return to pricing closer to where Auto was a few months ago in order to introduce a greater variety of models. If you preferred the previous behavior, you can set the cost_tier to low to get similar cost performance.
See the reasoning behind routing decisions in the chatroom
The easiest way to start learning how these new routers work is to pick Auto Router or Auto Code in the chatroom. A routing insights panel appears beside each reply showing why the router picked that model. The same analysis is available via the API when you enable router metadata.
Watch the live routing mix on each model page
The Auto Router and Auto Code model pages now show which models each router picks most often, split by session type, and how the mix shifts as difficulty rises.
Compare performance against other routers and single models
Auto Router and Auto Code benchmark results are published on the model routing benchmarks page alongside the other routers on OpenRouter and single-model baselines. We rerun them periodically, so you can track how each router keeps up as new models are released.
Built upon years of lessons from running Auto Router
Auto Router is coming up on its third birthday. If you set openrouter/auto in an agent years ago, you’re still getting the latest cost-optimal choice today. We’ve learned a lot about where automatic model selection goes wrong, and built the new generation to avoid those problems. Some examples:
We separated out Auto Code to optimize for harnesses. The most common complaint about previous versions of Auto Router was how it performed in coding harnesses. Auto Code favors a slightly more expensive tier of models whose strengths match coding work. It weighs speed more heavily because responsiveness matters while you build. It also penalizes failures more harshly, so it course corrects faster on work where success and failure are clear cut.
It’s restrained about switching to protect caching benefits. Switching models costs extra while the new model rebuilds the input token cache. Auto Router favors a change in reasoning effort when that’s enough, and switches only when the gain is worth the cache it gives up. In our beta period it stayed on the same model for nearly nine of every ten agent turns.
It adapts to failures. When a session is going wrong in ways that point at the model, such as the same error coming back or tests failing after an edit, those signals raise the odds of a switch. That makes it much less likely a session stays stuck with a model that was the wrong pick early on.
It’s tuned based on both real usage as well as benchmarks. Auto Router gets better with every benchmark run and every real routing decision it sees. Through typesafe/jev-router and openrouter/auto-beta we have already verified it on production workloads, while respecting zero data retention throughout. In our beta, against the previous router, invalid tool calls were 4× lower and agentic responses were cut off half as often.
Model Routing built upon the leading Provider Routing foundation
Model routers like Auto Router and Auto Code pick which model will process the request. Provider routing picks who will serve that model. OpenRouter has done this for every request since the beginning: once the model is picked, the provider router chooses among the providers hosting it using your provider preferences, live uptime and latency, price, and whether a provider already holds your prompt cache.
A model router can only be as good as the underlying provider router. We built Auto Router to be aware of our entire catalog, so it adapts to governance restrictions, benchmark results, and market signal from new model releases as they happen. Every one of the 600+ models on OpenRouter enters the consideration set the day it’s added, and benchmarks and popularity signals decide whether it earns a place in the cost-optimal set.
How a request moves through Auto Router
- Auto Router narrows the model pool. Guardrails, zero data retention, model capabilities, provider restrictions, BYOK keys, and any allowed or excluded model lists decide which models are considered.
Auto Router narrows the model pool. Guardrails, zero data retention, model capabilities, provider restrictions, BYOK keys, and any allowed or excluded model lists decide which models are considered.
- A fast decision model processes the request. In one call it rates eleven things, such as what kind of task this is, whether the task just changed, how hard it is, whether speed matters, whether it needs vision or knowledge of a codebase, and whether a bigger model, more thinking, or a cheaper model would serve it better.
A fast decision model processes the request. In one call it rates eleven things, such as what kind of task this is, whether the task just changed, how hard it is, whether speed matters, whether it needs vision or knowledge of a codebase, and whether a bigger model, more thinking, or a cheaper model would serve it better.
- The routing policy chooses the model. It weighs live prices, cache status, and benchmark performance to pick both the model and the reasoning effort.
The routing policy chooses the model. It weighs live prices, cache status, and benchmark performance to pick both the model and the reasoning effort.
- The request goes through the same provider routing a direct request to that model would, so it lands on the best provider for that model.
The request goes through the same provider routing a direct request to that model would, so it lands on the best provider for that model.
- The results of each turn inform the next turn’s model selection. The router carries signals like whether the model is struggling and what’s already cached into the next decision.
The results of each turn inform the next turn’s model selection. The router carries signals like whether the model is struggling and what’s already cached into the next decision.
Routers versus single models
Benchmarks consistently show that no router on the market beats the single best frontier model at every point on the cost and quality curve. The new Auto Router is no exception, and we publish its benchmarks to show its strengths and weaknesses plainly.
Routers earn their place when the work is varied, when an organization needs to hold costs steady, and for people who don’t have the time or interest to keep up with the constant stream of model releases. Choosing Auto Router or Auto Code over a single model trades a little peak performance for consistent, cost efficient performance over time.
If you know the model that works best for your specific work, keep using it. If you’d rather choose once and stay focused on the work itself, a router is the way to do that.
Get started
Auto Router and Auto Code work wherever you’d put a model string:
Read the Auto Router docs for the full settings, or open Auto Router in the chatroom and send it the prompt you’d normally hand-pick a model for. Tell us what it gets right and wrong in #feedback on Discord.
Frequently asked questions
What do I need to change to switch from the old Auto Router?
Nothing at all. The slug is still openrouter/auto and the auto-router plugin settings cost_tier, allowed_models, and excluded_models still work.
What is the difference between Auto Router and Auto Code?
Both run on the same routing engine. Auto Router is the general purpose router for mixed traffic and general agents, and favors a cost-efficient tier of models. Auto Code is specialized for coding agents and harnesses, starts in a higher cost tier, and weighs measured pass rate, speed, and cost per solved task across models and reasoning efforts.
Is model routing the same as provider routing?
No. Model routing picks which model handles a request; provider routing picks which provider serves that model. Auto Router and Auto Code do the first, then OpenRouter’s provider routing does the second with your provider preferences, uptime data, and prompt cache state.
Do the routers respect my guardrails and data policies?
Yes. Guardrail policies, zero data retention requirements, provider restrictions, allowed and excluded model lists, and BYOK keys define the model pool, and the router picks the cost optimal model inside it.
No. You pay the standard price of whichever model serves the request, and the response’s model field tells you which one it was.
What is openrouter/auto-beta?
Auto Router Beta is the release channel for the next version of Auto Router. New routing changes ship to openrouter/auto-beta first and graduate to openrouter/auto once they prove out, so use it to see what is coming in advance. If you try it, tell us what it gets right and wrong in on Discord.
