Why 'price per million tokens' lies about your AI bill

The supermarket unit-price problem

Here is the easiest analogy. Imagine you are at the supermarket comparing two packs of porridge oats. One says £1.50, the other says £1.80. Obviously you grab the cheaper one. Then you get home and realise the £1.50 pack was 500 grams and the £1.80 pack was 1 kilogram. Suddenly the 'more expensive' option is the better deal by a country mile.

That is why every UK supermarket is legally required to print a unit price (the cost per 100g, per litre, per kilo) next to the sticker. It is the only number that lets you compare like for like.

LLM pricing does not have that. The 'unit' is a token, but every provider defines a token slightly differently. So the per million token price is the sticker on the front of the pack, not the price per kilo.

What on earth is a token, in 30 seconds

A tokenizer is the bit of code that chops your text into the chunks a model actually sees. It is not words, and it is not letters. It is something in between, decided by the way the provider trained their model.

One token can be a whole short word, a chunk of a longer word, a piece of punctuation, or even a few characters of code or JSON. The same sentence can become 18 tokens on one provider and 27 on another, just because their tokenizers slice the language differently.

You can mostly ignore the mechanics. What you cannot ignore is the consequence: send the same prompt to two providers, you get billed for two different token counts.

How big is the gap, really?

It depends entirely on what you are sending. Plain English is the kindest content; the tokenizers are reasonably close. Structured stuff like JSON, YAML and tool definitions is where the gap opens up.

An analysis by TensorZero put some numbers on this. Using OpenAI's tokenizer as a 1.00x baseline:

• Claude Opus 4.7 produces 1.57x more tokens on plain text, 1.53x on YAML, 1.70x on JSON, and 2.65x on tool definitions.
• Gemini 3.1 Pro produces 1.06x on text, 1.18x on YAML, 1.11x on JSON, and 1.82x on tools.

So for an English chat conversation, the gap is small enough that you can almost ignore it. For a coding agent that is constantly passing tool schemas and JSON back and forth, the gap is huge.

A simple mental model for comparing properly

You do not need a spreadsheet. You need two numbers in your head.

Step one: figure out what kind of content you actually send. Mostly chat with humans? Plain English. Building an agent? Tools, JSON and code. Summarising documents? Probably mostly prose, but check.

Step two: apply a rough multiplier. For plain English, treat the OpenAI sticker price as roughly real, and tack on around 50 to 60 percent for Claude. For tool heavy or JSON heavy work, the gap can easily double or treble. Gemini sits in the middle for most things.

So next time you see 'Model X is half the price of Model Y' in a marketing comparison, ask the question that should always be asked when somebody is comparing prices: half the price of what?

The other hidden costs the sticker price does not mention

Even after you correct for tokenizer overhead, there are at least four more things the per million tokens number quietly leaves off:

• Output tokens cost more than input tokens. On most providers, the model generating text costs 3 to 5 times what feeding text in costs. If your app produces long responses, the input side of the price tag is the smaller half of the bill.
• Prompt caching changes the maths. If you reuse the same big system prompt across thousands of requests, most providers now let you cache it for a steep discount on subsequent reads. That can knock 70 to 90 percent off the input cost, but only if you are set up to use it. Trimming the prompt itself is another lever: the 'caveman' prompt trick shrinks the token count on the same principle.
• Long context tiers. Several providers charge different rates once your context window crosses a threshold (usually 128k or 200k tokens). Cheap below the line, suddenly not below the line above it.
• Thinking tokens. Reasoning models bill you for the internal 'thinking' tokens you never see in the output. On a tricky problem, that hidden working out can be the bulk of the cost.

TensorZero's analysis cheerfully points out that their 5.3x figure is just the input token side. Once you stack the rest on, real workload costs can drift even further from the menu price.

Can Anthropic's new spending reports tell you what your AI bill is buying?

Everything above is about predicting the bill before it arrives. The harder question comes afterwards: what did the money actually get you? On 28 October 2026, Anthropic (the San Francisco AI lab that makes the Claude models) launched a set of reports for its business customers aimed squarely at that question, as TechCrunch reported.

The reports cover Claude Code, Anthropic's coding agent that reads and edits a developer's files from the terminal. A manager picks a date range and sees four things for a team: what it worked on, what it produced, what that cost, and where its workflows broke down. The figures come from Anthropic's own usage analytics plus employee surveys, and each report adds recommendations for getting better results. Alongside them, Anthropic added pooled group budgets, so a team draws on one shared pot of token spend rather than each person sitting under a separate cap. Anthropic says it won't use the reporting data to train its models by default.

The timing is no accident. The same TechCrunch piece cited a report from Jellyfish, a company that sells engineering analytics software, finding that spending on agentic coding tools has grown about tenfold since the start of 2026 and now equals roughly 2% of total engineering cost. Two percent sounds small. Ten times growth in a single year is the part most finance directors did not budget for.

Why is it so hard to measure what AI spend buys?

Cost is the easy column. Tokens are metered, so the bill is exact to the penny. Output is the slippery one, for three reasons:

• The unit of work is fuzzy. A seat licence or a million tokens buys attempts, not results. One session ships a feature; another burns the same tokens going round in circles on a bug.
• Counting things is not the same as value. Lines of code, commits and merged changes are easy to count and easy to inflate. More code is not automatically better code, and some of the most useful work is deleting it.
• There is no control group. You rarely know how long the same task would have taken without the tool, so any 'hours saved' figure rests on an estimate or a survey answer.

What can vendor-supplied productivity numbers prove?

Be clear-eyed about who is marking the homework. A report built by the company selling the tokens is solid on the things it measures directly: where the spend went, which teams use the tool most, which sessions were expensive. Those numbers come straight from the meter, and they are as reliable as your invoice.

The productivity side is a different animal. Survey answers about time saved are self-reported, and people who like a tool tend to rate it generously. Activity counts show that work happened, not that it was worth doing. And the vendor has an obvious interest in the dashboard looking healthy at renewal time. None of that makes the reports useless. It makes them a starting point rather than a verdict.

The sensible approach: treat the cost and usage data as fact, treat the productivity estimates as a claim to test, and check them against numbers you already track yourself, such as how often you ship releases, how many bugs reach customers, or how long tickets sit open. If those move the right way, the spend is earning its keep. If the vendor's dashboard says you are flying and your own numbers have not budged, believe your own numbers.

What this means if you are just trying to pick a model

None of this means 'always go with whoever has the most efficient tokenizer'. The most efficient tokenizer for your workload might still be attached to a worse model for your task, or a slower one, or one with a more painful rate limit.

The point is narrower. Sticker price is a starting point, not an answer. If you are picking between two providers and they are within a factor of two on the menu, the tokenizer alone can flip which one is actually cheaper. So spend a few minutes with your real prompts before committing, and if you are choosing a consumer assistant rather than an API, our ChatGPT vs Claude vs Gemini comparison weighs more than price.

The cheapest cup of coffee, like the cheapest API call, is the one that gives you what you actually needed without the side of regret.