# What the new OpenRouter router leaves under caller control

The October router separates provider eligibility from provider selection. Ordered routes, explicit sorts and candidate filters have different effects.

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-routing-explicit-constraints/

The rebuilt OpenRouter default does not erase caller policy. An ordered provider list and an explicit sort still bypass the new optimizer, while an allowed or ignored provider list restricts the candidates on which it operates. This distinction is central to reading the October announcement: choosing the search space and choosing the winner inside that space are different decisions.

## Why provider choice already had layers

On October 21, 2025, [Exacto](https://openrouter.ai/blog/announcements/provider-variance-introducing-exacto/) made provider variation visible through a curated tool-calling route. That earlier product did not replace model selection. It added a hosting-quality decision underneath the selected model, demonstrating why a single model identifier can conceal several execution paths.

For an application owner, those layers create different responsibilities. A model choice concerns capabilities and behavior. A provider restriction can concern processing policy or an established operational relationship. An optimizer concerns the relative attractiveness of otherwise eligible execution paths. Combining these into one unexplained default makes policy difficult to audit.

## The automatic-selection precursor

[Auto Exacto](https://openrouter.ai/blog/announcements/auto-exacto/) on March 12, 2026 introduced automatic selection for tool traffic. It established a useful historical tension: the gateway can adjust to changing service conditions more frequently than a manually maintained application configuration, but automation needs a defined boundary.

Our causal interpretation is that widening automatic selection increases the importance of preserving explicit controls. The sources document the progression and the controls; they do not prove that this particular governance concern drove the company's implementation choices.

## Read the October controls as a decision tree

The [October 28 routing explanation](https://openrouter.ai/blog/announcements/how-we-rebuilt-provider-routing/) supports the following distinction:

| Caller instruction | Effect on the rebuilt default |
| --- | --- |
| Explicit provider order | Follow the specified order instead |
| Explicit provider sort | Use the requested sort instead |
| Allowed or ignored providers | Filter eligibility, then optimize among those remaining |
| No explicit ordering or sort | Apply the new default selection |

A restriction is therefore not equivalent to pinning. If several eligible providers remain, selection may still change as their observed conditions change. Conversely, an ordered list can intentionally preserve an operational preference even when another candidate looks better to the optimizer.

## A policy review with a concrete result

Imagine a team that permits a small set of processors and wants dynamic selection within that set. Its review artifact should contain the permitted set, the reason for each restriction, and the intended selection rule. Recording only a model name would leave the most consequential routing boundary implicit.

A different team might need a predetermined provider sequence during incident investigation. It should describe that as an ordered route, rather than assuming a filter freezes traffic. The distinction matters when comparing before-and-after traces: the same candidate set does not imply the same selected endpoint.

## What this changes in a retrospective

The historical story is not that control disappeared as routing became more intelligent. It is that an additional automatic decision now sits between eligibility policy and actual execution. An audit should separately ask whether the chosen provider was allowed and whether the intended ordering rule applied.

[Model routing versus provider routing](/journal/model-routing-vs-provider-routing/) explains the upper decision layer. [Provider routing controls](/journal/openrouter-provider-routing/) supplies the vocabulary for expressing the lower one. Together they help identify whether an unexpected route is a policy failure or an expected outcome of dynamic selection.