Home / LLM API Pricing

LLM API pricing, explained end to end

This page is the whole subject in one place: how token billing works, what drives the number on your invoice, what every tracked model charges, and where the real savings are. Each section hands off to a page that goes deeper on that one question.

How token billing works

Every provider prices the same two things. Input tokens are everything you send: the system prompt, the conversation history, retrieved documents, tool definitions, the user's message. Output tokens are what the model generates. Both are billed per million, and the rates are almost never the same.

A token is roughly four characters of English, or about 1.3 tokens per word, which puts a million tokens at around 750,000 words. Code, non-English text and heavily formatted content all tokenise less efficiently, sometimes much less, so a rule of thumb is fine for a first estimate and a poor basis for a budget. Different model families also use different tokenisers, meaning identical text can produce counts 10-35% apart depending on where you send it.

The arithmetic itself is simple: cost = (input ÷ 1,000,000 × input rate) + (output ÷ 1,000,000 × output rate). Everything difficult about LLM cost estimation is getting the token counts right, not the multiplication.

Why output costs more than input

Across the models tracked here the median output rate is 4.0x the input rate. The reason is mechanical rather than commercial: an entire prompt can be processed in one parallel pass, while each output token requires its own sequential forward pass through the model. You are paying for a fundamentally more expensive operation.

The consequence matters more than the fact. Because the two rates differ so much, the shape of your workload decides which model is cheapest for you, and a table ranked on input price alone will mislead you. A retrieval workload reading 20,000 tokens and writing 300 is priced almost entirely on the input rate. A drafting tool reading 500 and writing 2,000 is priced almost entirely on the output rate, where the spread across models is 2250x. Work out your input-to-output ratio before you compare anything.

What the market actually charges

Here is the entry tier from every provider tracked, which is the most useful single view for high-volume work: when a task is simple and the volume is large, the cheap tier is usually where it should run, and the only question is whose.

That is the floor of each lineup, not a summary of it. Providers span an enormous internal range, and the gap between a vendor's own cheapest and most expensive model is usually wider than the gap between two vendors at the same tier. For the full ranking of every model, the every model compared on price puts them in one sorted table; for the market structure behind the numbers, the our pricing market report reports the medians and spreads.

The four things that change your bill

Once you know the rates, almost all real cost control comes down to four levers, roughly in order of how much they move the number.

1. Prompt caching

27 of the 60 models here discount input tokens the provider has already processed for you, at a median of about 90% off. It applies to the prefix of a request only, so ordering decides whether it works at all: anything that varies must come after everything that stays the same. Full mechanics in the caching repeated context guide.

2. Batch processing

18 models offer roughly 50% off both input and output for asynchronous work. Unlike caching it discounts output too, which makes it the larger lever for generation-heavy jobs. The constraint is latency, not eligibility: if nobody is waiting on the answer, it qualifies. See asynchronous batch discounts.

3. Output length

Output is the expensive half of every bill, so capping it is the most direct lever available and the one that needs no provider feature at all. A model that answers in 200 tokens instead of 800 cuts the expensive side of the invoice by three quarters.

4. Model tier

The obvious lever, and the one to reach for last, because it is the only one carrying quality risk. A cheaper model that needs two attempts, or that produces output someone has to correct, costs more than the model that got it right first time, and none of that shows up on the API bill. Read matching model tier to workload before making the swap, and price it with the model switching savings calculator.

Estimating before you build

The order that works: estimate token counts from a real sample, price a single call, multiply by expected volume, then check the per-user figure against what you charge. Doing it in that order catches unit economics that do not work while you can still change the design, rather than after launch when the only remaining lever is a worse model.

Watch the calls-per-user number especially. Cost scales linearly with it and it is the variable most often underestimated: an agent loop averaging six model calls per user action costs six times what a single call does, and retries, reranking passes and self-critique steps multiply it further without appearing in any per-call estimate. The our calculator suite cover each step of that sequence.

What list prices leave out

Everything on this site is the standard public list price for a provider's own API. Four things sit outside that and can move your real cost substantially: enterprise and committed-use discounts, which are negotiated and not public; long-context surcharges, where several providers re-bill an entire request at a higher rate past a threshold rather than charging only for the excess; regional pricing, where the same model can differ by 60-70% between endpoints; and per-request fees on search-grounded models, which can exceed the token cost on short queries.

Each of those is flagged on the model and pricing by provider pages where it applies, because a rate card that hides them is worse than no rate card.

LLM API pricing: common questions