On October 7, 2026, Anthropic launched Claude Haiku 5.5 with a headline that is easy to repeat: up to 90% cheaper than Haiku 4.5. The same announcement carries a less cited number: on average, the saving lands around 75%. Both numbers are true. They simply do not answer the same question. It is the same lesson as TOPS and NPU: the number exists, but it does not answer the question you asked.

The difference is not a marketing detail. It is the tokenizer. Haiku 5.5 uses the new tokenizer introduced in Claude 4.7, and the documentation itself says the same text now counts approximately 30% more tokens than on Haiku 4.5. Because the price has a cheap tier up to 100,000 tokens and a tier five times more expensive above that, a prompt that sat comfortably in the cheap tier can cross the line without the text changing by a comma.

This text is an analysis of Anthropic’s public documentation, not a load test. The prices are the published ones; the math is simulation with stated assumptions. The number that matters for your case is the cost per finished task, and it comes only from measurement.

What changed in the table

Haiku 5.5 has two price tiers, measured in millions of tokens (MTok):

What changed in the table
ItemHaiku 4.5Haiku 5.5 up to 100kHaiku 5.5 above 100k
InputUS$1.00US$0.10US$0.50
OutputUS$5.00US$0.50US$2.50
Cache readUS$0.10US$0.01US$0.05
Cache write (5 min)US$1.25US$0.125US$0.625
Cache write (1 h)US$2.00US$0.20US$1.00

The 90% drop applies to the tier up to 100,000 tokens. Above that, the drop is 50%. The 90% cut is not a property of the model; it is a property of one prompt-size tier.

Two other details change the math. The batch discount (Batch API) is 50%, and a cache read costs 10% of the input price. For repetitive loads, the cache can weigh more than the difference between the tiers. For one-pass loads, the prompt size is what rules.

The tokenizer is the part nobody puts in the spreadsheet

The Haiku 5.5 documentation is explicit: it uses the new tokenizer introduced in Claude 4.7, and the same text counts approximately 30% more tokens than on Haiku 4.5. Anthropic’s general models page gives a word ruler that points in the same direction, with one difference: 1 million tokens equals about 555 thousand words on the current tokenizer, against about 750 thousand on the models before it. The ratio 750/555 is 1.35, or about 35% more tokens; the number Anthropic states is “approximately 30%.” To keep the two rulers from mixing, this text uses 30% in the examples and treats 35% as the upper bound of the approximation. If your text is closer to the word ruler, redo the math with 35%.

That means the limit of 100,000 tokens is measured on the new tokenizer. A prompt you measured on Haiku 4.5 at 80,000 tokens can become 104,000 on Haiku 5.5. The text is the same; the price classification changes.

Anthropic says about 90% of requests to Haiku 4.5 had up to 100,000 tokens. The company also states that the average saving lands around 75%. The footnote of the announcement says that math considers the split between the two tiers and the change in the number of tokens Haiku 5.5 uses to finish the same work, but it does not publish the formula. The simplest weighting does not reproduce the number: applying 30% more tokens on both tiers and weighting by 90% and 10% gives about 82% savings, not 75%. The difference suggests factors the note does not quantify, such as the weight of large requests in the total cost, or the ones that cross the boundary because of the tokenizer. It is an Anthropic estimate of the previous model’s average load, not an independent measurement and not a guarantee for your load.

The math, with three scenarios

Let’s use three scenarios with the same structure: input and output, no cache and no batch, to isolate the tokenizer’s effect. The cost is per call.

The math, with three scenarios
ScenarioHaiku 4.5 (input + output)Haiku 5.5 on the new tokenizerTierSaving
A: 40k + 1k, becomes 52k + 1.3kUS$0.045US$0.00585up to 100k87%
B: 80k + 2k, becomes 104k + 2.6kUS$0.090US$0.0585above 100k35%
C: 150k + 5k, becomes 195k + 6.5kUS$0.175US$0.11375above 100k35%

In scenario A, the text stays in the cheap tier and the saving reaches 87%, close to the table’s ceiling of 90%. In scenario B, the same text that was at 80,000 tokens crosses the limit because of the extra 30% and falls into the tier of US$0.50 per million of input. The saving exists, but it is 35%, not 90%. In scenario C, the prompt was already above the limit; the unit cut is 50%, and the tokenizer reduces the effective saving to 35%.

Scenario B, opened up:

  • Haiku 4.5: 80,000 input tokens × US$1.00/MTok = US$0.08; 2,000 of output × US$5.00/MTok = US$0.01; total US$0.09.
  • Haiku 5.5 with 30% more tokens: 104,000 of input × US$0.50/MTok = US$0.052; 2,600 of output × US$2.50/MTok = US$0.0065; total US$0.0585.
  • Saving: (0.09 − 0.0585) / 0.09 = 35%.

If the same text had stayed at 100,000 tokens on the new tokenizer — that is, if the 30% increase had not pushed the prompt into the expensive tier — the cost would be US$0.0113: 100,000 of input × US$0.10/MTok = US$0.01, plus 2,600 of output × US$0.50/MTok = US$0.0013. The saving would be 87.4%. The figure of US$0.009 would appear only if the text had stayed at 80,000 tokens on the old count, which is exactly the error the new tokenizer prevents. The difference between 87% and 35% is not in the model: it is in the prompt’s position relative to the boundary.

Anthropic’s pricing documentation defines the boundary rule. What decides the tier is the prompt size: the request whose prompt goes past 100,000 tokens pays the entire expensive table, input and output, and not only the excess; a prompt of exactly 100,000 tokens still stays in the cheap tier. The prompt size adds up all input tokens, including cache reads and writes, and each request is billed on its own. That is how the scenarios above were calculated. For anyone near the line, the only safe course is to measure the prompt on the new tokenizer and leave a margin. A prompt of 90,000 tokens on Haiku 4.5 can become 117,000 on Haiku 5.5; a 10% margin does not protect.

Update note (October 28, 2026): the version published on October 26, 2026 said Anthropic did not detail how the 100,000-token tier is billed and that, if the charge applied only to the excess, the numbers would change. The pricing documentation, consulted on October 28, 2026, details the rule: the request with a prompt above 100,000 tokens pays the entire expensive table, and cache reads and writes count toward the limit. The scenarios and the math do not change, because they already treated the tier as applying to the whole request. In the same revision, the origin of the word ruler, the explanation of the 75% average, the 1-hour cache write in the table, and the warning about cache below were adjusted.

From the call to the task

Scenario B costs US$0.0585 per call. If 1,000 tasks use one call each, the cost is US$58.50. If 5% fail and are redone, that is 1,050 calls: US$61.43. The cost per accepted task is US$0.0614, not US$0.0585. Across 100,000 tasks, the difference between the two bills is about US$292.

The point is not the number; it is the unit. The bill that decides is the one that divides the total cost — input, output, retries, and cache — by the accepted tasks. A cheap call that fails often can turn out more expensive than an expensive call that gets it right the first time. The same idea of a bill per unit of work appears in the post about the WhatsApp bill with AI.

What the 75% average means

The 75% average is useful for a portfolio decision: “across the set of typical Haiku 4.5 loads, Haiku 5.5 tends to cost about a quarter of the previous one.” It is not useful for deciding whether a specific task should migrate. A task with long output, many retries, or a prompt near the limit can have a much smaller saving; a short, repetitive task can have a saving close to the table ceiling, especially with cache and batch.

There is also the quality effect. Anthropic presents Haiku 5.5 as the most capable small model it has ever launched, but it is still positioned for classification, extraction, routing, summarization, and a subagent role. On tasks that require long reasoning, the price gain can be wiped out by rework. The relevant bill is not “how much 1 million tokens costs.” It is “how much a finished task costs at acceptable quality.” That is what I did in What one multi-agent cycle costs: measure in money, not in tokens.

When Haiku 5.5 tends to pay off

  • High-volume loads and short prompts. Classification, extraction, routing, summarization of passages, and real-time support replies. This is the territory the model was designed for.
  • Subagent of a larger model. Haiku 5.5 runs the small task while Sonnet or Opus plans. The total cost falls because most of the calls are to the cheap model.
  • Cache and batch. If the load repeats the same prefix, a cache read at US$0.01/MTok changes the math. If latency is not critical, the 50% batch discount stacks with the cheap tier. Just do not count on the cache to stay under the boundary: the prefix read from cache counts toward the prompt size.
  • Tasks with short output. Output costs five times the input on Haiku 5.5. A task that generates 10,000 output tokens for 1,000 of input has a cost profile quite different from one that classifies 10,000 tokens and returns a single word.

When the numbers do not add up

  • A prompt that crosses 100,000 tokens. The expensive tier multiplies the input by five. If the text is near the line, the new tokenizer can push it over.
  • Long output. The output price is five times the input price on both tiers (US$0.50 against US$0.10 on the cheap one; US$2.50 against US$0.50 on the expensive one). Long generation is not Haiku’s economical use case.
  • A task that requires complex reasoning. The small model can fail more often, and the retry consumes the saving. Cheap per token can turn out expensive per task.
  • A bill built only on the 90% number. The number is real, but it applies to one tier. The invoice is not an Anthropic weighted average; it is the sum of your calls.

The migration checklist

  1. Measure the tokens on the new tokenizer. Do not reuse the Haiku 4.5 count. Use the provider’s own token-counting tool, run a real sample on Haiku 5.5, and record the size distribution.
  2. Separate input and output. The ratio changes the conclusion. A classification load and a generation load are not comparable.
  3. Count the retries and the failures. Cost per finished task includes what was redone. A cheaper model that fails more often can cost more.
  4. Run a shadow batch. Send the same load to both models, compare quality and cost, and only then migrate.
  5. Leave a margin for the 100,000 boundary. If the prompt is less than 30% short of the limit, treat it as if it were already above.
  6. Consider cache and batch. They can change the math more than the choice between the tiers.
  7. Divide by what was accepted. Total cost divided by the approved tasks, not by the calls made. The logic of measuring what was redone is the same as the harness gates: the number that matters is the one that passed the gate.

The number that remains

Haiku 5.5 is good news for anyone who has volume, short prompts, and a well-measured load. The 90% cut is real, but it is the ceiling of the cheap tier, not the average price of your operation. The 75% average is an Anthropic estimate of the previous model’s load, not a promise for your case.

The bill that decides is simple to state and tedious to do: cost per finished task, with tokens measured on the new tokenizer, retries counted, and quality compared. Whoever skips that step is left with the number from the ad. Whoever does it sometimes finds that the effective saving gets close to the 90% ceiling; sometimes, that it lands at 35%.

Sources