In this analysis
Provider order and explicit sort bypass the new router; only and ignore constrain its candidate set without necessarily pinning execution.
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 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 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 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 explains the upper decision layer. Provider routing controls 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.