Publish input and output token prices side by side

Half a price is a different number

Publish the input rate and the output rate for each model next to each other, in the same unit, per million tokens. A buyer cannot cost a workload from one of them, because output is commonly priced higher and the share of output in a bill depends on the job. A headline built from the input rate alone describes no bill anybody will receive, and a buyer who has been caught by one has reason to read it as a warning.

On the token price table, a value we could not read is shown as no answer on record, never as zero. Where a page gives the input rate and leaves the output rate to the docs, a reader of the table meets one half and a gap.

A row with one rate shows a buyer the cheap half and says nothing about the half that often decides the bill. Printing both where a reader finds the first costs the provider one more cell.

The same rule covers the unit. A rate per thousand tokens beside rivals quoting per million is read by some buyers as cheaper by a long way, and by the careful ones as a page that wants to be misread.

What a buyer does with the pair

An engineer estimating cost takes a sample of real requests, counts the tokens going in and coming out, and multiplies each count by its rate. Then they multiply by expected monthly volume. The sum is the number that goes into a budget, and it is the number they will hold the first invoice against.

Procurement does the same sum with less patience. They want to paste two rates into two cells and get a monthly figure, for every provider on the shortlist, in an afternoon. A page that needs reading twice to find the second rate makes that afternoon longer, whether its rate is good or not.

Neither of them can work backwards from a single figure. A blend, a starting-from price or an example bill for a made-up workload all fail the same way: the buyer cannot separate the halves to apply their own mix.

The job decides which half matters

Summarising a long report reads a great deal and writes a little, so the input rate carries the bill. Drafting marketing copy from a two-line brief does the opposite. A classification call reads a paragraph and writes one word. An agent that thinks out loud before acting can write more than it reads, and the output rate becomes most of the cost. A chat product sits in between and drifts as conversations grow, since each turn resends the history as input.

Buyers know which of these they are running. What they need from the page is both numbers, so they can do the weighting themselves. A provider that pre-weights them into a single blended rate has chosen a mix on the buyer's behalf, and the buyer has no way to tell whether it is theirs.

How a blended rate misleads in both directions

A blended rate assumes a ratio of input to output. If the buyer's ratio has more output than the assumption, the blend understates their bill. If it has less, the blend overstates it and the provider looks dearer than a competitor that published two plain rates.

Either way the figure fails at the moment the buyer checks it against an invoice. That check happens in the first month, and it is when a buyer decides whether a pricing page can be trusted for the next model they need.

If a blend helps your marketing, publish it as well, labelled with the ratio it assumes. Put it below the two real rates, never instead of them.

Where the comparison breaks

Some pages quote per thousand tokens and some per million. Some quote input on the pricing page and output on a model card. Some give a rate in credits, with the price of a credit somewhere else. Each of these makes the buyer do a conversion, and every conversion is a chance to get it wrong in the provider's disfavour.

The cost calculator holds every rate per million tokens so a buyer can enter a monthly volume of each half and see what it comes to across sellers. A page that already uses that unit can be read without arithmetic, and a value read without arithmetic has one fewer step at which to go wrong.

Currency belongs in the same list. A page that prices in one currency and bills in another, at a rate set on the day, has added a figure the buyer cannot see in advance. Say which currency the invoice uses.

A layout that survives being copied

One row per model. Columns for the exact model name and version, input per million tokens, output per million tokens, and then cached input and batch if you offer them. Currency stated once at the top. No footnote that changes a rate. If a model has a second rate above some prompt length, it gets a second row with the threshold in its name.

That table will be pasted into a spreadsheet by a buyer and read by a script on our side. Both work best when the rate is plain text in a cell and the column header says what it is. A rate drawn as an image or behind a toggle may be read late, or wrongly, and a wrong value can be disputed but costs both sides time.