The Ten-Cent Haiku

TL;DR.

Anthropic released Claude Haiku 5.5 on October 7. The headline price is $0.10 per million input tokens and $0.50 per million output tokens, 90% below Haiku 4.5's $1 and $5, and level with OpenAI's GPT-6 Luna. Anthropic says the average workload will cost about 75% less than on Haiku 4.5.

The gap between 90% and 75% is the fine print, and it has three parts:

• A 100K line. Prompts over 100,000 tokens pay $0.50 and $2.50, five times the short rate. A 99K prompt with 1,000 output tokens costs $0.0104. A 101K prompt costs $0.0530.
• A new tokenizer. Haiku 5.5 uses the tokenizer of Sonnet 5.5 and Opus 5.5, which Anthropic says uses slightly more tokens per task than Haiku 4.5. DataCamp's launch review measured about 30% more for the same text.
• Effort, defaulting to medium. Haiku 5.5 is the first Haiku with an effort setting. Thinking tokens bill as output, and the default is not the setting behind the best benchmark numbers.

None of these makes the launch less important. It makes it more important. At $0.10, trying the cheap model first costs about 2.5% of an Opus 5.5 call on a typical request, down from about 19% with Haiku 4.5. The cost of a wrong guess has collapsed. What's left is knowing which requests Haiku 5.5 will finish correctly, and keeping them under 100K.

This post covers the pricing, the three catches with worked numbers, what the price drop does to routing math, and a Python tutorial that measures all of it on your own traffic before you switch.

Prices are Anthropic's list prices as published on October 7, 2026. Benchmark figures are vendor-reported. All cost examples are illustrative, not Nadir customer data.

What shipped.

Haiku 5.5 has a 1M-token context window and up to 128K output tokens. It is on the Claude Platform, AWS, Google Cloud and Microsoft Azure under the model ID claude-haiku-5-5. The Batch API takes another 50% off. Anthropic also cut Sonnet 5.5 cache reads from $0.20 to $0.10 in the same announcement.

The benchmark jump over Haiku 4.5 is large. On Anthropic's table, Haiku 5.5 scores 72.4% on OSWorld 2.1 (offline subset) against 15.7% for Haiku 4.5 and 48.9% for GPT-6 Luna, and 39.2% on Terminal-Bench 4.0 against 0.0% and 16.4%. Sonnet 5.5 is still well ahead on agentic coding at 70.6% on Terminal-Bench, which is why Anthropic positions Haiku for high-volume work: extraction, classification, summaries and sub-agents, with Sonnet and Opus kept for demanding coding.

Catch one: the 100K line.

Anthropic prices Haiku 5.5 by prompt length. We read the table the way long-context tiers usually work elsewhere: once a prompt is over 100,000 tokens, the whole request, output included, bills at the higher rate. That reading produces a step, not a slope. Going from 99K to 101K adds 2% more prompt and multiplies the bill by 5.1x. Anthropic's materials don't say how cached tokens count toward the line, so check your first invoice against your own logs. We assume here that they count.

Anthropic says about 90% of Haiku 4.5 requests were under 100K, so most traffic never sees the higher rate. The 10% that do are not random. They are the long-document jobs, the RAG calls with too many chunks, and above all agent sessions, which start small and grow every turn.

Take an agent that starts with 20K tokens of system prompt and tools, adds 5K per turn of tool results and history, and writes 1K tokens per turn, with the prefix cached. For 17 turns it costs about $0.002 a turn. At turn 18 the context passes 100K and every turn after costs $0.011 to $0.016. The 40-turn session comes to $0.338. Priced at the short rate throughout, it would be $0.092. Compacting the context back to 30K whenever it reaches 95K, including the cost of the summary call, brings it to $0.095.

That's a 3.7x difference from one design choice. We've seen the same shape on Grok's 200K line and GPT-5.6 Codex's 272K line. The fix is the same too: give long-running agents a context budget below the line, and treat compaction as a pricing decision, not only a quality one. Compaction has its own cache cost, and at Haiku prices the summary call is cheap enough that it usually wins.

Catch two: the tokenizer.

A price per token only means something next to a token count. Haiku 5.5 moved to the tokenizer used by Sonnet 5.5 and Opus 5.5. Anthropic's footnote says the 75% average already accounts for the extra tokens. DataCamp puts the increase at about 30% for the same text.

Here's what that does to the 90% headline, for a request that is 3,000 input and 800 output tokens on the new tokenizer:

So the short-prompt saving is 87 to 90% depending on your text, before effort. It's still a large cut, and the gap is the reason to re-count your own tokens instead of trusting a per-token ratio. One useful side effect: since Haiku 5.5 now shares a tokenizer with Sonnet 5.5 and Opus 5.5, a request should count about the same on all three, which makes routing between them easier to price.

Catch three: effort.

Haiku 5.5 takes an effort setting from low to max, and the API default is medium. Higher effort means more thinking, and thinking tokens bill as output.

The setting matters for quality. VentureBeat's reading of Anthropic's charts puts Terminal-Bench 4.0 at about 39% at maximum effort and about 20% at the default. If you take the headline score and run the default, you may be buying a different model than the one you benchmarked.

The setting matters less for cost than it would on a bigger model, because Haiku 5.5's output is so cheap:

Add 6,000 thinking tokens to every request and Haiku 5.5 costs $3.70 per 1,000 requests, still less than Haiku 4.5 with no thinking and about a quarter of Sonnet 5.5 before Sonnet's own thinking. The thinking counts used here are assumptions to show the scale; measure yours with the tutorial below. The point is that model and effort are now one decision with two dials. "Haiku 5.5 at high, or Sonnet 5.5 at low?" is a real question for a lot of traffic, and the answer depends on the task, not the price sheet. We showed in Cheaper on Paper how a model that thinks more can cost more than one with a higher list price. At these prices that's unlikely against Sonnet, but likely enough against GPT-6 Luna, which matches Haiku 5.5's per-token price, that you should compare cost per solved task, not per token.

What a $0.10 model does to routing math.

Routing has always been a bet: send a request to the cheap model, and if the answer isn't good enough, pay for the expensive one too. The retry tax is the cost of the losing bets.

The size of that tax is set by the price ratio. On the 3,000-in, 800-out request:

At 2.5%, a failed cheap attempt is nearly free in money. Route half the requests to Haiku 5.5 and re-run 10% of those on Opus 5.5 after they fail a check, and cost per request falls 44%. Route 70% with 15% re-run and it falls 58%. Both are illustrative, at list prices, and both depend entirely on your traffic.

Two things haven't got cheaper. Latency: a request that fails on Haiku and re-runs on Opus takes both calls' time. Detection: the savings only hold if you can tell which answers failed, or predict in advance which requests will. A $0.10 model makes being wrong cheap, but not harmless, and a wrong answer that nobody catches costs more than either call. A cheap model also changes cache behaviour: moving a conversation between models throws away its prompt cache, so route whole tasks or sessions, not individual turns within them.

Tutorial: price Haiku 5.5 on your own traffic.

You need a sample of real requests from your logs (a few hundred is enough), an Anthropic API key, and a way to check whether an answer is right: unit tests, an exact-match field, or a rubric. The steps count tokens, price them with the 100K line, find your best effort level, and work out what routing would save.

Step 1: measure the tokenizer change.

count_tokens is free and counts with the tokenizer of the model you name.

import anthropic, json, statistics

client = anthropic.Anthropic()

def count(model, req):
    return client.messages.count_tokens(
        model=model,
        system=req.get("system", ""),
        messages=req["messages"],
    ).input_tokens

sample = [json.loads(line) for line in open("sample_requests.jsonl")]

ratios = []
for req in sample:
    old = count("claude-haiku-4-5", req)
    new = count("claude-haiku-5-5", req)
    req["tokens_in"] = new
    ratios.append(new / old)

print(f"new / old tokens: median {statistics.median(ratios):.2f}, "
      f"p90 {sorted(ratios)[int(len(ratios) * 0.9)]:.2f}")

Multiply your Haiku 4.5 bill by this ratio before you apply the new prices. Code, JSON and non-English text often move differently from English prose, so look at the p90, not only the median.

Step 2: price each request with the 100K line.

# USD per million tokens, Anthropic list prices, October 7, 2026.
SHORT = dict(input=0.10, output=0.50, cache_write=0.125, cache_read=0.01)
LONG = dict(input=0.50, output=2.50, cache_write=0.625, cache_read=0.05)
LINE = 100_000

def haiku55_cost(prompt_tokens, output_tokens, cache_read=0, cache_write=0):
    """prompt_tokens includes cached tokens. Assumes the whole request
    reprices once the prompt is over the line."""
    p = SHORT if prompt_tokens <= LINE else LONG
    uncached = prompt_tokens - cache_read - cache_write
    return (uncached * p["input"] + cache_read * p["cache_read"]
            + cache_write * p["cache_write"] + output_tokens * p["output"]) / 1e6

over = [r for r in sample if r["tokens_in"] > LINE]
near = [r for r in sample if 0.8 * LINE < r["tokens_in"] <= LINE]
print(f"{len(over) / len(sample):.1%} of requests over 100K, "
      f"{len(near) / len(sample):.1%} within 20% of the line")

The "near" group is the one to watch. Requests that sit at 80 to 100K today will cross the line the next time someone adds a tool, a few-shot example or a longer retrieval window. For agents, run the same check on every turn of a session, not on the first request.

Step 3: sweep effort and score each level.

def run(req, effort):
    resp = client.messages.create(
        model="claude-haiku-5-5",
        max_tokens=16000,
        system=req.get("system", ""),
        messages=req["messages"],
        output_config={"effort": effort},
    )
    text = "".join(b.text for b in resp.content if b.type == "text")
    u = resp.usage
    cost = haiku55_cost(u.input_tokens + u.cache_read_input_tokens
                        + u.cache_creation_input_tokens,
                        u.output_tokens,  # includes thinking tokens
                        u.cache_read_input_tokens,
                        u.cache_creation_input_tokens)
    return text, cost

def check(req, answer):
    ...  # your unit tests, exact match, or rubric. Return True or False.

results = {}
for effort in ["low", "medium", "high", "max"]:
    solved, spend = 0, 0.0
    for req in sample:
        answer, cost = run(req, effort)
        spend += cost
        solved += check(req, answer)
    results[effort] = (solved / len(sample), spend / max(solved, 1))
    print(f"{effort:>6}: solve rate {solved / len(sample):.1%}, "
          f"cost per solved task ${spend / max(solved, 1):.5f}")

Pick by cost per solved task, not cost per request. A level that costs twice as much but solves 30% more can be the cheaper one. Run the same loop on your current model as the baseline, keeping its own effort setting.

Step 4: price the routing decision.

def blended(share_to_haiku, miss_rate, haiku_cost, big_cost):
    """share_to_haiku: share of requests sent to Haiku 5.5.
    miss_rate: share of those that fail a check and re-run on the big model."""
    return ((1 - share_to_haiku) * big_cost
            + share_to_haiku * haiku_cost
            + share_to_haiku * miss_rate * big_cost)

solve_rate, haiku_per_solved = results["high"]
haiku_cost = haiku_per_solved * solve_rate   # back to cost per request
big_cost = 0.028                             # your measured baseline per request

for share in (0.3, 0.5, 0.7):
    c = blended(share, 1 - solve_rate, haiku_cost, big_cost)
    print(f"route {share:.0%}: {1 - c / big_cost:.1%} cheaper per request")

This uses the overall solve rate as the miss rate, which is pessimistic: a good router sends Haiku the requests it is most likely to solve, so the miss rate on routed traffic should be lower than on the whole sample. The gap between the two is what a router is worth.

Where Nadir fits.

Nadir makes the per-request decision this tutorial is approximating. Send model="auto" and a trained classifier reads each prompt and picks the tier from the models you've configured, against the quality floor you set on the API key. It routes whole requests, so a request sent to the cheap tier never touches the expensive one, and each response reports the routing decision and its cost in the metadata. If you want only the decision, POST /v1/bucket returns simple, medium or complex with a probability for each, and you call your own providers, at whatever effort level you chose in Step 3.

When a model like Haiku 5.5 lands, the expensive part is not changing the model string. It's finding out how much of your traffic can move without anyone noticing a worse answer. Observe mode records the decision Nadir would have made on every request without changing a single response, so you can compare the routed share and projected cost against your own Step 3 numbers before you switch. Start with a free key.

Conclusion.

Claude Haiku 5.5 cuts the price of a short request by about 90% and brings a cheap model within sight of frontier agent benchmarks. Three details decide what you actually pay: a 100K line above which every token costs 5x, a tokenizer that counts the same text as somewhat more tokens, and an effort setting whose default is not the one behind the best scores. Keep agents under the line, re-count your tokens, and pick effort by cost per solved task. Then use the new price ratio for what it is: at 2.5% of a premium call, trying the cheap model first is almost free, and the only hard part left is choosing which requests to send it.

Sources: Anthropic, [Claude Haiku 5.5](https://www.anthropic.com/claude-haiku-5-5), October 7, 2026 (pricing, the 100K threshold, the 75% average estimate, the tokenizer note and benchmark table). [VentureBeat](https://venturebeat.com/technology/anthropic-launches-claude-haiku-5-5-with-90-api-price-reduction-matching-gpt-6-luna), October 7, 2026 (Terminal-Bench by effort level, competitor prices). [DataCamp](https://www.datacamp.com/blog/claude-haiku-5-5) (tokenizer estimate of about 30%, Batch API discount). [MarkTechPost](https://www.marktechpost.com/2026/10/07/anthropic-releases-claude-haiku-5-5-a-small-model-with-1m-context-priced-at-0-10-per-million-input-tokens/), October 7, 2026. Opus 5.5 and Sonnet 5.5 prices from Anthropic's model pricing as of October 8, 2026. Benchmark scores are vendor-reported. The agent session, effort and routing figures are illustrative calculations at list prices, and assume the whole request reprices above 100K with cached tokens counting toward the line.