Does a lower price per million tokens mean a cheaper AI model?

No. The price is per token, and a token is not a fixed quantity of text. Anthropic's pricing page states that Claude 4.7 and later models "use a newer tokenizer" and that "this tokenizer produces approximately 30% more tokens for the same text". The per-token price went down. The count went up.

Nobody buys tokens. They send a contract, a tool catalogue, a support thread, a repository, a conversation already forty turns deep, and the bill arrives in a unit the vendor defines.

Why does the same text cost a different number of tokens on each model?

Because every vendor trains its own tokenizer, and vendors replace them between versions. The Claude Opus 5.5 migration guide says the tokenizer introduced with Opus 4.7, which Opus 5.5 also uses, "might use roughly 1x to 1.35x as many tokens when processing text compared to models before Claude Opus 4.7". The token counting docs add the operational instruction: when migrating, "don't reuse token counts measured on the older model to estimate costs or context window fit".

The cleanest proof is on the pricing page itself, where Anthropic publishes the token cost of a fixed tool definition twice, once per tokenizer.

Identical tool definition	Claude 4.6 and earlier	Claude 4.7 and later	Ratio
Bash tool	244 tokens	325 tokens	1.33x
text_editor_20250728	745 tokens	974 tokens	1.31x

One string, two numbers, printed four rows apart on the same page. Checked by Unity Horizon on 3 November 2026.

What does a 20% price cut buy when the counter has changed?

Work it through on the vendor's published figures. Take whatever text counts as one million tokens on Claude Sonnet 4.6, the last Sonnet on the previous tokenizer, and send that identical text to each model.

Model	Tokenizer	List input price	Tokens for that text	What that text costs
Claude Opus 4.6	previous	$5 / MTok	1,000,000	$5.00
Claude Opus 5.5	current	$4 / MTok	1,000,000 to 1,350,000	$4.00 to $5.40
Claude Sonnet 4.6	previous	$3 / MTok	1,000,000	$3.00
Claude Sonnet 5.5	current	$2 / MTok	1,000,000 to 1,350,000	$2.00 to $2.70

Opus 5.5 lists 20% below Opus 4.6. On the same text it arrives somewhere between 20% cheaper and 8% dearer, and the list price alone cannot tell you which end you are at. Sonnet 5.5's headline is a 33% cut. The honest range is 10% to 33%.

None of this is hidden. It is on the pricing page, two screens below the table everyone screenshots.

Where does a 30% counting change become a 400% price change?

At a threshold. Claude Haiku 5.5 is priced by prompt length: up to 100,000 tokens it bills $0.10 per million input and $0.50 output, and over 100,000 tokens it bills $0.50 and $2.50. Five times, both sides. The pricing page adds that a request's prompt length "counts all of its input tokens, including cache reads and cache writes", and that each request is priced on its own, so part of the prompt being a cache hit does not save you.

Now take a prompt you sized at 80,000 tokens against Claude Sonnet 4.6. Under the current tokenizer the same prompt can count up to 108,000. It crosses, and then every token in it bills at five times the rate you budgeted, cache reads included. The text did not grow. The ruler did.

What else in your system is denominated in tokens?

Your throughput. The rate limits page says limits are "measured in requests per minute (RPM), input tokens per minute (ITPM), and output tokens per minute (OTPM) for each model class". A count a third fatter is a third less text per minute under an unchanged ceiling. We wrote about how many AI agents you can run at once before you hit a rate limit and found caching was the lever worth pulling. Same arithmetic, read from the other end.

Your compaction trigger too. The migration guide says to update max_tokens "to account for the updated tokenization, including compaction triggers", and an agent set to compact at 150,000 tokens now reaches that point about a quarter earlier in the conversation. Summaries land sooner. Detail the model used to still have in front of it is gone sooner. Nobody filed a ticket, because nothing broke.

And every client-side estimator that divides characters by four. The same guide says to re-test "any code path that estimates tokens client-side or assumes a fixed token-to-character ratio".

Context window fit is the one thing here that got easier. Claude 4.6 and later models other than Haiku 5.5 carry the full 1M token window at standard pricing, so a prompt 30% fatter than you planned still has somewhere to go.

How do you compare two models on cost without guessing?

Count your own prompt on both. The token counting endpoint accepts the same body as a message, system prompt and tool definitions included, and the docs spell out the procedure: "count the same request twice, once with your current model and once with the model you plan to move to, and compare the two input_tokens values". The endpoint is free. Its rate limit sits apart from message creation, so the measurement does not eat the capacity being measured.

Then multiply each count by that model's list price. That product is the comparable number.

The cross-vendor version of this exists. In April 2026 TensorZero pushed identical inputs through each provider's own counting API and published the ratios. Their corpus was the Iliad for prose, a 2 million character OpenAPI spec rendered as JSON and again as YAML, and 100 generated tool definitions. Normalised to gpt-5.4, claude-opus-4-7 counted 1.57x on text and 2.65x on tool schemas. A 2x gap in list price came out as a 5.3x gap in effective price on tool-heavy work. Those ratios are seven months old and every model in them is a generation back. The method survives the models, and the corpus is public, so anyone can rerun it on the current lineup.

Who does this arrangement suit, and who pays for it?

A unit the buyer cannot audit without making an API call suits the vendor who publishes the list. It costs the procurement team comparing two numbers in a spreadsheet. The pricing roundups that rank thirty models by sticker and count nothing can keep ranking.

The teams hit hardest are the ones whose context is structured rather than prose: tool schemas, JSON payloads, source code, YAML config, accessibility trees out of a browser tool. In TensorZero's April run the tool-definition column was the widest in the table at 2.65x, and an agent's context is mostly tool definitions and the results they return. A chat product sending plain paragraphs barely notices. A forty-tool agent pays the full spread on every turn.

Our own post on how many tools an AI agent can have priced a 77,200-token catalogue at about four cents a cached turn on Claude Opus 5. That count was taken under the current tokenizer, so it holds for Opus 5.5 and does not transfer backwards. The $3.75 we have quoted since August for a 500,000 input and 50,000 output run on Opus 5 is $3.00 on Opus 5.5, on identical counts. One of our anchors moved because the price moved. The other would move because the counter moved.

We have not measured the 30% on our own prompts. Anthropic publishes it as an approximation and says the exact increase depends on content and workload shape, and those two tool-definition rows are the only identical-input pair we found a vendor publishing. TensorZero's corpus covers English prose, JSON, YAML and tool schemas, and covers no other language at all. We built askHermis. It answers guest messages in 38 or more languages, and we do not know what the current tokenizers do to a Greek one. If someone has counted that, we would like the number.

Counting your own prompts against the model you are about to call takes half an hour, and it is where our agentic AI work starts on any migration. So here is the question worth answering before Monday. How many tokens is your production system prompt on the model you are calling today, and who measured it there?