What happened
On October 28, 2026, OpenRouter announced what it calls its largest provider-routing change since the company was founded. The change applies when a request targets a model served by more than one provider and the caller has not supplied an explicit provider list or sort instruction. OpenRouter says roughly 77% of its requests fall into that multi-provider category.
Previously, the default router mostly ranked providers by input-token price. A failed request would fall back to the next-cheapest option. OpenRouter argues that this delivered low listed prices but did not reward speed, real-time reliability, or quality. It also says the old approach could be distorted by pricing mixes in which low input pricing was offset by more expensive cached or completion tokens.
The replacement calculates a real-time “Routing Cost” for each endpoint. It estimates a request's input and output token use from recent traffic, then combines the endpoint's effective price with the cost of waiting and retrying. Effective price incorporates observed cache-hit rates and the typical input-output mix rather than relying only on a list price. The performance component includes end-to-end output throughput and time to first token (TTFT). TTFT receives separate weight because it matters repeatedly during interactive work and agent runs with successive tool calls.
The router also incorporates HTTP 429 rate-limit events, provider-caused failures, and quality signals. A 429 adds the time spent reaching a rejection, the expected retry, and a penalty weighted by its frequency. Reliability failures are treated as expensive because another attempt is required. For quality, OpenRouter currently says it checks whether tool calls are well formed and may reduce traffic to providers whose tool calling is broken or whose benchmark accuracy is materially below the model's expected level. Traffic is shared among providers near the competitive edge rather than sent entirely to one endpoint; capacity caps and backoff limit traffic to endpoints that struggle.
OpenRouter reports a one-week A/B test covering 24 million requests. Under the new default, p50 TTFT was 16.9% lower and throughput was 16.3% higher. Requests encountering at least one 429 declined from 7.1% to 3.8%, a 46% reduction, while cost per thousand requests increased 6.0%. Callers can bypass the new default with explicit sorting, provider selection, or their own keys. The :floor suffix retains price-only sorting and admits flex-tier endpoints; :nitro is also listed among the suffix-based routing controls.
What the archive adds
This is a new fact in a known routing story. Introducing FireRouter with Opus framed routing as a cost-quality trade-off rather than a free efficiency gain. OpenRouter now supplies a production-routing example where latency, retries, capacity, and tool-call usability are explicitly converted into the default selection policy.
Trend signal
This supports Agent economics moves to completed work. OpenRouter is not pricing a model call as an isolated unit: it treats waiting, rejection, retries, and unusable tool output as costs of obtaining a useful result. Its metric remains routing cost rather than verified task completion, but it moves operational accounting closer to the outcome a caller actually needs.
Why it matters
Provider routing is part of application behavior, even when a team does not write a router itself. A cheaper endpoint that produces slow first tokens, capacity rejections, or malformed tool calls can make an agent workflow more expensive in elapsed time and retries than its token price suggests. OpenRouter's change makes that trade-off automatic for default users, while preserving a price-first escape hatch.
Teams should therefore treat the default as a product change, not simply an infrastructure improvement. A lower latency and error rate may improve interactive and tool-using workflows, but the reported aggregate 6.0% spend increase may not match a particular model, workload shape, cache pattern, or provider set. The appropriate choice depends on whether a workflow values predictable completion, lowest spend, or direct control over providers.
Limits and uncertainty
The results are OpenRouter's own one-week A/B measurement, not an independent benchmark, and the supplied material does not break results down by model, provider, region, workload, or customer. It does not establish whether the measured tool-call quality check catches all failures that matter to an agent workflow. Nor does it say how routing-cost weights vary by model or how often a caller will see a different provider in practice. The 6.0% figure is an aggregate cost-per-thousand-requests result, not a promise for an individual deployment.
Skill to build now
Instrument one representative OpenRouter workflow this week and compare default routing with an explicit :floor run. Record end-to-end completion time, TTFT, 429s, provider failures, retry count, tool-call validity, and total charged cost. Use the same prompts and a fixed test window. This turns the platform-level averages into a decision tied to the workflow your team actually operates, especially if it makes several sequential tool calls.
Reader takeaway
OpenRouter's default router is no longer a cheapest-provider selector. It now spends somewhat more, by its measurement, to buy speed, capacity, reliability, and usable tool calls. Builders using the default should measure the change in their own traces; builders optimizing strictly for price should choose the explicit price-first route.
Open question
Will OpenRouter publish model- and provider-level evidence showing when the added routing cost produces better task completion rather than only better request-level performance?