OpenRouter or direct

Compare the routed bill, including its fee, with the direct bill plus the monthly cost of running another integration. A higher routed token rate can still cost less overall at low volume.

S

your monthly volume, in millions of tokens at your input:output mix

p_direct

the provider's own blended rate, $/M, for that mix

p_route

the cheapest marketplace rate at equal-or-better declared precision, $/M

f

the effective marketplace fee as a fraction, including any applicable minimum

C

monthly cost of one more direct integration: a second key to rotate, a second invoice, a second quota, a second thing to monitor

Routing wins while  S · p_route · (1 + f) < S · p_direct + C

Define  D = p_route(1 + f) − p_direct. Routing wins when S · D < C.

For nonnegative monthly volume S and integration cost C, if D > 0, the crossover is S* = C ÷ D: routing costs less below it, direct costs less above it, and the two tie at it. If C is zero, the crossover is zero.

If D = 0, routing costs less only when C is positive; with C = 0 the costs tie at every volume. If D < 0, routing costs less at every positive volume. At zero volume it costs less only if C is positive; otherwise both cost zero. The formula assumes fixed rates and an effective fee fraction for the scenario. It does not infer a direct rate from a marketplace quote.

Illustrative Every figure in this paragraph is made up to show the shape of the arithmetic; none is measured. Take f = 0.055, a direct blended rate of $1.20/M, and a model the marketplace resells at the same $1.20/M. Set the additional direct integration cost C to $50/month. Routing costs $1.266/M. At 500 M tokens/month, routing costs $633 versus $650 direct including C: routing saves $17. At 1,000 M tokens/month, routing costs $1,266 versus $1,250 direct: direct saves $16. The crossover is about 757.6 M tokens/month. The fee scales with volume; the assumed monthly integration cost does not.

The split is on independent sellers: distinct sellers other than the lab named in the model slug. The cheapest row per listed seller name is selected first; better declared precision breaks price ties. Comparability is assessed among those selected quotes, so a seller's higher-priced precision options are outside this comparison.

These six partition the population exactly: 158 + 84 + 46 + 36 + 22 + 2 = 348. unknown precision never enters the declared-precision gap, median or maximum, including when every independent seller's selected quote is unknown.

Identifying the lab behind a seller is name-based, with a short hand-maintained alias list for the cases where the strings differ (qwen, bytedance-seed). A miss counts a lab as independent, which inflates the independent-seller count — so 158 is a floor on how many models have nobody but the lab quoting them, never a ceiling.

The 158 / 84 / 106 split is identical under all 6 workloads. That is expected and worth stating: how many sellers exist is a fact about the market, not about your token mix. What the mix moves is how much the gap between them is worth.

Output share is output tokens as a fraction of the total; cache hit rate is the share of input billed at the cached rate. An output-heavy workload gives output rates more weight. A cache-heavy workload favors offers whose published cache-read rate is lower than their full input rate. An unlisted cache-read rate uses the selected tier’s full input rate in the blend.

Google: Gemini 2.5 Flash is the clearest case on this snapshot. It carries 7 offer rows. Counted three ways, it gives three answers:

The rows are one vendor's flex, standard and priority service tiers. A rate card is not a market. On this snapshot 60 of 348 models have a row-level spread wider than their selected-seller-name spread. Repeated rows do not add sellers; the independent-seller counts also exclude recognized names belonging to the lab.

The mirror-image trap is precision. MoonshotAI: Kimi K2.6 has 17 independent sellers and a 2.05× spread between their selected quotes, but there are not two comparable positive prices at the best declared precision. Lower or unreported precision may explain cheaper quotes; the raw spread alone does not establish a saving.

A gateway is not a discount, and OpenRouter does not claim it is. Its FAQ says it "pass[es] through the pricing of the underlying model providers without any markup, so you pay the same rate as you would directly with the provider", and that it charges a fee when you purchase credits. Both halves of that sentence are load-bearing: the token rate is not the product, and the fee is real.

What you get for the fee is genuine, and none of it is a lower rate:

• One integration instead of N. That is the C term, and for a team evaluating several models a month it is the whole argument.
• A second seller to fail over to, on the 106 models where more than one independent seller exists.
• Trying a model without opening an account with its lab. The option has value even when the rate does not.
• The fee is charged on credit you load, not per request, so it is a fixed fraction rather than something that compounds with volume.

Rates read from OpenRouter's FAQ on 2026-08-27: 5.5% with a $0.80 minimum on card credit purchases, 5% on crypto, and a plan-dependent BYOK fee above a free allowance. These are OpenRouter's published figures, not an Undominated measurement. Nothing in this repository re-fetches or verifies them, so treat them as a pointer to the source rather than a current fact — a stale fee is a wrong number, and the formula above is written in terms of f precisely so that it survives the rate changing. Note the minimum: on a credit purchase below about $14.55 the $0.80 floor costs more than 5.5% would.

We take no fee, commission or referral from any link on this page, and we do not sell inference. See independence.

Everything above is about the market. Your case turns on two prices and one number only you have, so the useful next step is measurement, not more reading.

• Bill audit — drop an OpenRouter activity export. It is parsed in your browser and never uploaded. It tells you which models you actually pay for, at what mix, and which of them something better and cheaper beats.
• Spreads — which models are worth shopping across distinct sellers at equal-or-better precision, and which apparent bargains are precision trades.
• Check a model — whether one model is on the frontier or beaten, with the switching-cost payback.
• Methodology — how effective price, precision ranking and capability-safe dominance are computed, including what is missing.

Offer data as of 2026-10-06, from OpenRouter's public model-endpoints API. Recomputed on every offer-data regeneration by scripts/compute-openrouter-scenarios.mjs. Tests require this projection to agree with the accepted offer book.