Per 1K or per 1M: the 1000x error waiting in every price comparison

Large language model prices are quoted in two units. Some sources give a price per thousand tokens, others per million. Both conventions are in wide use, both look like ordinary decimal numbers, and mixing them makes a comparison wrong by a factor of a thousand.

What makes it dangerous is the direction of the mistake. It does not produce an obviously broken figure. It produces a spectacular deal — and a spectacular deal is exactly what the reader of a pricing comparison is hoping to find.

The two conventions

Today the providers themselves have largely settled on per-million. Aggregators, older documentation, internal database columns and a good deal of tooling still use per-thousand, because that is what the convention was when the first APIs shipped.

Neither column is wrong. The failure is arithmetic between them, and there is nothing in the numbers themselves that announces which convention you are holding.

What the mistake produces

Take a real pair. A frontier model listed by its provider at 4.00 per million input tokens, resold at 0.00021507 per thousand. Converted properly, that resale price is 0.2151 per million, and the ratio is about 18.6 times cheaper — a large, believable number.

Compare the two raw figures without converting and you get 4.00 against 0.00021507: a ratio of roughly 18,600. The badge would read "99.99% off". It looks like a typo, and the reason it survives into published tables is that nobody reads a discount badge and thinks *too good*.

Where it creeps in

Four places, in roughly the order we have seen them:

• Two columns, two conventions, one table. A catalogue that stores its own price per thousand and the provider’s per million. The bug is not in either column; it is in the code that divides one by the other.
• Copying from an aggregator. Comparison sites normalise to their own convention and do not always say which. A number lifted without its unit is a number without meaning.
• Provider documentation changing convention. Several providers moved from per-1K to per-1M as prices fell. Old code that hardcoded a conversion silently became wrong.
• Spreadsheets. A column of small decimals, sorted, with no unit in the header. This one is nearly undetectable by eye.

This station stores exactly that split — site prices per thousand tokens, provider list prices per million — so the conversion lives in one tested function rather than at every call site. That is not elegance; it is damage control. A thousand-fold error in a price claim on a page that also runs ads is the kind of mistake that is worth structuring code to prevent.

How to catch it in ten seconds

Three checks, none of which require knowing the right answer in advance.

1. 01Sanity-check the magnitude. Frontier model input prices sit in the low single digits per million tokens. If a figure is in the thousandths, it is either per thousand or it is a small model — and you can tell which by looking at the output price, which is normally three to five times the input.
2. 02Check the ratio. Real relay discounts land between roughly 30% and 98%. A badge over 99.9% is almost always a units error rather than a bargain.
3. 03Convert both sides yourself, once. Multiply any per-1K figure by 1,000 and compare like with like. If the comparison collapses, the table was wrong.

On this station’s catalogue, read on 2026-08-30, the median discount across the 40 models with a comparable list price was 87%, the shallowest 31%. That spread is what a real one looks like: wide, uneven, and bounded well short of 100%. A catalogue where every model shows the same headline discount, or where several show 99%-plus, is reporting arithmetic rather than prices.

A worked example

Say you are comparing a relay’s price for a model against the provider’s published rate.

provider_list_per_1m = 4.00          # from the provider's own pricing page
relay_price_per_1k   = 0.00021507    # from the relay's catalogue

relay_price_per_1m = relay_price_per_1k * 1000   # 0.21507
discount = 1 - (relay_price_per_1m / provider_list_per_1m)

# 0.9462  ->  94.6% cheaper, and about 18.6x further per dollar.
# Without the * 1000 you would get 0.99995, i.e. "99.99% off".

The multiplication by a thousand is the entire article. It is one line, it is easy to leave out, and leaving it out produces a number that no one wants to question.

Once the units are right, there is a second layer to get right: the list price you are dividing by often has conditions attached, and reading it correctly is its own problem. And the denominator itself may simply be wrong — we audited ours and found two errors.

A reference, in both units

Published input prices for a few models, read from the providers’ own pages on 2026-08-27, shown both ways. The point is not the specific figures — they move — but the magnitudes, which are what let you sanity-check a number at a glance.

The shape to remember: frontier model input prices are single digits per million, which is thousandths per thousand. A resale price roughly an order of magnitude below that is plausible; three orders below is a units error.

Normalising a whole catalogue

If you are comparing more than a handful of models, convert everything to one unit once, at the boundary, and never mix again. Two rules keep it safe:

1. 01Put the unit in the name. price_per_1m, not price. A variable called price will eventually be divided by one called price.
2. 02Convert at the edge. One function that turns whatever the source gave you into your internal unit, called once per source. Everything downstream works in one convention.

That is exactly how this station handles it, and not by choice: the catalogue stores site prices per thousand and provider list prices per million, so the conversion sits in a single tested function rather than at every call site where a discount is computed. The comment above it says the quiet part — getting it wrong is a thousand-fold error in a public price claim.

Units are the first of three things that go wrong in a price comparison. The second is an unaudited reference price; the third is conditions the headline hides. All three sit inside the wider guide to relays.