OpenRouter Auto Code solved our five coding tasks and cost between 56 and 78 percent less than pinning Claude Opus 5.5. But against GPT-6.1 Sol, the model it chose most often, it was cheaper in one run and 78 percent more expensive in the other. The difference lies in a detail that the documentation doesn’t mention: when Auto Code sends a request to GPT-6.1 Sol, it uses OpenAI’s priority service tier.
yoDEV Tested · November 9, 2026
We testedopenrouter/auto-codeagainst GPT-6.1 Sol and Claude Opus 5.5 pinned, on five Python tasks (46 pytest tests), using OpenRouter’s Chat Completions API from a cloud-based Linux environment. The results we report as ours come from that test.
What is OpenRouter and what is Auto Code?
OpenRouter is an API gateway: a single key and a single endpoint compatible with OpenAI (https://openrouter.ai/api/v1/chat/completions) in front of hundreds of models from different providers. Instead of integrating each provider separately, you change the model with text: anthropic/claude-opus-5.5, openai/gpt-6.1-sol, and so on.
Auto Code is a model router designed for code agents. You send openrouter/auto-code as the model and OpenRouter decides which model, and with what reasoning effort, responds to each request. OpenRouter announced it on November 6, 2026, along with a rebuilt version of its general router, Auto Router.
According to the model’s spec sheet, Auto Code treats each request as part of an agent session and weighs three things: the rate of code tasks that pass, the time to complete them, and the cost per solved task. It tries to stay with the same model while work is going well; when something fails, it prefers to increase reasoning effort rather than change models (so it keeps the prompt cache), and only switches when error signals point to the model.
What are the differences between Auto Code and OpenRouter’s Auto Router?
Auto Router (openrouter/auto) is the general router for mixed traffic and prioritizes cost efficiency. Auto Code (openrouter/auto-code) uses the same routing engine, but starts at a higher tier of code models. Neither charges its own fee: you pay the standard price of the model that handles each request.
Configuration also changes, and it’s easy to get wrong:
| Auto Router | Auto Code | |
|---|---|---|
| Model ID | openrouter/auto |
openrouter/auto-code |
| Starting tier | Cost efficient | Higher code tier |
| Restrict models | auto-router plugin: allowed_models, excluded_models |
Same, in auto-router |
| Cost tier | cost_tier in auto-router (low … max) |
cost_tier in jev-router (low, medium, high) |
Auto Code ignores the cost_tier you send in the auto-router plugin. If you copy the setting from the announcement or Auto Router’s guide, nothing breaks: it just doesn’t apply.
OpenRouter’s benchmarks claim that Auto Code scores “in line with Claude Opus 5.5” at 74 percent less cost per task. These are figures from the provider itself, published on its routing benchmarks page, and the announcement doesn’t detail the methodology. That’s why we ran our own test.
How did we test it?
We wrote a small Python package with five tasks and 46 pytest tests, all failing at the start:
- Add retries with exponential backoff to
fetch_user(the same example from OpenRouter’s announcement) - Fix three bugs and add validation in a
paginatehelper - Implement
parse_duration("1h30m")with strict validation - Implement an LRU cache with TTL
- Implement
slugifyfor Spanish names (accents, ñ and trimming without cutting words)
Before calling any model, we verified the tests against our own reference solutions: all 46 pass. Each task had up to two turns in the same session; if tests kept failing, the pytest output went back to the model. We ran everything on November 9, 2026 via the Chat Completions endpoint, and took the billed cost from OpenRouter’s own generation logs.
A caveat from the start: each task is a single file the model rewrites completely, not an agent loop with tools. It measures routine code work, not long autonomous sessions.
Does OpenRouter Auto Code save money compared to choosing the model by hand?
Versus Opus 5.5, yes. Versus your own favorite model, it depends on the run.
| Configuration | Models that responded | Solved | Total cost | Per solved task | Median time |
|---|---|---|---|---|---|
| Auto Code, run 1 | GPT-6.1 Sol ×3, GLM-5.3 ×2 | 5/5 | $0.0420 | $0.0084 | 7.7 s |
| Auto Code, run 2 | GLM-5.3 ×4, GPT-6.1 Sol ×1 | 5/5 | $0.0209 | $0.0042 | 4.9 s |
Auto Code + cost_tier: low |
DeepSeek V4.1 Flash ×5 | 5/5 | $0.0092 | $0.0018 | 15.6 s |
| GPT-6.1 Sol pinned | GPT-6.1 Sol | 5/5 | $0.0236 | $0.0047 | 6.1 s |
| Claude Opus 5.5 pinned | Claude Opus 5.5 | 5/5 | $0.0949 | $0.0190 | 8.2 s |
All configurations solved all tasks, so with work of this size models don’t differ in quality, only in cost and speed. The only first-turn failure was the low tier on the slug task (8 of 11 tests); it fixed it on the second turn after seeing test output.
Versus pinned Opus 5.5, Auto Code cost 56 percent less on run 1 and 78 percent less on run 2. OpenRouter’s figure of 74 percent falls within that range. Versus pinned GPT-6.1 Sol, run 2 was 11 percent cheaper, and run 1 was 78 percent more expensive.
Why did Auto Code cost more than calling the same model directly?
Because it paid for a faster lane. OpenRouter’s generation logs show that all Auto Code calls that went to GPT-6.1 Sol ran with service_tier: "priority", while our calls to pinned GPT-6.1 Sol ran on "default". Same model, same prompt: the retry task cost $0.0135 with Auto Code versus $0.0047 pinned, and the duration task $0.0129 versus $0.0062. Part of the difference also comes from reasoning more: 261 reasoning tokens versus 81 on the retry task.
At the time of publishing this note, the Auto Code guide doesn’t mention the priority tier. It makes sense for an agent where latency matters, but it means the router’s GPT-6.1 Sol doesn’t cost the same as yours.
What AI for programming does Auto Code choose, and is it always the same?
It’s not always the same. The same prompt went to different models depending on the run: the retry and slug tasks went to GPT-6.1 Sol on run 1 and GLM-5.3 on run 2. Only the duration task went to GPT-6.1 Sol both times. The router chooses from a candidate set: in our runs, the snapshot of the pool had 13 models, and among the candidates were GPT-6.1 Sol, GLM-5.3, Gemini 4 Argon, Kimi K3.1 Pro, and Claude Opus 5.5.
Routing also explains latency spikes. One cache task with GLM-5.3 took 118.7 seconds because the model spent 3,225 of its 4,148 output tokens reasoning; the same task with the same model took 3.9 seconds on run 2. Pinned models were most predictable: Opus 5.5 stayed between 5.4 and 8.7 seconds per task.
Is OpenRouter Auto Code free?
The router is, the work isn’t. The model’s spec sheet says Auto Code is free, but that means the router doesn’t add any fee: according to the announcement and guide, you pay the standard price of the model that handles each request. In our test, that was between $0.0018 and $0.0084 per solved task, depending on configuration.
How to use OpenRouter Auto Code with your API key?
Put openrouter/auto-code as the model anywhere your tool accepts a model name, and use your OpenRouter API key as always. This is the basic request from the official guide:
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": "..."}]}'
If you use it with an agent, send a session_id field (or an x-session-id header) so the router treats all turns as a single conversation instead of guessing.
To lower the cost tier, use the jev-router plugin, not auto-router:
{
"model": "openrouter/auto-code",
"messages": [{"role": "user", "content": "..."}],
"plugins": [{"id": "jev-router", "cost_tier": "medium"}]
}
To limit which models it can use, allowed_models and excluded_models go in auto-router:
{
"model": "openrouter/auto-code",
"messages": [{"role": "user", "content": "..."}],
"plugins": [{"id": "auto-router", "allowed_models": ["anthropic/*", "openai/*"], "excluded_models": ["~anthropic/claude-opus-latest"]}]
}
If your restrictions leave no models available, the request fails with a 404 indicating which fields to change. The guide doesn’t cover configuration for specific tools like Claude Code or Codex, so we don’t include it here either.
How to know which model responded in OpenRouter?
Read the model field of the response. To see the full decision, send the X-OpenRouter-Metadata: enabled header and check the jev-router stage in openrouter_metadata.pipeline. On our runs it showed the task classification (code:general_impl, with 0.99 confidence), the scope of work (localized_change), the candidates with their estimated cost, and the probability assigned to each model and effort level. It’s the most useful part of the whole function: you can see why the router did what it did.
Does Auto Code work with EU regional routing?
At the time of publishing this note, no: the model’s spec sheet indicates Auto Code is not available with EU regional routing (EU in-region routing). If your team needs requests to stay within the EU, check the spec sheet before switching.
Router or pinned model: which is the best AI for programming in your case?
Pin the model when you already know which works for your tasks and you care more about predictable cost than convenience: in our test, pinned GPT-6.1 Sol came out cheaper than one Auto Code run, almost the same as the other, and without latency surprises. Use Auto Code when you’d otherwise use a frontier model like Opus 5.5 for everything, or when your traffic mixes trivial and hard tasks. And if cost is what matters most, cost_tier: low on jev-router was the cheapest configuration we tested: 90 percent less than Opus 5.5, with an extra turn on five tasks. If you also want to trim the tokens you send, check how to use Headroom with LiteLLM to spend fewer tokens.
Our figures come from a single day, five small tasks, and one or two runs per configuration. The model pool and prices change daily, so take them as a snapshot of the moment, not as a ranking.
What about you? What model does your code agent use by default today?
- Always the same frontier model
- I change it by hand depending on the task
- I let a router decide (OpenRouter, LiteLLM…)
- I prefer another option (tell us which)
Comment below or, if this article reached you by email, reply directly to the email: your response gets published here.
Related: How to connect all your coding agents with OmniRoute