Summary: On November 6, 2026, OpenRouter launched a ground-up rebuild of its Auto Router, saying it outperforms the previous router by up to 4× depending on the benchmark, with a routing decision 3× faster at the p90 (0.65s vs 1.96s). The same release adds Auto Code, a router tuned for coding harnesses that OpenRouter says scores in line with Claude Opus 5.5 across five benchmarks while costing 74% less per task. If you build on a model string, this changes what “pick once and stop thinking about models” buys you.
What actually changed under the hood
The old Auto Router leaned on a couple of coarse signals, like task type, because keeping latency low meant keeping judgments simple. The new engine scores each request against eleven factors in a single fast call: what kind of task it is, whether the task just changed, how hard it is, whether speed matters, whether it needs vision or codebase awareness, and whether a bigger model, more reasoning, or a cheaper model would serve it better. That score is then combined with live pricing, provider health, and cache status before a routing policy picks both the model and the reasoning effort.
The pipeline matters as much as the scoring. Governance first: guardrails, zero data retention requirements, provider restrictions, BYOK keys, and any allowed or excluded model lists narrow the pool before anything else happens. Then, once a model is picked, the request flows through the same provider routing a direct call would use — uptime, latency, price, and who already holds your prompt cache decide which provider serves it. OpenRouter notes every one of its 600+ models enters the consideration set the day it’s added, with benchmark results and popularity signals deciding whether it makes the cost-optimal set.
One honesty check worth appreciating: OpenRouter itself states that no router on the market beats the single best frontier model at every point on the cost and quality curve, and it publishes its benchmarks on the model routing leaderboard alongside single-model baselines so you can see where the router falls short. I wrote before about why that kind of public tracking matters when you’re picking a layer you can’t easily inspect.
Why Auto Code exists at all
The most common complaint about the old Auto Router, per OpenRouter, was how it behaved inside coding harnesses. Auto Code (openrouter/auto-code) is the answer: it draws from a more expensive tier of coding models, weighs latency more heavily because responsiveness matters while you build, and penalizes failures more harshly so it course-corrects faster on work where success is clear-cut — tests pass or they don’t.
The claimed economics are the headline: across five benchmarks, Auto Code scores in line with Claude Opus 5.5 at 74% less cost per task. Both routers run on the same engine; Auto Router stays general purpose and cost-efficient, Auto Code starts in a higher cost tier and optimizes across measured pass rate, speed, and cost per solved task.
The switching problem, finally addressed
The quiet insight in this release is about cache economics. Switching models mid-session costs extra because the new model has to rebuild the input token cache. The new router treats that as a real cost: it prefers adjusting reasoning effort when that’s enough, and switches models only when the expected gain beats the cache it gives up. During the beta, OpenRouter reports it stayed on the same model for nearly nine of every ten agent turns.
It also adapts when a session goes wrong. Repeated identical errors or tests failing after an edit raise the odds of a switch, so a session is less likely to stay stuck with a model that was the wrong pick at turn one. In beta against the previous router, invalid tool calls were 4× lower and cut-off agentic responses dropped by half. Those signals then feed the next turn’s decision.
Scale behind the tuning: the router sees over 2.5T tokens from over 100k people every month, which is the sample OpenRouter says keeps it honest beyond benchmark wins. It also verified the new generation on production workloads through typesafe/jev-router and openrouter/auto-beta, with zero data retention respected throughout.
What these claims don’t establish
Some caveats before you move production traffic. The 4× and 74% numbers come from OpenRouter’s own benchmark runs, which it reruns periodically — there’s no independent verification here, and the five specific benchmarks behind the Auto Code claim aren’t named in the announcement. The beta-period reliability figures cover a limited window against the previous router, not long-term behavior at scale.
There’s also a deliberate pricing shift. The low-cost efficiency of the cheapest models had pulled the old router’s cost per task down, but crowded out strong mid-tier models. This release moves pricing back toward where Auto sat a few months ago specifically to widen model variety. If you were relying on that drift toward cheap, set cost_tier to low to get similar cost performance.
What to do next
Migration is genuinely nothing: the slug is still openrouter/auto, and the cost_tier, allowed_models, and excluded_models settings still work. Routing itself is free — you pay the standard price of whichever model serves the request, and the response’s model field tells you which one it was.
The useful test isn’t a benchmark, it’s your own workload. Open Auto Router in the chatroom, where a routing insights panel shows why each model was picked (the same analysis is available via API by enabling router metadata), and send it the prompt you’d normally hand-pick a model for. Run your usual agent loop against openrouter/auto-code, compare cost per completed task against your pinned model, and check whether the ~90% same-model stickiness holds on your sessions. If you want to see routing changes before they land, point a non-critical workload at openrouter/auto-beta.
curl https://openrouter.ai/api/v1/chat/completions \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "openrouter/auto-code",
"messages": [{"role": "user", "content": "Add a retry with backoff to fetchUser in api/users.ts"}]
}'The honest frame from OpenRouter is the right one: if you already know the best model for your work, keep it. The router earns its place when your traffic is varied, your costs need to stay steady, or you’d rather spend your attention on the product than on the model release cycle.
Sources
View the original post on X