Key takeaways
- OpenRouter released openrouter/auto and openrouter/auto-code on November 5, 2026. Auto targets general apps, chat and agents; Auto Code treats every request as part of a coding-agent session.
- The documented Auto Router classifies prompts into roughly 30 task types, ranks eligible models using trailing seven-day aggregate spend share, applies a selected cost tier, and returns the model that actually answered in the response.
- OpenRouter says there is no separate routing fee: each response is billed at the selected model’s standard rate. That means the router has no single fixed token price, and cost must be read from the actual model and usage record.
- Both registry entries advertise a two-million-token route ceiling and broad multimodal input, but a router is not one model. Effective modalities, output type, context, latency, policy and quality depend on the model and provider selected for a request.
- Trial the routes against a fixed-model control. Pin allowlists, exclusions, cost tier, provider policy and session IDs; log the returned model; and reject adoption if route changes make quality, compliance or spend harder to explain.
Two callable router IDs arrived on November 5
OpenRouter released two API identifiers on November 5, 2026: openrouter/auto for general-purpose applications and openrouter/auto-code for coding agents and harnesses. The public registry timestamps Auto Code at 13:12:01 UTC and Auto Router at 13:38:09 UTC. Both can be sent in the model field through OpenRouter’s supported completion, Responses and Messages-style interfaces.
These are routing products, not newly trained foundation models. A request is handed to another model chosen by OpenRouter, and the response identifies that downstream model. Buyers therefore need to evaluate the routing policy and the models it can select, rather than treating “Auto” as a stable set of weights or a single capability profile.
Auto Router uses task type, market behavior and cost bands
OpenRouter’s documentation says Auto Router first assigns a prompt to one of roughly 30 task types, including debugging, multi-step agent planning, knowledge questions, math, customer support and research reports. It then ranks models using aggregate, anonymized spend share for that task over a trailing seven-day window, applies the requested cost tier, and constructs a primary choice plus fallbacks after account policies and request restrictions.
This is a live policy rather than a frozen benchmark table. Community spending can reflect real adoption, but it is not independent proof that the chosen model is best for a particular workload. The route can follow market changes within days, which reduces manual model-list maintenance while also making the effective dependency set more dynamic.
Auto Code adds coding-session signals
OpenRouter describes Auto Code as the coding-specific route built on the same engine. It says every request is treated as part of an agent session and model choices are guided by coding-task pass rate, completion time and cost per solved task. Across turns, the route follows edits, test results and recurring errors, keeps a model while work is progressing, and can increase reasoning effort before switching after persistent trouble.
Those are OpenRouter product claims, not AccessAllGPT test results. The public page showed a changing live routing mix during review, but a short-window traffic share does not establish patch correctness, tool reliability or cost effectiveness. AccessAllGPT did not run a repository task through Auto Code or inspect the scoring data behind its choices.
Pricing follows the model that actually answers
OpenRouter says Auto Router adds no routing fee. The customer pays the standard rate of whichever model is selected, and the response model field reveals that identity. The registry uses non-price sentinel values for the router records rather than publishing one input and output rate, which is consistent with variable downstream billing.
A cost tier is a band, not a hard budget ceiling. OpenRouter documents low, medium, high, xhigh and max tiers and says an unspecified request behaves roughly like the low band. Because a band excludes models both above and below it, teams that need a strict cap should also use endpoint price controls, log token usage and selected models, and calculate cost per accepted task rather than relying on the router label.
The two-million-token listing is a route ceiling, not a promise
The public registry advertises two million tokens of context for both routes and lists text, image, audio, file and video input with text or image output at the routing layer. Auto Code also exposes a 65,536-token maximum completion field. These records describe the router’s envelope, not a guarantee that every eligible downstream model accepts every modality or can use the full window with equal quality.
OpenRouter says route selection considers required capabilities and output modality, but effective context, caching, tool semantics, provider location, retention, latency and failure behavior still come from the selected path. The Auto Router page also stated that it was not available through EU in-region routing during review. Regional or zero-data-retention requirements should be enforced as policy, then verified from request records rather than inferred from the top-level slug.
Controls reduce drift, but do not remove it
Auto Router accepts wildcard allowlists and exclusions, such as a provider family or exact model. It also respects account-level model and provider restrictions, guardrails and zero-data-retention settings. Sessions prefer the same model only while it remains among the top candidates for the next prompt, so a conversation can still switch when the task changes.
Use an explicit session_id, record the returned model and provider, and freeze allowed models when repeatability matters. OpenRouter warns that settings for openrouter/auto and the separate auto-beta track use different plugin IDs; settings sent under the wrong one can be accepted but ignored. Configuration tests should deliberately prove that banned models cannot be selected and that an empty eligible set fails closed.
What builders and buyers should do next
Run a shadow trial with a representative prompt and agent-task set. Compare openrouter/auto and, for coding, openrouter/auto-code against a pinned incumbent on acceptance rate, factual errors, patch and test success, tool-call validity, latency, retries, selected model, provider, token use and cost per accepted result. Include task shifts inside sessions to expose unwanted switching.
Trial when workload diversity makes manual routing expensive. Constrain with allowlists, exclusions, cost tiers, provider and data policies, spend limits and rollback thresholds. Wait when auditability, residency or deterministic model identity is mandatory. Reject the router if its gains do not outweigh evaluation churn or if the chosen model cannot be explained after an incident.
Copy-ready dynamic-router trial record
Keep the router policy, downstream model and measured outcome in the same record so “automatic” does not mean untraceable.
Entries stay in this browser tab and are not submitted to AccessAllGPT. Blank responses are copied as [Unresolved].
General or coding task, users, tools, modalities, session length, volume and failure consequence.
openrouter/auto or openrouter/auto-code; cost tier; allowlist; exclusions; provider, ZDR, guardrail and max-price policy.
Explicit session ID, task-shift cases, allowed switching behavior, stickiness expectation and reset condition.
Representative prompts or repository tasks, edge cases, tool failures, long inputs and fixed-model control.
Returned model and provider, task type when enabled, input/output tokens, price snapshot, latency, retries and errors.
Human acceptance, factual defects, tests, tool validity, review time, cost per accepted task and route-switch rate.
Model-mix change alert, price and policy checks, regression schedule, incident trace and rollback trigger.
Trial, constrain, wait or reject; approved workloads, traffic ceiling, owner and next review date.
Primary sources
Browse the publication-wide evidence index →
- Auto Router model pageOpenRouter · Reviewed: Release date; API identifier; product description; live routing display; model mix; request example; supported API surfaces; modalities; context; regional-routing notice; FAQ · Retrieved · Supports: OpenRouter lists openrouter/auto as released November 5, 2026 and available through its chat-completions, Responses and Anthropic-compatible APIs. The page describes general-purpose, session-aware routing and exposes a changing live model mix.
- Auto Code model pageOpenRouter · Reviewed: API identifier; product description; coding-agent routing criteria; live request and model-mix displays; request examples; supported parameters; modalities and context · Retrieved · Supports: OpenRouter exposes openrouter/auto-code as a coding-agent-specific route. It says model choices consider coding-task pass rate, completion time and cost per solved task, while session behavior follows edits, tests and recurring errors.
- Auto Router — Intelligent Model SelectionOpenRouter Documentation · Reviewed: Overview; routing method; usage; response; session stickiness; model allow and exclusion patterns; cost tiers; account defaults; pricing; limitations · Retrieved · Supports: OpenRouter documents task classification, trailing seven-day aggregate spend-share rankings, cost tiers, model restrictions, session stickiness and the returned model field. It says customers pay the selected model’s standard rate with no additional router fee.
- OpenRouter public model registryOpenRouter API · Reviewed: Records for openrouter/auto and openrouter/auto-code: creation timestamps; architecture; modalities; context; supported parameters; API surfaces; pricing sentinels and completion limits · Retrieved · Supports: The public registry recorded Auto Code at 2026-11-05 13:12:01 UTC and Auto Router at 13:38:09 UTC. Both records advertise a two-million-token route ceiling and multimodal input, while actual compatibility depends on the selected downstream model.
Limitations
This is a first-party launch and documentation review, not hands-on router testing, an independent benchmark, a billing audit, a classifier audit, a security assessment, a privacy assessment or a procurement review. AccessAllGPT did not authenticate; call openrouter/auto or openrouter/auto-code; spend credits; inspect prompts, ranking code or aggregate spend data; test session stickiness, fallbacks, cost tiers, allowlists, exclusions, guardrails, ZDR, max-price controls, tools, structured output or multimodal inputs; verify EU routing behavior; reproduce coding pass rates; compare quality, latency or cost with a fixed model; or validate the two-million-token envelope. The downstream model mix, prices, capabilities and providers can change. Live page request counts and model shares were treated as mutable snapshots and are not used as performance evidence.
Disclosures
AccessAllGPT received no API credits, private access, briefing, routing data, benchmark data, review, payment or compensation for this article. OpenRouter and the downstream model providers did not sponsor, review or endorse it. AccessAllGPT did not test, score, rank or certify either router. AccessAllGPT Research is operated by NeuralArc, is independent, and is not affiliated with OpenRouter. Publication-wide relationships are listed on the disclosures page.
