LLM API pricing compared, and how to read it

Every provider publishes a dollars-per-million-tokens figure, and comparing those figures is the least useful thing you can do with them. The headline input rate decides a minority of real bills.

Three rates, not one

Each model has at least three prices, and they move independently:

• Input. What you pay for the prompt. Processed in a single parallel pass, which is why it is the cheapest of the three.
• Output. Typically four to six times input, because generation runs one token at a time with a full pass over the model for each.
• Cached input. Commonly a tenth of the base input rate, for prompt content the provider has already processed. On repetitive workloads this is the rate most of your input actually bills at.

A model that looks 40% cheaper on input can be more expensive in production if its output rate is higher and your workload generates a lot of text. Every rate for the models tracked here is in the model price table, each with the provider URL it was read from and the date it was read.

Your input-to-output ratio decides the winner

This is the single most useful thing to know about your own workload, and most teams have never measured it.

• Input-heavy — summarisation, classification, extraction, retrieval-augmented answering. Often 20:1 or higher. Input rate and cached rate dominate; output pricing is nearly irrelevant.
• Output-heavy — content generation, code writing, translation, long-form drafting. Can approach 1:1. Output rate dominates completely, and the ranking from the input-heavy case frequently inverts.

Measure yours from production logs, then put both numbers into the cost calculator. The ranking it produces for your ratio is the only ranking that matters, and it will not match a generic "cheapest models" list.

The tokenizer is part of the price

A rate per million tokens is meaningless without knowing how many tokens your text becomes — and that is model-dependent, because each provider trains its own vocabulary.

The effect is large enough to reverse a comparison. Anthropic states that the tokenizer introduced with Claude 4.7 produces roughly 30% more tokens for the same input than its predecessor. A model priced 20% below a competitor but tokenizing 30% denser is more expensive per page of text, not less — and no price table shows you that, because price tables compare rates rather than costs.

The token counter counts one text against every model at once for precisely this reason, and marks which counts are exact and which are estimates. Not every provider publishes a tokenizer that can run in a browser, and pretending otherwise would be the easy, dishonest option — the methodology page sets out where each figure comes from.

What price tables leave out

• Reasoning tokens. Reasoning models bill their internal thinking as output even though you never see it. Real output counts can be several times the visible answer, which makes the headline output rate materially misleading for these models.
• Batch discounts. Roughly 50% off for asynchronous processing with a latency budget in hours. Free money on any workload that is not blocking a user, and almost never reflected in comparisons.
• Regional and residency premiums. Pinning inference to a specific geography commonly adds around 10%.
• Server-side tool charges. Web search and similar are billed per call on top of tokens.
• Introductory pricing. Promotional rates expire. Where a model tracked here has one, the expiry is noted on its row in the price table rather than left as a surprise.

A sane way to choose

1. Measure a real request. Median input tokens, median output tokens, and how much of the input is a stable prefix. Guesses here are wrong in the expensive direction.
2. Shortlist on capability, not price. Three or four models that can actually do the task. Price differences are irrelevant among models that fail.
3. Price the shortlist at your real ratio and volume in the cost calculator, with the cache slider set to your actual cacheable share.
4. Check the context fit. A cheap model is no bargain if your context does not fit — the context window calculator settles that in seconds.
5. Then optimise the workload, which usually beats switching models. See how to reduce LLM API costs — the first three items there routinely return more than any provider change.

One closing caution. Prices change without notice, and a comparison written six months ago is decoration rather than information. Anything you read on this subject, here included, should carry a date and a source link — and if it does not, treat the numbers as approximate at best.