# Why input-token price stopped being the whole routing decision

OpenRouter’s October routing rebuild followed earlier provider-quality work. The useful comparison is billed usage plus execution consequences, not a nominal rate alone.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-10-28
Original announcement: https://openrouter.ai/blog/announcements/how-we-rebuilt-provider-routing/
Canonical URL: https://retrivium.ai/retrospectives/retro-openrouter-effective-routing-cost/

The October routing change matters because the cheapest advertised input rate can be the wrong unit for comparing inference routes. A request also occupies time, may encounter a capacity failure, and can require another attempt. OpenRouter moved its default selection toward a composite view of those costs. That does not make every faster provider economical for every workload; it changes which question the gateway tries to answer.

## The earlier quality problem

The [Exacto announcement](https://openrouter.ai/blog/announcements/provider-variance-introducing-exacto/) on October 21, 2025 treated provider variation as a quality problem for tool calls. The important historical point is the object of comparison: identical model names did not make hosted execution interchangeable. A buyer choosing a model still had to care about the operator serving it.

That observation weakens a simple commodity assumption. If an application must repeat a malformed tool interaction, the first attempt's low unit rate is an incomplete description of the work purchased. This is a reasoning example, rather than a measurement of how frequently that happens.

## Automation before the general rebuild

[Auto Exacto](https://openrouter.ai/blog/announcements/auto-exacto/), announced on March 12, 2026, applied automatic provider selection to tool traffic. It is a concrete precursor to the broader optimizer, though chronology alone does not prove that its implementation caused the later design. The sequence shows a recurring product problem: selection had to respond to observed execution, not only a static catalog.

A manually curated list can preserve useful quality boundaries. It also leaves an operator responsible for revising that list when performance changes. Automatic selection moves part of that recurring work into the gateway.

## What changed in October

The [October 28 announcement](https://openrouter.ai/blog/announcements/how-we-rebuilt-provider-routing/) describes default routing that weighs effective price, responsiveness, throughput and failures. The causal hypothesis is that broader traffic made a single published rate less useful as a sufficient ordering rule. This is an editorial interpretation of the documented progression, not a claim about internal decision meetings.

Consider a background classification job and an interactive coding assistant using the same model. Waiting is cheap for the first and expensive for the second. A composite default can improve the average selection without proving that these applications share the same preferred tradeoff.

## A comparison artifact for buyers

A useful route comparison separates the invoice from execution consequences:

| Question | Evidence needed |
| --- | --- |
| What was billed? | Actual usage and applicable provider rate |
| Was the result usable? | Application validation and retry history |
| How long did work occupy the workflow? | End-to-end timing, including failed attempts |
| Was the route eligible? | The caller's privacy and provider constraints |

These columns prevent a low nominal rate from silently standing in for a completed task. They also prevent a gateway's aggregate experiment from becoming an application-specific savings claim.

## The remaining choice

Explicit price-oriented selection remains a meaningful policy when waiting is acceptable and outputs are independently validated. A composite optimizer is useful when operational consequences belong in the default decision. Neither policy removes the need to define success at the application boundary.

The historical change is therefore about the unit of optimization: from a readily visible token rate toward the conditions under which those tokens become useful work. [Provider routing controls](/journal/openrouter-provider-routing/) explain the caller's policy boundary, while [throughput and latency](/journal/throughput-latency-tradeoff/) explain why different workloads can rationally choose different operating points.