What buyers compare before they choose an LLM API

Four questions, in the order they can be checked

A buyer choosing an LLM API compares the price per million input and output tokens first, then the context window, then the rate limits on the tier they can afford, and last what happens when the model is retired. Each question removes providers from the list, so a provider whose page cannot answer one of them can leave the shortlist at that step, whatever its rate.

The first cut is wide. We hold token prices for 467 models from 16 providers, and 93 of those models are sold by more than one seller. For those models the buyer is not choosing a model at all. They are choosing a seller, and the seller has to give them a reason.

Sellers of a model nobody else sells skip the first comparison and meet the second one harder. With no rival on the same model, the buyer compares them against a different model at a similar rate, and context, limits and retirement policy become the whole case.

The rate is read in two halves

Input and output are priced separately per million tokens, and output is commonly the dearer half. Anyone with a real workload knows roughly how much text goes in and how much comes back, so both rates get read and weighted. The token price table shows both, by model, with the page each was read from.

Without a known mix, a calculator does the weighting. The LLM cost calculator takes a monthly volume of input and output tokens and prices it across every seller of a model. It uses only published rates, so a discount that lives in a sales email does not appear, and the provider that relies on one looks dearer than it is.

Cached input and batch tiers come into the comparison here, for buyers whose traffic repeats or can wait. They are a reason to stay on a slightly dearer seller, but only if the page says what qualifies.

Rates also move. A team that costed a workload last quarter may see a change on its invoice before any announcement reaches it. A dated line saying when the rates were last changed is cheap and stops that conversation from starting badly.

Context length removes models, not sellers

The context window is a yes or no question. A buyer who needs to pass a long contract or a codebase in one request filters out every model that cannot take it, before thinking about price again. The same model sold by several sellers may also be served with a shorter window at some of them, so the served window has to be checked seller by seller.

So the figure belongs on the price page, beside the rate, for each model and not once in a footnote. A seller that serves a shortened window and says so loses the buyers who need the long one and keeps the trust of everyone else. A seller that does not say so finds out from a support ticket.

Order matters for the seller here. A provider that wins on rate and then loses on context has spent its best argument on a buyer who was never going to stay. Putting the window next to the rate lets the wrong buyers leave early and cheaply, which costs both sides less than a trial account that ends at the first long prompt.

Limits decide whether the price can be paid

A low rate at a limit of a few requests a minute is a price for a prototype. Buyers moving to production ask how many requests and tokens per minute they get on each tier, how a tier is reached, and what happens when they exceed it: a queue, an error, or a bill.

A provider that publishes this only in its documentation loses a step. Comparisons happen in tabs, with the pricing page open, and a limit three clicks away is easy to treat as a limit that is not stated.

Our data does not hold limits, so the comparison a buyer makes on this step happens on your page or not at all. Tiers named by spend, with the requests and tokens per minute each one allows, are enough for them to decide.

Retirement is the question that arrives last

Models are retired, and an application built on one has to move. A team that has done that once will want the notice period, the named replacement and whether the replacement is priced the same. The question comes last because it does not change the first invoice, and it carries weight because it changes the second year.

An alias that silently points to a newer version is a version of the same question. A buyer whose outputs changed overnight wants to know which name is pinned and which one moves.

Procurement has its own reason to ask, because a forced migration is a project with a cost and somebody has to budget for it. A dated retirement list that has been kept up for a year is evidence they can put in a vendor review.

What the page can do about all of this

Put the four answers on one page, in the order buyers ask them: rates for both halves, context window, limits by tier, and the retirement policy with a link to the list of dates. Name the model exactly, with its version, so it matches the listing a buyer is comparing against.

Then claim the listing. It is free, it lets you correct a value we read wrongly, and it lets you answer the questions asked of your category with a source. How each figure is gathered is written down, including that a rate older than 21 days is hidden rather than shown stale.