On November 6, 2026, OpenRouter announced a new generation of Auto Router and a specialized Auto Code for programming tasks. The company reports a faster selection step in its own live test: 0.65 versus 1.96 seconds at p90. This measures routing latency, rather than promising the same acceleration for an entire response.
Two separate choices within a request
The documentation says `openrouter/auto` selects a model and reasoning effort for general work, while `openrouter/auto-code` uses a policy for coding agents. The eligible pool is constrained by customer rules, including model lists and data requirements. The selected model can change between turns. The system also considers the cost of losing a prompt cache, so a switch is not required for every new message.
A subsequent choice determines which provider serves the selected model. The provider-routing documentation describes controls for permitted and excluded providers, fallbacks, prices and required parameters. It also supports restricting requests to Zero Data Retention endpoints. Choosing which model and choosing where it runs therefore remain distinct decisions with separate rules.
That distinction matters directly to users. A model name alone does not fully describe data handling, and automatic selection does not itself define a privacy policy. Those conditions need to be specified and checked by the application.
Inspecting the selected route
The official Router Metadata documentation describes enabling inspection with the `X-OpenRouter-Metadata: enabled` header. The returned `openrouter_metadata` object can identify the requested model, strategy, provider and serving attempts. Streaming responses are supported too. Cached replays do not include this object, limiting what can be inferred from missing metadata. It is an observability tool rather than evidence that the generated answer is correct.
OpenRouter also maintains a page comparing routers with individual models. Its visible description states that it compares systems for selecting between models. Our check did not return the numerical tables, so we do not use unverified values from them. We did not independently reproduce the company’s tests. A product-specific task set remains necessary, particularly when code relies on unusual libraries or internal conventions.
Editorial interpretation: measure completed work
Consider an assistant alternating between short questions, code changes and prolonged debugging. A fixed model and an automatic router are two configurations that can be compared. A useful evaluation would submit identical tasks and judge their results by the same criteria, rather than comparing only the price of an individual token.
For programming work, the evaluation should include retries, time until a test passes and spending on unsuccessful edits. If a cheaper answer needs more repairs, its final cost may differ from the initial estimate. This is an editorial suggestion for measurement, not the result of our own Auto Code experiment.
Control matters alongside performance. An application should be able to explain which models were eligible and which model actually answered. A small representative evaluation should be repeated after a routing update, because an unchanged application request can lead to a different selection over time.
Teams should also decide how to handle unavailable routes. A request that satisfies a strict data policy but cannot be served is operationally different from one silently sent elsewhere. The documented controls provide a way to express such choices; the application still needs to verify the behavior it depends on. The launch expands automatic selection, while its value for a particular team must be established on that team’s work.
