OpenRouter adds Auto Code, with new cost and routing controls
OpenRouter has announced a rebuilt Auto Router and a separate Auto Code router for coding agents. The November 6 announcement keeps the existing openrouter/auto identifier, while adding openrouter/auto-code for development work.
The practical change is how the service chooses a model and its reasoning effort across a task. Existing Auto users should also check their spending: the new default deliberately permits a more expensive mix of models than the previous generation.
Auto and Auto Code serve different workloads
General Auto is intended for mixed requests and general agents. Auto Code uses the same engine with a coding policy that puts more weight on speed, successful completion and recurring failures. OpenRouter says its decision process combines eleven request signals with prices, provider health and prompt cache information.
The company reports that Auto Code performed around Claude Opus 5.5 across its five selected benchmarks at 74 percent lower cost per task. That is a platform reported comparison, not a saving ByteForward has independently reproduced or a guarantee for a particular repository.
A coding team should therefore compare completed changes rather than isolated answers. A cheap patch that fails tests twice may cost more overall than a stronger model that finishes on the first attempt.
The cost setting has an important exception
The Auto Router documentation describes three general cost policies: low, medium and high. Low aims for lower estimated cost, while high allows more capability when the expected benefit justifies the expense. OpenRouter recommends low for users seeking costs closer to the previous Auto behavior. This selects a routing policy, not a fixed token price or the model’s reasoning effort.
Auto Code has a different rule. Its coding router guide says it ignores cost_tier when that setting appears under the auto-router plugin. To apply a general low, medium or high tier, the request must put cost_tier in a jev-router entry. Otherwise Auto Code uses its own coding tier.
Both services charge the price of the model that actually answers, without an additional router fee. Treat a migration as a change in spending behavior even when the application keeps the same model identifier. Record the resolved model and actual usage instead of assuming yesterday’s average still applies.
Check model restrictions and regional availability
Auto Code honors allowed and excluded model lists under auto-router. The guide says those lists are hard restrictions and that a request returns a 404 error if no eligible model remains. A restrictive test case should fail visibly rather than silently broaden the approved model pool.
The current Auto Code listing also says it is unavailable through EU in-region routing. It dates the release to November 5, one day before the blog announcement. Teams with regional requirements should check that limitation before changing production traffic.
Do not treat the listing’s maximum context window as a uniform allowance. OpenRouter says a request gets the context capacity of the model serving it, with routes supporting up to two million tokens. The selected model remains relevant even when an application asks for an automatic choice.
Keep the session together and inspect decisions
The coding guide recommends sending session_id or the x-session-id header so turns are treated as one conversation. Auto Code prefers adjusting reasoning effort before switching models when that preserves useful cached context. Repeated errors or failing tests can prompt a change.
For visibility, the router metadata documentation describes an explicit opt-in: set X-OpenRouter-Metadata to enabled. Successful responses then include routing details, except for cache hits, which omit metadata. Streaming clients receive them at the end, so a logger that records only early chunks can miss the explanation.
Check the response’s selected model, then use the metadata to understand routing and fallback behavior. Keep these records with task outcomes so a later comparison can distinguish better routing from a different workload or a changed model pool.
A sensible migration test
Choose a small set of representative repository tasks, including one with a failing test and one with a longer conversation. Run the existing setup, general Auto and Auto Code against the same acceptance criteria. Compare total cost, time to a passing result and the changes a reviewer must repair.
ByteForward’s guide to OpenRouter’s routing benchmarks explains why quality, waiting time and task cost belong in the same comparison. For this release, also test the exact cost setting and permitted model list that production will use.
Keep the working baseline available while evaluating the new route. The useful result is a reliable improvement on your own tasks, with costs and access rules you can explain.
