OpenRouter Provider Routing Explained: Oct 2026 Update

OpenRouter rebuilt its default routing on October 28, 2026: time to first token down 16.9%, 67% fewer 429 events in total, requests about 6% more expensive. Automatic routing can still quietly move you to a pricier provider, so the trade-off matters more than the headline.

OpenRouter's new router no longer picks the cheapest input-token price. It estimates what a good answer costs — price plus waiting plus retries — and sends each request to the provider with the lowest Routing Cost.

The 30-second verdict, with proof

OpenRouter provider routing now optimizes for Routing Cost instead of prompt-token price. The change applies automatically when a request sets no explicit provider.sort, provider.order, provider.only, or provider.ignore, and it covers the roughly 77% of traffic that goes to models served by more than one provider, per OpenRouter's announcement.

Results come from a week-long switchback test across 24 million requests and 103 billion input tokens, evenly split between old and new routers.

\*Share-of-requests figures and event-count reductions are both reported in the announcement: the 67% and 47% refer to total 429 events and total retries, not the hit-rate ratio, since one request can hit multiple errors.

Per the announcement, caller-measured TTFT p95 fell from 6,032 ms to 4,504 ms, whole-request p50 fell from 4.00 s to 3.24 s, and time wasted in failed attempts dropped from 349 ms to 242 ms per request.

Bottom line: stay on the new default for interactive chat or agents if you can tolerate ~6% higher cost; switch back to price-only for large batch jobs where every cent matters.

Routing Cost in plain English

Routing Cost answers two questions for every provider: what does one try cost, and how often does it work. OpenRouter's example: a $0.40 attempt plus $0.60 of waiting equals $1.00, divided by an 80% success chance, for $1.25 per good answer. Lowest cost wins more traffic.

Three inputs feed that number:

1. Effective price, not list price. OpenRouter estimates input and output tokens from recent traffic, then applies each provider's real cache-hit rate and token prices. Worked example from the announcement: 40K uncached inputs at $2.00/M ($0.080) plus 60K cached inputs at $0.50/M ($0.030) plus ~4K outputs at $8.00/M ($0.032), for $0.142. A provider with cheap input price but expensive cached or output tokens loses its edge here.
2. Waiting time in dollars. Throughput is end-to-end output tokens per second including time to first token (example: 5s to first token plus 500 tokens in 5s = 50 tok/s). The router converts waiting with a per-model rate based on typical provider charges and speeds. Time to first token gets extra weight because agent tool-call chains wait on it at every step.
3. Failure cost. A 429 means the provider turned the request away, so you wait for the rejection then resend elsewhere (example: 2.50 wait plus penalty × 0.4% rate adds 0.01). Reliability errors carry a heavier ~8x penalty (1% error rate raises cost ~8%), and providers far worse than peers stop getting traffic until recovery. Quality currently checks well-formed tool calls (95% well-formed raises cost ~5%), with flagged providers cut to test traffic, per the announcement.

Two guardrails prevent collapse onto one winner, per the announcement: every provider keeps a trickle of traffic so recovery is visible, and the router backs off failing providers while learning per-provider capacity caps and spilling overflow elsewhere.

Why default routing still breaks production apps

User reports illustrate four recurring failure modes that per-token price never captures.

Tool-call hops break schemas

the mid-request hop is what actually broke tool calling for me, not the sticker price on any one provider.

— u/Michael_Jeffords, r/openrouter thread on providers to avoid

Quality scoring today is mostly well-formed tool calls plus benchmark-accuracy flags, per the announcement. A mid-conversation switch can still change quantization or refusal behavior, since provider quality varies and some serve more heavily quantized variants.

Cache busting inflates bills

One thread documents ~700K-token contexts where expected $0.20 cached requests billed near $2.00 after provider changes, the pattern behind "paying 10-32x more because of broken caching." The new router pins a conversation to its original provider while cache is warm and algorithmically selects only the first request, per OpenRouter's cache-aware routing, but stickiness breaks on fallback to another provider. Users who fixed it pinned one provider with sticky sessions.

I think it's a pretty fundamental flaw in OR that you have to configure this manually beforehand.

— u/welcome_to_milliways, r/openrouter thread on broken caching

Silent expensive fallback

One production report noted part of traffic silently moving from Sonnet to Opus at ~5x the listed price with uptime green and burn jumping from $184/hr to $412/hr overall, per @CarbonOnX. The new router makes this trade explicit: a faster, more reliable provider can legitimately outrank the cheapest.

429s on paid accounts

A paid OpenRouter balance does not raise upstream capacity, as users in this 429 thread note. A 429 reflects that provider's shared pool for that model. The rebuild cut 429 events by 67% in testing, but pinning or ignoring the rate-limited provider remains the production fix. Start with how to fix OpenRouter 429 errors, and see OpenRouter Auto Router guide for the older price-weighted default.

Three routing setups that actually hold up

Which setup fits depends on hands-off speed, hard cost caps, or deterministic behavior. All use the same provider object: provider.order bypasses the new logic and tries providers in exact order, provider.only and provider.ignore filter candidates then the new algorithm picks among survivors, and any explicit provider.sort (price, throughput, latency) replaces it.

1. Stay on the new default (interactive chat and agents)

No code change needed. This fits user-facing chat and multi-step agents where each tool call waits on first token — accept ~6% higher cost as latency and retry budget. Log the serving provider (returned in the API response and activity page) with TTFT p50 and 429 rate for a week: if your 429 share stays near the new ~4% baseline and cache-hit rate holds, stay; if one provider dominates failures or cache hits collapse, move to setup 3.

2. Lock the cheapest path (batch jobs and cost-capped work)

Three ways to prefer price-based routing when cost beats speed:

{ "provider": { "sort": "price" } }

or append :floor to the model slug (meta-llama/llama-4-maverick:floor), or set default sort to price in account settings, per the announcement FAQ. Note :floor also admits flex-tier endpoints, which bare sort does not, per OpenRouter's routing guide.

Pair with a ceiling:

{ "provider": { "sort": "price", "max_price": { "prompt": 1.0, "completion": 2.0 } } }

Use for large prompts, short outputs, and cheap retries.

3. Pin a stable provider (production with cache or tool calls)

Pin when correctness, cache hits, or compliance beat per-request optimization:

{
  "provider": {
    "order": ["deepinfra", "together"],
    "allow_fallbacks": true,
    "require_parameters": true
  }
}

require_parameters only avoids endpoints missing required request parameters; it does not guarantee identical tool-call or schema behavior across providers. Reserve order with allow_fallbacks: false for compliance or BYOK cases where an outage is preferable to an unapproved provider. For most apps, allow fallbacks, narrow with only/ignore, and pass stable session_id for warm-cache reuse (sticky routing). If a provider is flaky, block it in guardrails and compare direct-provider APIs — several users report going direct removed slowness and cache issues once the model was settled (example thread).

Automatic routing is better than it was. It still does not replace pinning when one bad hop costs more than a week of slightly higher per-token prices.

FAQ

Do I need to change my code to use the new routing?

No. Requests without explicit provider sort, order, only, or ignore use the new router automatically.

How do I keep price-only routing?

Set provider.sort to "price", append :floor, or set account default sort to price.

Does the new routing override my provider order?

No. order bypasses it; only/ignore filter first, then the new algorithm picks.

Will the new routing cost more?

See the verdict table: +6.0% per 1K requests, +7.3% per M tokens in testing.

How can I see which provider actually served my request?

Check the API response provider field and the activity page, per OpenRouter docs.

Why do I still get 429s on a paid account?

Upstream shared-pool limits, not your balance. Pin or ignore the rate-limited provider.