OpenRouter Auto Code: A Model Router for Coding Agents, With No Router Fee

OpenRouter launched a rebuilt Auto Router and a new coding-specific router, Auto Code, on November 6, 2026. Auto Code has its own model slug, openrouter/auto-code. Put it wherever a harness takes a model string, and OpenRouter picks the model and the reasoning effort for each turn.

There’s no router fee. You pay the standard price of whichever model serves the request, and the response’s model field tells you which model that was. OpenRouter says Auto Code scores in line with Claude Opus 5.5 across five benchmarks while costing 74% less per task. That’s OpenRouter’s own claim, and its benchmark results are published on its model routing benchmarks page.

The general router, openrouter/auto, also changed. Its default now sits in a higher price tier than before, so existing users who liked the old, cheaper behavior need one setting change.

openrouter/auto-code vs openrouter/auto#

Both routers run on the same routing engine. The difference is the policy:

There’s a third member, openrouter/auto-beta. New routing changes ship there first and graduate to openrouter/auto once they prove out.

How Auto Code picks a model for each turn#

OpenRouter’s docs describe the same five steps for every request:

1. Narrow the model pool. Guardrails, zero data retention, model capabilities, provider restrictions, BYOK keys and your allowed and excluded model lists decide which models are considered.
2. Rate the request. A fast decision model rates eleven aspects of the request in one call. These include the kind of task, 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.
3. Pick a model and effort. The routing policy weighs that rating against live prices, cache status and benchmark performance to choose both the model and the reasoning effort.
4. Route to a provider. The request goes through the same provider routing a direct request to that model would, so provider preferences, uptime, latency, price and prompt cache state still apply.
5. Carry signals forward. The next turn’s decision uses what already happened, such as whether the model is struggling and what’s already cached.

Step 5 matters most in an agent loop. Switching models costs extra while the new model rebuilds the input token cache, so the router prefers changing reasoning effort when that’s enough. OpenRouter says that in beta it stayed on the same model for nearly nine of every ten agent turns. When a session goes 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.

OpenRouter also reports these beta results against the previous router: invalid tool calls were 4x lower, and agentic responses were cut off half as often. The routing step itself is 3x faster at p90 in its live test, 0.65s against 1.96s.

Using openrouter/auto-code in a request#

Auto Code works wherever you’d put a model string. OpenRouter’s example on the Chat Completions endpoint:

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"}]
  }'

Send a session_id in the body (or the x-session-id header) so the router treats every turn of an agent session as one conversation. Without one, OpenRouter falls back to a fingerprint of your messages.

To see why the router chose a model, add the X-OpenRouter-Metadata: enabled header. The jev-router stage in openrouter_metadata.pipeline lists the resolved models, the routed candidates with their reasoning effort and estimated cost, and the reason for the pick. Cache hits never include openrouter_metadata.

Codex CLI#

OpenRouter’s Codex CLI guide configures ~/.codex/config.toml with an openrouter provider. That guide uses a fixed model slug and doesn’t cover Auto Code specifically, but Auto Code is meant to go wherever a model string goes, so the change is the model line:

model_provider = "openrouter"
model = "openrouter/auto-code"

[model_providers.openrouter]
name = "openrouter"
base_url = "https://openrouter.ai/api/v1"

[model_providers.openrouter.auth]
command = "sh"
args = ["-c", "echo $OPENROUTER_API_KEY"]

On Windows, OpenRouter’s guide uses command = "powershell" with args = ["-NoProfile", "-Command", "Write-Output $env:OPENROUTER_API_KEY"]. Check the model field on the first few turns (or your OpenRouter activity page) to confirm which models actually served them. Our Codex CLI custom provider guide covers the rest of the provider setup.

Claude Code#

Claude Code connects to OpenRouter through ANTHROPIC_BASE_URL="https://openrouter.ai/api", your OpenRouter key in ANTHROPIC_AUTH_TOKEN, and ANTHROPIC_API_KEY set to an empty string. OpenRouter’s own Claude Code guide carries a warning, though: Claude Code with OpenRouter is only guaranteed to work with the Anthropic first-party provider, and Claude Code may not work correctly with other providers. Auto Code can route to non-Anthropic models, so test it on a throwaway branch before you rely on it.

If you see model-not-found errors for OpenRouter-only models such as openrouter/auto, OpenRouter’s troubleshooting points to a credential conflict. Run /logout to clear a cached Anthropic login, or make sure a real ANTHROPIC_API_KEY isn’t still set in your shell profile. For the general trade-offs of putting OpenRouter in front of Claude Code, see OpenRouter vs direct API for Claude Code.

Limiting which models Auto Code can pick#

Auto Code applies allowed_models and excluded_models from the auto-router plugin as hard restrictions. Patterns accept wildcards such as anthropic/*, and exclusions apply after the allow list:

{
  "model": "openrouter/auto-code",
  "messages": [{"role": "user", "content": "Refactor this module into smaller functions."}],
  "plugins": [
    {
      "id": "auto-router",
      "allowed_models": ["anthropic/*", "openai/*"],
      "excluded_models": ["~anthropic/claude-opus-latest"]
    }
  ]
}

If your restrictions leave no eligible model, the request fails with 404, and the error names the fields to change. Matching is case-sensitive.

Auto Code ignores the auto-router plugin’s cost_tier and runs on its own coding tier. To route a request on a general tier instead, set cost_tier (low, medium or high) on a jev-router plugin entry. To cap spend per request, provider.max_price still applies to whichever models the router resolves.

You can also save allowed and excluded models on your workspace’s Routing page in OpenRouter settings. Saved lists apply to openrouter/auto, openrouter/auto-beta and openrouter/auto-code. A request that sets the same field overrides the saved value unless you turn on the “prevent overrides” toggle.

If you already use openrouter/auto#

You don’t need to change anything to keep working. The slug is still openrouter/auto, and cost_tier, allowed_models and excluded_models still work.

Cost is the part to check. OpenRouter says the previous router had drifted toward the lowest-cost models, and this release returns to pricing closer to where Auto was a few months ago. If you preferred the cheaper behavior, set cost_tier to low:

{
  "model": "openrouter/auto",
  "messages": [{"role": "user", "content": "Summarize this paragraph"}],
  "plugins": [{"id": "auto-router", "cost_tier": "low"}]
}

cost_quality_tradeoff and pin_model belonged to the previous generation. Requests that send them still succeed, but the current router doesn’t use them.

Who should try Auto Code#

Auto Code fits when your coding work is varied, when you want steady costs, or when you don’t want to track every model release. OpenRouter frames it as trading a little peak performance for consistent, cost-efficient performance over time. Since there’s no router fee and the model field shows what served each turn, you can run it on real tasks and compare the bill against your current fixed model.

If one model already does your work well, OpenRouter’s own advice is to keep using it. For a price-by-price view of the models a router might pick from, see our cheapest AI coding API comparison.