The same model costs 75x more depending on who you buy it from

gpt-oss-120b is served by 59 providers. The cheapest charges $0.039 per million input tokens. The most expensive charges $2.92. Identical weights, identical model, 75x the price.

That is not an outlier I went looking for. It is the third row of a catalogue I rebuild every six hours, and the pattern holds across the market: of 1,889 model families with published prices, 816 are served by more than one provider, and among those with at least three providers the median gap between cheapest and dearest is 45%.

Most teams pick a provider once, wire it in, and never revisit the decision. The bill grows, the model stays the same, and nobody re-runs the comparison because doing it properly is tedious. This is what doing it properly looks like.

Where the prices come from

I pull two independent, openly licensed catalogues: models.dev and LiteLLM's price table. Neither is treated as authoritative. Vendors are never asked to report their own competitiveness, and a single upstream source is a single point of failure for a number you are about to make a purchasing decision on.

Together they yield 6,780 priced offers. Getting to a number you can actually trust takes two filters, and both matter more than the aggregation.

Filter one: prices that are not prices

LiteLLM states cost per token. models.dev states cost per million tokens. That is fine until a contributor writes a per-million figure into a per-token field, which has happened for 16 model rows across three providers.

Left alone, one of those rows claims $15,000 per million input tokens. Feed that into a monthly workload and it renders an $8.37 million bill for a model that actually costs about nine dollars a month to run. Worse, it silently poisons every comparison that model appears in: the "spread" for that family becomes 880,000x and the genuine 40% saving next to it disappears into the noise.

So anything above $200 per million tokens is rejected as a unit error rather than published. For calibration, the 99th percentile of real input prices is $15 per million. The ceiling is generous by more than a factor of ten, and the tool reports how many rows it dropped instead of quietly discarding them.

Filter two: when two sources disagree

Where both catalogues price the same provider and model, they should agree. In 65 cases they do not, and the disagreements are not rounding:

• Azure GPT-4 Turbo — $10 vs $30 per million input tokens
• Azure GPT-4o — $2.50 vs $5.00
• DeepSeek Chat — $0.14 vs $0.28

Every one of those is a factor of two or three. Averaging them would produce a number that is wrong in a new and undetectable way, so disputed rows are marked as disputed and left for a human to verify. A price two independent sources argue about is not a price you should quote to anyone.

Getting this check right took a correction. My first version compared the catalogue against itself and reported 217 "disputes" — most of which were a single provider legitimately selling two variants of the same model at different prices. Only comparisons between the two feeds count. That is the difference between 65 real findings and 217 pieces of noise that would have destroyed trust in the whole exercise.

What the spread actually looks like

Take a fairly ordinary workload — 30 million input tokens and 8 million output tokens a month — and price it across every provider serving the same model:

• Llama 3.1 405B — 5 providers, $6.00 to $287.90 a month
• Qwen3 235B — 7 providers, $2.93 to $114.00 a month
• DeepSeek V3 — 12 providers, $6.44 to $126.00 a month

Scale those by 10x or 100x, which is where a real product sits, and the difference stops being a rounding error on the AWS bill and becomes a line item somebody has to explain.

Try it on your own workload

The comparison is free and takes no signup, because the comparison is the easy part: run your model and volume through the repricer.

What list prices will not tell you

I would rather say this plainly than have you discover it later. Comparing list prices for one model is the shallow end. It knows nothing about your cache-hit rate, your real input/output ratio, your latency floor, your rate limits, your committed-use discounts, or what your invoice actually says — and in most teams a larger share of the waste is hiding in exactly those places than in the provider choice.

The cheapest row is also not automatically the right answer. Several of the lowest prices belong to aggregators and routers rather than the lab serving the weights, which carries its own reliability and data-handling questions. The output is a shortlist to verify, not a quote.

That deeper analysis is what the Find the Waste week does: your real usage, your whole workload rather than one model, and a ranked list of fixes at the end. If it cannot find enough to pay for itself, it costs you nothing.