OpenRouter Price Watch

Reading the table

• $ — cheapest release of a model that ships as several dated versions at different prices; hover for the version count.
• ▼n% ▲n% — price change since your baseline, which is stored in this browser and re-anchored by Reset change baseline; hover for the old price.
• green / amber Est. avg — expected cost below / above the headline price; hover for each provider's estimated share.
• +n — how many other providers serve the slug; hover the provider name for the whole roster with prices.
• ↓n% — a different provider serves the same model that much cheaper than the default route.
• free batch — separate service tiers rather than cheaper releases, so each has its own checkbox and neither competes for the $.
• alias — a ~ routing alias (~openai/gpt-latest), which has no provider roster of its own.
• Sorting by Model nests each release line over its variant families, cheapest first inside each; those headers collapse when clicked.

A slug is a menu, not a price

A model id like deepseek/deepseek-v4-pro is not one product. Around eighteen different companies run those weights — StreamLake, Baidu, DeepSeek themselves, CoreWeave, Novita, Azure and more — each at its own price, quantization (fp8, bf16), context length and throughput. One company can list several endpoints for a slug, and first-party vendors also sell service tiers under the same name: openai/flex at half price, openai/priority at double.

You are billed by whoever served you

OpenRouter passes provider pricing through without markup and deducts credits based on the tokens the serving provider reports. So the cost of a request is the rate of the endpoint that handled it — two identical calls a minute apart can bill differently if they land on different providers. For deepseek/deepseek-v4-pro the roster spans about 5× from cheapest to dearest, so that difference is not academic.

How the default route is chosen

Unless you say otherwise, OpenRouter load-balances rather than always picking the cheapest: it drops providers that had an outage in the last 30 seconds, then chooses among the rest by price with inverse-square weighting — halving a price makes a provider four times as likely — falling back to the others on failure. You can override that with sort: "price" (the :floor suffix), :nitro for throughput, an explicit order list, only/ignore, max_price, or allow_fallbacks: false to pin the top choice.

What this page computes

Input, Output and Cache read are the rates of OpenRouter's default route — the endpoint whose price matches the models API listing, named in Provider. Blended weights input against output by your ratio, because output tokens usually dominate a real bill:

blended = (in × input + out × output) / (in + out)

Est. avg is what a request should cost on average across the whole roster, given that routing. With p a provider's blended price and u its 30-minute uptime, share of traffic w ∝ u / p², so the expected price is

E[p] = Σ(u_i / p_i) / Σ(u_i / p_i²)

Deranked endpoints (negative status) and opt-in tiers (flex, priority, batch, zdr) are left out, since default traffic never lands on them. Hover any Est. avg cell for the per-provider shares.

How much to trust it

• The exponent is documented behaviour, not a published constant. If routing is really inverse-linear, or weights per-request cost rather than per-token price, these estimates shift.
• Uptime barely moves the result in practice — providers with genuinely bad availability are usually deranked already, and what remains sits at 96–100%. The exclusion does more work than the weighting.
• Your account settings win. Ignored providers, data-policy limits and an explicit sort all change the distribution; with sort: "price" you pay the roster minimum, not this mean.
• Provider prices move during the day (some carry a discount field), so an estimate can drift by a few percent between refreshes.