Moving to Claude Haiku 5.5: the breaking changes, the effort dial and the 100k price cliff

Anthropic released Claude Haiku 5.5 on 7 October. The headline is price: list prices for normal-sized prompts are 90% lower than Haiku 4.5. The less obvious part is that code written for Haiku 4.5 can fail on Haiku 5.5. A few request parameters that used to work now return a 400 error, and a new pricing rule can make a long prompt five times more expensive per token than a slightly shorter one.

If you run Haiku in production for triage, extraction, routing or as a subagent, this is the checklist we would follow before switching the model string.

What changed, in one table

All figures below are from Anthropic’s Haiku 5.5 model overview and what’s-new page. Prices are US dollars per million tokens.

	Claude Haiku 4.5	Claude Haiku 5.5
Context window	200k tokens	1M tokens
Max output	64k tokens	128k tokens (300k on the Batch API, beta)
Input price	$1.00	$0.10 (prompt up to 100k) / $0.50 (over 100k)
Output price	$5.00	$0.50 / $2.50
Cache read	$0.10	$0.01 / $0.05
Minimum cacheable prompt	4,096 tokens	512 tokens
Thinking	Manual (budget_tokens)	Adaptive, on by default, with an effort setting
Tokenizer	Older	Newer: the same text is about 30% more tokens

The model ID is claude-haiku-5-5. It is available on the Claude API, Amazon Bedrock (as anthropic.claude-haiku-5-5), Google Cloud, Microsoft Foundry and Claude Platform on AWS, per the 7 October release notes.

On quality, Anthropic’s launch page reports large gains over Haiku 4.5 on every benchmark it lists. One example: on the offline subset of OSWorld 2.1 it reports 72.4% for Haiku 5.5 against 15.7% for Haiku 4.5. These are the vendor’s own numbers; run your own evals on your own tasks before trusting them.

The five things that can break

The release notes list the changes that turn a working Haiku 4.5 request into a 400 error on Haiku 5.5. In practice, check these in order:

1. Sampling parameters. temperature, top_p and top_k can return an error. Many codebases set temperature: 0 for classification out of habit. Remove it.
2. Manual thinking budgets. budget_tokens is not accepted. Thinking is now adaptive and you steer it with effort (below).
3. Assistant prefill. Ending messages with a partial assistant turn, a common trick to force JSON, now errors. End with a user turn and use structured outputs or a tool instead.
4. The old computer-use tool. computer_20250124 errors. Anthropic points to computer_toolset_20260801 on the Claude API and Google Cloud, and computer_20251124 on Bedrock.
5. Edited history with thinking blocks. If you send thinking blocks back and also change the system prompt, tools or earlier turns, the request can fail. Keep conversations append-only.

Two Bedrock-specific notes: structured outputs aren’t available for Haiku 5.5 there, so validate JSON in your own code, and the computer-use tool name differs from the Claude API.

There are also changes that won’t error but can still break a parser. A response can now start with a thinking block even if you never asked for thinking, so code that reads response.content[0].text will pick up the wrong block. Select blocks by type. And the model can decline a request through a safety classifier, which shows up as stop_reason: "refusal". If your pipeline assumes every response has text, add a branch for that.

Effort: the new dial

Haiku 5.5 is the first Haiku with an effort setting. Per Anthropic’s effort documentation, it supports all five levels (low, medium, high, xhigh, max) and defaults to medium. You set it with output_config.effort.

The docs give practical guidance worth following:

• low for chat, short tool calls and simple high-volume requests. The docs warn that in long agent prompts the model is more likely to skip a search or stop early at this level.
• medium as the starting point for most work.
• high for knowledge work, longer agent tasks and strict instruction following.
• xhigh / max only where your evals show a gain, and compare against Sonnet 5.5 at that point.

Thinking counts toward max_tokens. If you had a tight max_tokens for short classification answers, raise it, or the model can run out of room after thinking and before writing the answer. You can turn thinking off with thinking: {"type": "disabled"}, but only at high effort or below.

The 100k price cliff

Haiku 5.5 has two price tiers. Anthropic’s pricing page says a request whose prompt is over 100,000 tokens pays the higher prices, and that the count includes cache reads and writes. It is not a marginal rate: the whole request is billed at the higher tier.

That makes the boundary sharp. By our arithmetic from the list prices, a 99,000-token prompt costs about $0.0099 in input, while a 101,000-token prompt costs about $0.0505. Two thousand extra tokens, five times the input bill, and output on that request is also billed at the higher rate.

Now combine that with the tokenizer change. A prompt that measured 85,000 tokens on Haiku 4.5 is likely to be around 110,000 on Haiku 5.5 if the 30% figure holds for your content. Long-document workloads that sat comfortably under the line can cross it without any change to your code.

What to do:

• Recount real prompts with the new model before you switch. Don’t reuse token counts from Haiku 4.5 logs.
• Cap retrieval. If you stuff RAG chunks into the prompt, set a token budget below 100k rather than a fixed number of chunks.
• Log prompt size per request and alert when a meaningful share goes over 100k.
• Remember caching doesn’t help here. Cached tokens still count toward the threshold. What caching does help with is cost below it: the minimum cacheable prompt dropped from 4,096 to 512 tokens, so short, repeated system prompts can now be cached.

A worked cost example

Take a ticket-triage job: 1 million requests a month, each with a 2,000-token prompt and a 300-token answer. This is our arithmetic from the list prices above, not an Anthropic figure.

	Haiku 4.5	Haiku 5.5 (same token counts)	Haiku 5.5 (+30% tokens)
Input	$2,000	$200	$260
Output	$1,500	$150	$195
Monthly total	$3,500	$350	$455

Thinking tokens are billed as output and are the unknown here. Even if thinking tripled the output tokens in the last column, the total would be about $845, still roughly 75% below Haiku 4.5. That lines up with Anthropic’s own claim on the launch page that Haiku 5.5 costs about 75% less to run on average. If you can use the Batch API, input and output are a further 50% cheaper.

Notes for teams in India

Anthropic bills in US dollars, so budget for exchange-rate movement on top of these numbers. On the first-party API, the default global routing uses standard prices, while pinning inference to the US with inference_geo: "us" adds a 1.1x multiplier, per the pricing page. On Bedrock and Google Cloud, regional endpoints carry a 10% premium over global ones. If you don’t have a data-location requirement, global is the cheaper default.

A migration order that works

1. Run your existing eval set on claude-haiku-5-5 at medium effort with the five breaking items fixed.
2. Recount tokens for your largest real prompts and check how many land over 100k.
3. Try low effort on the simplest, highest-volume task and compare quality and cost.
4. Roll out behind a flag, keeping Haiku 4.5 as the fallback, and watch refusals, empty-text responses and cost per request for the first week.

The model is cheaper and, on Anthropic’s numbers, much stronger. The work is in the request shape and the token counts, not the model string.