What AI API pricing doesn't tell you

You are about to build on an LLM API, so you check the pricing page. Every provider gives you the same thing: a table of dollars per million tokens, cheapest model at the bottom, flagship at the top. It is the first number you look at, and it feels like the number that decides your bill.

It is not. The price per token tells you what a token costs, not what an answer costs, and definitely not whether the cheap model gives you an answer you can ship. Those are different questions, and the pricing table cannot answer either one. Two real runs show the gap.

The sticker prices, for reference

Here is roughly what the current API lineups cost, in dollars per million tokens, so the rest of this has a baseline.

Standard per-token prices across current API models, cheapest to dearest within each provider. Verified against the OpenAI, Anthropic, Together, and Grok pricing pages, October 2026. The spread from the cheapest model to the flagship is roughly 100-fold.

[1] Batch (asynchronous jobs, results returned within a window) is billed at exactly half the standard input and output rate on OpenAI and Anthropic. Together offers a batch tier on its serverless models. Grok accepts batch requests but gives no discount on Grok 4.7, so there is no batch saving to show. [2] Cache read bills tokens you resend (a reused system prompt or document) at a fraction of the standard input rate, typically around a tenth and as little as a fortieth on some models. Writing to the cache costs slightly more than standard input.

Notice the table already needs two footnotes to be honest, and those footnotes move the bill more than the headline numbers do. A model that looks twice as expensive per token can be the cheaper one in practice if your workload reuses a long system prompt (cache) or runs offline (batch). The standard per-token price is the sticker, not the bill. And even that is still only half the question, because the spread is wide enough that model choice looks like a pure cost lever, where you pick the cheapest row and pay the least. That is the conclusion the table invites, and it is wrong often enough to matter. A token price only becomes a bill once you know how many tokens a real task takes and whether the answer is good enough to use, and neither of those is on the page.

Run one, where the cheapest model wins and the dear one wastes your money

Take a real task. A customer writes in about a double charge, and your support assistant has to reply under your refund policy.

Five models answered, each scored against a gold-standard reply, with the cost of that answer recorded alongside the score.

Cheapest models at the top of the quality ranking, the most expensive model at the bottom.

Read the cost column against the quality column. DeepSeek V4 Flash scored highest at 92, for about a hundredth of a cent. GPT-4o, the most expensive model in the group at roughly 25 times the cost of GPT-4o Mini, scored lowest at 72. On this task the pricing table pointed you exactly the wrong way. Pay more and you got a worse answer, because a warm, concise refund reply does not need a flagship model, and the flagship’s extra length and formality counted against it.

If this were the only task you ran, the lesson would be “buy cheap.” That is the wrong lesson too.

Run two, where the same five models flip and the cheap ones fail

Change the task. Same five models, a different job, one that needs the model to reason rather than write.

Scored the same way, against that correct answer, the result inverts completely.

The most expensive model is now the only one that gets it right. The cheap models that won the first task all fail this one.

GPT-4o, the model that scored worst and wasted your money on the support reply, is the only one of the group that answers this correctly. The cheap models that topped the first table all get the math wrong here. GPT-4o Mini and Claude Haiku both miscount the upgrade timing; GPT-4.1 Nano invents an extra month at the old price. Each would have told your customer the wrong total. On this task the cheap row on the pricing page is not a saving, it is a wrong answer you would have shipped.

(DeepSeek is absent from this table because it took over a minute to respond and its score did not complete, which is its own kind of answer about fitness for a live task.)

The same five models, ordered cheapest to most expensive. Green is the easy task, blue is the hard one. Neither price nor one task’s result predicts the other.

The number the pricing page can’t show you

Put the two runs together and the point is hard to miss. The same five models, ranked by the same pricing table, inverted between two perfectly ordinary tasks. On one, the cheapest was best and the priciest was waste. On the other, the cheapest failed and only the priciest was safe to ship.

What actually decides the right model is cost per acceptable answer, meaning the cheapest model that still clears the quality bar your task sets. That is a number you can only get by running your own task across the models and scoring the results, because it depends on your prompt, your data, and how hard your task actually is. The support reply and the billing question came out opposite, and nothing on any pricing page would have told you that in advance.

And the answer does not stay put

Even once you have measured and picked the cheapest model that clears your bar, that answer has a shelf life. Providers change these models and their prices constantly. In a single recent stretch, OpenAI cut one model’s price by 80 percent, trimmed another, and launched a flagship at more than double the rate of the one it replaced. Any of those moves can change which model is your cheapest acceptable option, and none of them arrives as a notification.

So the real work behind “which model is cheapest” is not reading a table once. It is measuring the models on your own task to find the cheapest one that is actually good enough, and then re-checking it on a schedule so a price cut or a quiet model update does not leave you overpaying, or shipping worse answers, without knowing. The pricing page is where you start. It is nowhere near where the decision ends.

How to run that measurement, and read cost against quality on your own prompts, is covered in how to evaluate LLM output. Keeping the answer current as the models move is how to monitor LLM quality over time.