How to Read an LLM Price List

Every inference provider publishes one, and at first glance they all look alike: a model name, an input price, an output price, per million tokens. It reads like a spec sheet, and teams routinely treat it like one — sort by the headline number, pick a winner, move on.

That is how budgets go wrong, because the headline number is the beginning of the price list, not the price. The real bill depends on which row of the list your traffic actually lands on, and modern price lists have more rows than they used to. Cached tokens, batch tiers, context-length surcharges — each is a different price for the same model, and the gap between rows is wider than the gap between most providers.

This post walks the rows, deliberately provider-neutral: every pattern below exists on multiple real price lists, ours included. The aim is that the next one you open — ours included — reads like a contract instead of a menu.

A token is not a word. Models consume text as subword pieces — common words whole, rare words chopped into fragments, punctuation and whitespace counted too. English prose averages well under a token per word; code, non-English text, and formatting-heavy content tokenize denser, sometimes much denser.

The catch for comparison shopping: tokenizers differ across model families. The same paragraph does not yield the same token count on every model, so “per million tokens” is not quite the same unit on two price lists. For rough budgeting that hardly matters; for a close decision between providers, run your actual prompts through both tokenizers before trusting the arithmetic.

The habit that pays: whenever a list states a per-million-token number, translate it into your own units — per ticket resolved, per document summarised, per page extracted — before comparing anything.

Because they are two different workloads behind one API. Reading a prompt is parallel work: the model processes the whole input at once, and the hardware chews through it efficiently. Writing the response is sequential: every output token is generated one at a time, each depending on all the ones before. Sequential work holds expensive hardware busy longer per token, so output costs more — typically several times the input rate, on nearly every list in the industry.

The design implication is real: response-length discipline is a cost lever that prompt-engineering discipline is not. A system prompt halved saves at the input rate; a response format that answers in half the tokens saves at the output rate. On a well-designed workload the output row matters more than the input row — teams shopping by input price are optimising the cheaper half of the bill.

Model input and output volumes separately when estimating. A chat product and an extraction pipeline can have identical total token counts and wildly different bills, purely from which direction the tokens flow.

Some lists carry a discounted row for cached input tokens, and it is the most under-read row in the industry. The idea: when the beginning of a prompt is byte-identical across many requests — a system prompt, a policy document, a knowledge-base extract — the provider can reuse the computed state for that prefix instead of reprocessing it. Work avoided is priced lower, so cache reads bill at a fraction of the standard input rate where the row exists.

Whether you benefit is an architecture question, not a pricing question. Workloads with a long, stable prefix and a short variable tail — document Q&A over a fixed corpus, a support bot with a large policy prompt — are cache-shaped; workloads where every request is novel text gain nothing.

Two things to check on any list: whether a cached row exists at all, and what its design constraints are. Prefix caching only helps when identical content comes first, which makes prompt layout a billing decision. That rabbit hole gets its own post; for now, find the cache row before you find the headline.

Real-time rates buy immediacy — the request jumps the queue and the first answer bytes arrive in a heartbeat. Batch and flex rows sell the same computation with the urgency removed — submit work now, collect results later, pay less for being interruptible.

The discount exists because deferrable work is worth more to the provider than to you: it fills idle capacity that would otherwise earn nothing. A support report generated at midnight and read at nine in the morning has no business paying real-time rates — yet a surprising share of production traffic is exactly that, batch-shaped work on an interactive tier, because nobody asked the deadline question when the pipeline was built.

When reading a list, mark which models offer a deferred row and file it next to your workload inventory. Anything whose deadline is measured in hours rather than heartbeats is a candidate.

Long context costs the provider something real: attention over a very large prompt costs memory and time that short prompts do not. Some lists reflect this directly — different rates for the same model by context-window size, or surcharges past a threshold. Others bake it into separate SKUs: the standard version and the long-context version, at different rates.

The trap is paying long-context prices by accident. An integration defaulting to the biggest available window “just in case” may be buying the expensive row for traffic that never uses it. Check what context size the requests actually need, check where the tier boundaries sit, and make sure the model id you call maps to the row you think you are paying.

This is also the row most likely to move as techniques improve — a decision made a year ago deserves a re-read.

The free tier is the most honest row on any list, because its purpose is evaluation. Use it that way: run real prompts against the models actually under consideration, measure what you would have paid, and note the rate limits you hit. A free tier tells you nearly everything about the API surface and nothing about production — throughput, priority, and support are all different above the waterline.

Credits are the same instrument with a clock attached: excellent for funding a proper evaluation, terrible as a selection criterion. A large balance with a short expiry manufactures urgency, and urgency is how checklists get skipped. Note the expiry, run the trial at your own pace, and treat the credit as consumed learning rather than a discount on the decision.

The one thing free tiers cannot show is the production bill — free traffic is rarely shaped like production traffic. That translation, your volumes and split against real rates, is a job for the calculator rather than the price list alone.

Three rules, learned from watching comparisons go wrong.

Compare model by model, never blend by blend. An average across a catalog mixes flagship and economy tiers into a number no customer is ever charged. The only honest comparison is the same model — or the same capability tier — on both lists.

Weight by your workload, not by the provider’s defaults. A list that wins on input rate loses if your bill is mostly output; a cheap standard tier is irrelevant if the traffic needs the long-context row. The unit of comparison is your monthly volume split by direction, tier, and cache eligibility — run through both lists.

Date everything. Price lists move, and an undated comparison is a rumour. The pricing calculator exists precisely because this arithmetic is tedious by hand: your volumes in, a model-by-model breakdown out, from the same published rates shown on the model library.

When the spend is small, the price list is a distraction. The difference between two reasonable providers on a modest bill is lunch money; the difference between a clean architecture and a wasteful one is not. Retries nobody noticed, prompts padded with context nobody reads, non-production traffic on production tiers — these dwarf any rate-card optimisation, and none of them appear on a price list.

It is also the wrong tool for the quality question. A cheaper model that fails a fifth of requests costs more per finished task than the expensive one that passes first try, and no amount of rate-card reading tells you which is which. Measure on your workload; buy on the measurement.

Read the price list last, in other words — after the volumes, the shape, and the quality floor are known. Then it is a fifteen-minute exercise instead of a leap of faith, and the calculator does the arithmetic.