OpenRouter Auto Router vs Auto Code: Which to Use

A coding agent and a general chatbot should not share the same router setting. Use openrouter/auto for mixed traffic and openrouter/auto-code for multi-turn coding sessions — with one catch: Auto Code's solved-task cost is usually higher than Auto's, while the 74% saving is measured against Opus 5.5.

Both routers launched November 5, 2026 and were announced November 6, 2026 by OpenRouter. They share one routing engine; the difference is the starting model tier and how failure signals steer the session. There is no routing fee — every request bills at the selected model's normal rate (OpenRouter announcement).

Use Auto for mixed traffic, Auto Code for coding sessions

Auto Code is the coding-agent router that starts in a higher cost tier and weighs pass rate, speed, and cost per solved task (OpenRouter announcement).

If you already know which model is best for your workload, OpenRouter itself says to keep it. Routers trade a little peak performance for consistent cost-efficient picks without tracking every release (OpenRouter announcement).

Can you trust the 74% cheaper claim?

Direction yes, number with asterisks. The "74% less" figure compares Auto Code against Claude Opus 5.5 on five OpenRouter-run benchmarks — not against Auto, and not independently verified. I found no independent reproduction as of November 6, 2026, one day after launch (OpenRouter announcement).

Here is the full benchmark table from the announcement, because the headline hides the second half:

Three things fall out of that table (OpenRouter announcement):

1. Auto Code beats Auto on 4 of 5 scores, but loses Tau-bench Banking 52.6% to 53.1%. The gaps run 2 to about 5 points, not a generation leap.
2. Auto Code costs more than Auto on 4 of 5 tasks — up to 3.7x on TerminalBench ($4.96 vs $1.33). It also costs more than the previous Auto Router on every benchmark (e.g., 8.1x on TerminalBench).
3. "Cheaper" only works against Opus 5.5 per solved task. Cost per task bakes in retries: a cheaper per-token model that fails twice can cost more per solved task than a pricier model that passes first try. That is the right metric for agents, but it is not your per-token bill dropping 74%.

Community skepticism centers on verifiability, not the direction:

"Says it clearly: the 74% number is from OpenRouter's own 5 benchmarks, not independent verification. Trust the direction, not the digits." — @LJL06019

Another user asked the question that decides whether you reproduce it: "the 74% only holds if my prompt tells the router what is hard. What tells the router what is hard?" (@harden_369741).

Treat the claim as: Auto Code is roughly Opus-5.5-class on these five coding-heavy benches at a lower solved-task cost, while Auto is the cheaper router when raw score is not the constraint. Re-run it on your own repo set before budgeting.

What actually differs under the hood

Same engine, different policy. Both routers evaluate 11 request factors per call — task type, difficulty, whether speed matters, whether vision or codebase knowledge is needed, whether a bigger model or more reasoning would help — then combine that with live pricing, provider health, prompt-cache status, benchmark data, and session history (OpenRouter announcement).

Auto Code adds three coding-specific weights on top (OpenRouter announcement and Auto Code page):

• Starts from a stronger (pricier) coding model tier instead of Auto's cost-efficient medium tier.
• Weighs latency harder and penalizes failed code changes more heavily.
• Switches away faster when edits fail tests or the same error recurs.

The escalation order matters: when a session stalls, Auto Code first raises reasoning effort, and only then switches models. OpenRouter says this plus session stickiness kept the router on the same model for nearly 9 out of 10 agent turns during beta, with invalid tool calls 4x lower and cut-off agentic responses halved versus the old router (OpenRouter announcement). Routing latency at p90 fell from 1.96s to 0.65s, roughly 3x (OpenRouter announcement).

Auto's general path is older and documented separately: a lightweight classifier assigns about 30 fine-grained task types (e.g., code:debugging, agent:multi_step_planning), ranks models by trailing-7-day community spend share per task, applies your cost tier and restrictions, then picks a primary plus fallbacks (Auto Router docs). The new generation keeps that market signal but adds the session layer.

Live routing mixes show what "stronger tier" means in practice. A November 6 snapshot of Auto Code's last-24-hour traffic (992 requests) had GPT-6.1 Sol at 70.4%, Claude Opus 5.5 at 14.8%, and GLM 5.3 at 11.0% (Auto Code page). Auto's general mix leans cheaper — DeepSeek V4 Flash variants alone were about 47% of displayed volume on its overview page (Auto overview). Mixes rotate within days as prices and releases move, so read them as weather, not roster.

The switching tax: cache rebuilds and provider stickiness

This is the section generic launch coverage skips, and it decides your real bill. Switching models mid-session throws away the prompt cache: the new model must re-ingest your context at full input price. OpenRouter acknowledges the mechanism — the router keeps multi-turn conversations on one model until it is no longer a leading choice precisely to reduce rebuilds (OpenRouter announcement).

Real users report the failure mode both ways:

"people keep trying to build routers at request level which is not going to work … a prompt without surrounding context is simply not enough signal to judge complexity … we can't frequently change the model during a session in an economic way. one or two missteps … spending more cost than simply using the best model all along" — @kunchenguid

The money quote behind that critique comes from OpenCode's author: fixing OpenRouter caching cut one test bill from $50 to $6 (@thdxr). On Reddit, one user testing openrouter/auto reported "It's cache hit rate when we tested it was basically 0" (u/tankerkiller125real), and another found "every time Auto flipped the id the next call came back with cache_discount 0 while the pinned run kept reading" (u/Michael_Jeffords). The VS Code thread's top advice is blunt: "Keep model and provider fixed for better results as cache would save cost else u would be sending large context to random providers" (u/Zealousideal-Part849).

Two practical consequences:

1. Cache hit rate is the bill, not list price. About 87% of agent tokens now come from cache by one user's estimate (@shu8ham_) — so a router that breaks stickiness can cost more than a pricier pinned model that reuses context. Moving a timestamp from the top of the system prompt to the bottom fixed that user's bust-every-call cache (@shu8ham_).
2. Stickiness can stick you to a bad host. Follow-up requests stay with the same provider while its cache is warm, so one weak quantized endpoint can poison a whole session — "Same model name is not the same model. Pin what serves it" (@webtkdev). If quality wobbles after a switch, log the provider, not just the model.

Auto Code's answer — escalate reasoning before switching, switch fast only on clear failure — is the right shape (Auto Code page). But until you see your own cache_discount stream stay nonzero across a session, assume switching is a budgeted risk, not free.

Cost controls that actually cap the bill

cost_tier is a band, not a ceiling. The five tiers — low, medium, high, xhigh, max — each select a cost band of eligible models; models above and below the band can be excluded, and an unset tier behaves roughly like low on the classic docs path (Auto Router docs). Reddit's summary is the one to remember: "cost_tier is a band, not a ceiling … pin an exact model whenever the bill has to be deterministic" (u/conifer_v11).

A workable setup for either router:

• Start Auto Code at default for a trial repo set; start Auto at low if you liked the old cheap behavior. OpenRouter moved the new default pricing up toward "a few months ago" levels to admit more capable models (OpenRouter announcement).
• Add allowed_models / excluded_models wildcards (e.g., anthropic/*) to bound the pool; exclusions win over allowlists, and an empty pool fails closed with 404 (Auto Router docs). Note the plugin-ID trap: openrouter/auto reads auto-router settings while openrouter/auto-beta reads auto-beta-router — cross-submitted settings are silently ignored (Auto Router docs).
• Layer provider.max_price plus workspace spend limits for a hard cap; the tier alone cannot do it (Auto Router docs).
• Pass an explicit session_id for multi-turn work so stickiness keys on your conversation, not a message fingerprint (Auto Router docs).
• Log model, provider, tokens, price snapshot, and cache_discount per request. That log is the only way to compute cost per accepted task — the metric Auto Code optimizes and the one your budget cares about.

Related reading on this site: the Auto Router setup guide, OpenRouter pricing guide, prompt caching guide, and LiteLLM vs OpenRouter for self-hosted routing alternatives.

Call it in one line and see what actually ran

Both routers work anywhere a model string is accepted (Auto overview):

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

Swap in openrouter/auto for general traffic. The response model field names the model that actually answered — always capture it (Auto Router docs). Send X-OpenRouter-Metadata: enabled to get the task classification (Auto Router docs), or open the chatroom's routing-insights panel to see why a model was picked (task type, difficulty judgment, candidate share) (OpenRouter announcement). Both routers support tool calls, streaming, images, PDFs, audio, and video input with text/image output, up to a 2,000,000-token route ceiling — the actual window is whatever the selected model supports (Auto overview and Auto Code page).

One IDE note: Codex CLI, Cline, Kilo Code, OpenCode, Continue, and Copilot-style VS Code setups may add their own sub-calls, retries, and large contexts on top of your prompt — one user compared about 20 tokens via direct Python against 20k–40k tokens via a plugin request (r/openrouter routing thread). When a small-looking request bills large, check whether the tokens came from the router or the harness before blaming the router. OpenRouter's catalog behind both routers spans 600+ models (OpenRouter announcement).

OpenRouter Auto vs Auto Code FAQ

Is Auto Code more expensive than Auto Router?

Usually yes per task. On OpenRouter's own table Auto Code costs more than Auto on four of five benchmarks (tied on the fifth). Auto Code is only "cheaper" against a fixed frontier model per solved task.

Does the router charge an extra fee?

No. Both openrouter/auto and openrouter/auto-code bill at the selected model's normal rate with zero router surcharge (Auto overview).

Does switching models break prompt caching?

Yes, it can. A new model or provider must rebuild cache, and users have logged cache_discount dropping to 0 right after a flip. Auto Code prefers raising reasoning effort first and stayed sticky about 9/10 turns in beta (OpenRouter announcement), but verify on your sessions.

Which models can they pick, and can I exclude some?

Any model in the catalog after your guardrails, zero-data-retention, provider, allowlist, and excludelist filters apply (Auto Code page). Wildcards like anthropic/* work; exclusions take precedence (Auto Router docs).

When should I pin a fixed model instead of a router?

When the bill must be deterministic, when audit or residency needs a known model, or when your pinned model's quality already beats the router's average on your repos. A good workflow is Auto for discovery, then pin or whitelist the winner.

The trade-off you cannot prompt around: Auto Code buys a few extra pass-rate points with a higher tier and session awareness, but every switch spends cache. If your sessions are long and context-heavy, the cheapest router is the one that stops switching.