October 28 catch-up
OpenRouter says its October 28 routing update balances price, waiting time, and reliability on enabled models. It does not establish universal rollout or an exact launch hour. [1]
Better performance can cost more
In its week-long, 24-million-request experiment, OpenRouter reports roughly 6% higher cost per request and faster responses. We did not reproduce those findings. Its displayed capacity-error rates do not reproduce the quoted reduction, so we omit that percentage. [1]
Filters and explicit sorting do different jobs
Explicit provider.sort or provider.order bypasses the new algorithm; provider.only and provider.ignore filter its candidates. Warm-cache conversations normally retain their provider, with fallback when unavailable. [1]
The linked provider guide still describes the older price-based default, which conflicts with the new announcement. It documents sorting and fallback controls. Its :floor shortcut also admits flex-tier endpoints, so do not treat that shortcut as identical to a plain price sort. Confirm the policy used by your particular model and request. [2]
Our take
Write down whether the application prioritizes cost, response time, or reliability, then inspect its actual provider metadata and usage bill. Use an explicit supported preference when that priority must be predictable. A routing preference does not fix a token price, guarantee the final bill, or independently prove answer quality.
We read public sources and made no OpenRouter API request or account change.