OpenRouter Auto Code claims Opus-level coding at 74% lower cost

• Auto Code reaches Opus 5.5-like benchmark performance at 74% lower cost per task in OpenRouter's tests.
• Routing overhead falls to 0.65 seconds at p90 in OpenRouter's live test, down from 1.96 seconds. That measures model selection, before the selected model answers.
• Model choices are inspectable through chat and opt-in API metadata, according to OpenRouter's walkthrough.
• Beta traffic produced one-quarter as many invalid tool calls and half as many truncated agent responses as the previous router, according to OpenRouter.

Auto Router stayed with the same model for nearly nine in ten beta agent turns, a welcome bit of cache awareness. The configuration docs also disclose that the unchanged openrouter/auto slug now defaults to a more expensive model mix.

OpenRouter's 74% savings claim covers cost per evaluated task across five benchmarks. The benchmark board, updated November 7, lists aggregate costs of $1.64 for Auto Code versus $6.43 for Opus 5.5 at high effort.

Against that Opus baseline, two coding results illustrate the trade-off:

• Deep SWE: Opus 70.5% → Auto Code 74.3%, +3.8 points.
• Terminal Bench 4.0: Opus 53.1% → Auto Code 50.0%, −3.1 points.

The frontier chart's quality score averages performance relative to the best router on each benchmark. Single-model baselines that outperform every router are capped at 10 on that benchmark.

Coding-harness performance was the most common complaint about earlier Auto Router versions, OpenRouter says in its launch post. Both products share an engine, but Auto Code changes three policy priorities:

• Starts with a higher-cost tier containing stronger coding models.
• Weighs speed more heavily.
• Penalizes failures more harshly, increasing the likelihood of changing course.

The shared engine processes each request in five steps:

1. Filter eligible models. Apply guardrails, zero-data-retention requirements, model capabilities, provider restrictions, bring-your-own-key settings, and allowed or excluded model lists.
2. Rate the request. One decision-model call scores eleven aspects, including task type, task changes, difficulty, speed sensitivity, vision, codebase knowledge, and potential benefit from larger models or more reasoning.
3. Choose model and effort. Combine those ratings with live prices, benchmark performance, and cache state.
4. Choose a provider. Apply the same provider routing used for a direct model request, including provider preferences, uptime, latency, price, and existing prompt caches.
5. Carry signals forward. Feed model-struggle and cache signals into the next turn's selection.

Restrictions therefore define the candidate pool before model selection. OpenRouter claims its cost optimization continues within that restricted pool.

Switching models requires rebuilding the input-token cache. The router prefers changing reasoning effort when that is sufficient, and switches when the expected gain justifies losing the cache.

Repeated errors or tests failing after an edit increase the odds of a switch. Sessions are recognized through an explicit session_id, or a fingerprint of the messages when that field is absent, according to the session documentation.

The API's opt-in header is X-OpenRouter-Metadata: enabled. The chatroom exposes the analysis beside each reply.

The documented response mechanics include:

• Decision details: The jev-router stage in openrouter_metadata.pipeline contains resolved_models, candidate models with reasoning effort and estimated cost, and the reason for the pick.
• Streaming: Metadata arrives in the final chunk before data: [DONE] for Chat Completions and Responses, or in the terminal message_stop event for Anthropic Messages.
• Response-cache replays: Cached responses omit routing metadata so they do not expose stale routing decisions.

The metadata reference also specifies that unrecognized header values fall back to disabled.

Auto Router handles more than 2.5 trillion tokens from over 100,000 people monthly, according to OpenRouter. Its beta comparison against the previous router reports:

• Invalid tool calls: Fourfold reduction.
• Truncated agent responses: 50% reduction.

New listings enter consideration immediately, according to OpenRouter; benchmarks and popularity signals determine which earn a place in the cost-optimal set. The catalog contains more than 600 models, and the public router pages distinguish actual usage from the projected mix for new work.

Both routers charge the selected model's standard rate, with no additional routing fee. The response's model field identifies which model actually served the request.

The configuration reference documents several migration details:

• Model strings: openrouter/auto remains the general-purpose route; openrouter/auto-code is the coding route. Existing Auto requests receive the rebuilt router without changing the slug.
• Default spending: The general router's default policy costs more per task than its predecessor to include a wider model range. Setting cost_tier to low approximates the previous cost behavior. Cost tier controls routing policy, separately from model reasoning effort.
• Plugin IDs: Stable Auto settings use auto-router; Auto Beta settings use auto-beta-router. Settings under the wrong ID are accepted but silently ignored, including allowed_models, excluded_models, and cost_tier.
• Legacy settings: The current router ignores cost_quality_tradeoff and pin_model, although requests containing them still succeed.
• Data region: Auto Router is available only in the global data region.
• Input format: Requests require conversational input or messages; the legacy prompt field is unsupported.