A checklist for an inference pricing page

The short version

An inference pricing page buyers can compare names each model exactly, with maker and version; gives input and output rates per million tokens side by side; states cached and batch rates with their conditions; gives the served context window; lists rate limits by tier; and links to retirement dates. Each item answers a question a buyer otherwise asks support or answers by assuming the worst.

The posts this checklist draws on go into each item. What follows is the order to work through them, and the one test each must pass.

Most of these items cost nothing to publish. They are facts the provider already holds, written down in one place, in the unit and the name buyers use.

Naming and the two rates

Start with the name, because every other fact attaches to it. Maker, family, size, suffix and version, as one searchable string. Resellers who name the maker are matched to every other seller of the model; those who do not can sit alone. The test: could a buyer paste your model name into a search box and land on the same model elsewhere?

Then both halves of the price. Input and output side by side, per million tokens, plain text in a table. A blended rate, if you want one, goes below them with its ratio. The test: could a buyer cost their own workload from the page without opening another tab?

If a model has a second rate above a prompt length, that is a separate row with the threshold in tokens, not a footnote.

Put the currency once at the top of the table and the date the rates were last changed beside it. Both are small. Both stop a comparison going wrong before it starts.

Discount tiers with their conditions

A cached rate is only usable with its conditions. What counts as cached, how long it lasts, whether it must be requested, and what a cache write costs. Test it on an engineer who has not read your docs: can they say how to arrange a prompt to get the rate?

A batch rate needs its window. The trade a batch tier makes is speed for price, and a buyer can weigh it only with the completion window, what happens to late requests, the batch limits and the list of models covered. Ask whether a buyer could schedule a nightly job from what is printed.

Name the models each tier covers on the row of each model, never in a paragraph above the table. A buyer scanning rows sees a blank where a cached or batch rate should be and moves on.

Context, limits and retirement

Give the context window on every model row, as served, in tokens, with the output limit and any long-context rate beside it. A blank is no answer on record to a buyer's filter, and the model leaves the list.

Put rate limits on the pricing page by tier, in named units, with what moves an account up and what happens at the cap. Link every model with a scheduled retirement to one page of dates and replacements. The test for both: could a buyer plan a launch and a migration from the page alone?

For retirement the test is simpler: pick any model on the page and see whether a buyer can tell, from that row, whether it is scheduled to go and what replaces it.

Three readers to test the page on

Give the finished page to an engineer, someone from finance and a script. The engineer should be able to estimate a month of their own traffic, say which tier they start on and name the prompt layout that earns the cached rate. Finance should be able to put every rate into a spreadsheet without converting a unit. The script should find each rate as text in a table cell with a header that names it.

Each reader fails differently. Engineers stop at a missing limit. Finance stops at a rate in credits or per thousand tokens. A script stops at an image, a toggle or a rate inside a sentence. Fix what stopped them and run it again.

Date the page. A line saying when prices were last changed tells a buyer how old their comparison is, and tells a reader on our side whether a difference from the last read is a change or an error.

After the page is right

For a popular model sold by several sellers, these facts are the whole argument. How far token prices spread between sellers of one model is the comparison buyers run, and the page decides whether the dearer rate looks earned.

Then claim the listing. It is free, it proves the page is yours, and it lets you correct a value, answer the questions asked of your category with a source, and see thirty-day totals of views and comparisons. A rate we read is shown with its source and date, and hidden after 21 days if we cannot read it again.

Paying does not change where a product ranks. Paid placement on this site is labelled and sits outside every ranked list, and no amount of money buys a higher position in the token table or an edit to a rate in it.