COMPUTE AND INFRASTRUCTURE

Why input-token price stopped being the whole routing decision

Event source: OpenRouter rebuilds default provider routing around effective cost and service quality ↗

In this analysis
THE RETROSPECTIVE TAKE

The default router now considers service quality alongside effective price; the cheapest published input rate is an incomplete description of completed work.

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 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, 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 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:

QuestionEvidence 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 explain the caller’s policy boundary, while throughput and latency explain why different workloads can rationally choose different operating points.

← All retrospectives