I checked five LLM cost calculators against the published rates

What happened

On 3 August 2026 I took five free LLM cost calculators and checked their Anthropic prices against Anthropic's published pricing, and their method against what the tokenizer actually does.

The published rates, for reference: Claude Opus 4.5 through Opus 5 are $5 per million input tokens and $25 output. Claude Sonnet 4.6 is $3/$15. Claude Haiku 4.5 is $1/$5. Claude Opus 4.1 and Opus 4, both now deprecated, are $15/$75.

That last line is the one to hold onto.

The price errors

aitokencalculator.com was correct on every Anthropic model I checked. Opus 4.8 and 4.7 at $5/$25, Sonnet 4.6 at $3/$15, Haiku 4.5 at $1/$5, and Opus 4.1 correctly priced at $15/$75 and explicitly labelled legacy. Credit where it is due.

cognio.so prices Claude Opus 4.6 at $15/$75. The actual rate is $5/$25, so the tool overstates the cost of the flagship by three times. The error is repeated in the page's own FAQ, which states that Opus 4.6 "costs $15.00". It also prices Haiku 4.5 at $0.80/$4, which is Haiku 3.5's rate.

ecorpit.com prices Claude Opus 4.8 at $15/$75, the same threefold overstatement, and builds analysis on top of it: the article presents a "12x spread" between GPT-5 and Opus as a headline insight, when the actual spread is a quarter of that. It also puts Haiku 4.5 at $0.80/$4. Notably it prices Claude Fable 5 correctly at $10/$50 while describing it as having launched the day before, so this is not a tool with an old dataset.

tokencalculator.com is mostly right and fails in a more interesting way. Opus 5, 4.8, 4.7 and 4.5 are all correctly at $5/$25. Opus 4.6 alone is listed at $15/$75, and its one-million-context variant at $18/$90, a figure with no basis in the published rates at all. The same tool carries two rows for Haiku 4.5 under different date stamps, one at the correct $1/$5 and one at $0.80/$4. Both appear in the dropdown. Whichever you scroll to first is the answer you get.

Five calculators against the published rates, 3 August 2026

Tool	Flagship Opus price shown	Correct?	Token counting method
aitokencalculator.com	$5 / $25	Correct on every model checked	Character count divided by four, stated
cognio.so	$15 / $75 for Opus 4.6	3x overstated	Roughly one token per 3.5 characters, stated
ecorpit.com	$15 / $75 for Opus 4.8	3x overstated	Claims a per-model WebAssembly tokenizer including an Anthropic one
tokencalculator.com	$5 / $25, except Opus 4.6 at $15 / $75	Inconsistent within the same tool	Not stated
token-counter.dev	Not priced	n/a	tiktoken, an OpenAI tokenizer, in WebAssembly

What a threefold price error does to a business case

Published rate ($5/$25)30 USD

cognio.so and ecorpit.com ($15/$75)90 USD

Why does it matter?

Notice the number that keeps appearing: $15/$75. That is not a random error. It is the correct price for Opus 4.1 and Opus 4, and it was the correct price for the Opus line generally until Anthropic cut it to $5/$25 at Opus 4.5.

So these are not tools with stale data. They are tools where a new model was added by copying the previous flagship's row, and nobody checked that the price had moved. tokencalculator.com proves the point: it cannot be stale, because it has Opus 4.5 right and Opus 4.6 wrong, and 4.5 is the older model.

That distinction matters for how much you can trust a fix. A stale dataset is repaired by a refresh. A miscopied row is repaired only when a human notices, and nothing in the interface will ever draw attention to it. The number is not implausible; it was true eighteen months ago.

A threefold overstatement on the flagship is not a rounding error in a business case. It is the difference between a workload that justifies Opus and one that gets routed to Sonnet on cost grounds that do not exist.

The error all five share

The price errors are the visible half, and some tools get them right. There is a second error, and every one of the five has it.

Claude 4.7 and later use a new tokenizer that produces approximately 30% more tokens for the same text. Sonnet 4.6 and earlier use the previous one. This is documented by Anthropic.

None of the five mentions it. More to the point, their counting methods cannot accommodate it:

• aitokencalculator.com states that it divides character count by four, and describes its token counts as OpenAI-accurate, which is at least honest scoping.
• cognio.so estimates Claude at roughly one token per 3.5 characters, and says so.
• token-counter.dev counts with tiktoken, an OpenAI tokenizer, in WebAssembly.
• ecorpit.com claims it "runs the actual tokenizer for each model in your browser via WebAssembly" and lists an "Anthropic tokenizer" in its comparison table. Anthropic publishes no tokenizer. Whatever that tool runs for Claude, it is not the model's tokenizer, and the claim is the only one of the five that is not merely imprecise but describes something that does not exist.

A fixed character divisor cannot represent a tokenizer change, so on Opus 4.7, 4.8 and Opus 5, all five under-count, by roughly thirty per cent on prose and more on code. A tool can therefore have every published price exactly right and still tell you a number that is a third too low, which is the case for the one tool that got the pricing right.

What to do about it

• Check the flagship price by hand, once. Open the vendor's pricing page and confirm the model you are actually planning to use. It takes a minute and it is the single figure most likely to be wrong.
• Be suspicious of $15/$75 specifically. For any current Claude Opus model it is the previous generation's price and it is three times too high.
• Do not price a business case from a character divisor. For Claude, use the count_tokens API endpoint with your own representative prompts. For OpenAI models the tokenizers are open source and run locally.
• Measure your own tokenizer delta rather than applying thirty per cent. The documented figure is an approximation across content types, and code is affected considerably more than prose.
• Treat these tools as what they are. They are fine for an order-of-magnitude comparison between model tiers. They are not a source for a procurement decision, and none of them claims to be.