On October 7, 2026, Anthropic shipped Claude Haiku 5.5, and it quietly broke three things most high-volume pipelines depend on: manual thinking budgets, assistant message prefill, and the sampling parameters classification code has long leaned on. None of that shows up in the headline. The headline is the price: $0.10 per million input tokens for prompts under 100k, down from $1 on Haiku 4.5 [1][2]. But if you’re running a routing or classification pipeline and you just swap the model string, you’ll get a wall of 400 errors before you get the savings.
This is a migration guide, not a launch recap. It walks through what actually breaks when you move a classification or routing pipeline off Haiku 4.5, how to fix each thing, and what the cost and latency math looks like once you do.
In this article:
Haiku 5.5 is positioned squarely at the work classification and routing pipelines do: summarization, compaction, database queries, and classification at volume, run as a subagent under a bigger model when needed [1].
The context window jumped from 200k to 1M tokens, and max output rose from 64k to 128k [3]. Training data cutoff is June 2026 [4]. Neither number is the interesting part for a migration.
The interesting part is the tokenizer. Haiku 5.5 uses the same newer tokenizer as Claude 4.7 and later, and the same text produces roughly 30% more tokens than it did on Haiku 4.5 [3]. That matters because pricing is tiered by prompt length: $0.10 input and $0.50 output per million tokens for prompts up to 100k, rising to $0.50 and $2.50 above that [2]. Anthropic’s own footnote says Haiku 5.5 is about 90% cheaper than Haiku 4.5 for requests under 100k tokens and 50% cheaper above that, with the blended average closer to 75% once the tokenizer inflation is factored in [1]. If your classification prompts are small (a support ticket, a log line, a routing decision) you’re almost certainly staying under the 100k threshold and capturing the full discount. I wrote about picking a model tier by workload before Haiku 5.5 existed; the framework still holds, the numbers in it don’t.
Anthropic’s own benchmark table backs this with customer numbers rather than just synthetic scores: Box reported a classification score 11 points higher than Haiku 4.5 at roughly half the latency, and Asana measured a 30% drop in latency for task completions on its existing workload [1]. Those are vendor-reported, not independently audited, so treat them as directional rather than guaranteed for your own data.
Four things in a typical classification or routing pipeline will return a 400 error on Haiku 5.5 without any code change needed to trigger them, because the old syntax is simply rejected [5]. First, manual extended thinking: thinking: {"type": "enabled", "budget_tokens": N} no longer works. You now set thinking: {"type": "adaptive"} and control depth with a separate effort parameter instead of a token budget [3][5].
Second, sampling parameters. temperature, top_p, and top_k are rejected outright on most values; if you still send temperature it must equal 1, and sending both temperature and top_p together fails regardless of their values [5]. For a classifier that used temperature: 0 to make labels more repeatable, this is the change that actually requires rethinking your approach, since you can no longer lower temperature to reduce label variance. Validate outputs in code instead and treat the model as probabilistic even at the margins.
Third, assistant message prefill. If your routing code forces a response format by ending the messages array with a partial assistant turn (a common trick to force a label as the first token), Haiku 5.5 rejects it. Requests must end on a user turn [3][5].
Fourth, and easy to miss: thinking blocks from every earlier assistant turn now stay in context and count as input tokens, where Haiku 4.5 only kept the latest turn’s blocks [3]. In a multi-turn routing conversation, that compounds token usage in a way it didn’t before. I covered why these per-call costs matter more than the sticker price in a separate piece on agent loop economics, and the thinking-block accumulation is exactly the kind of hidden multiplier that piece warned about.
If prefill was how your pipeline forced a category label, the replacement is a classification tool with an enum, called with tool_choice: {"type": "auto"} rather than a forced choice [5]. That last detail matters more than it looks: forcing a specific tool with tool_choice: "any" or a named tool suppresses the thinking block entirely, so if you want the model to reason before it commits to a label, auto tool choice plus a prompt instruction is the only way to get both [3].
{ "model": "claude-haiku-5-5", "max_tokens": 2000, "output_config": { "effort": "low" }, "tools": [{ "name": "classify", "description": "Record the category for this ticket.", "input_schema": { "type": "object", "properties": { "label": { "type": "string", "enum": ["billing", "technical", "account", "other"] } }, "required": ["label"] } }], "tool_choice": { "type": "auto" }}
This is the same structured-outputs pattern I laid out in more detail in a prior post on getting the API to actually honor a schema, and nothing about the underlying approach changed with Haiku 5.5. What did change is that structured outputs, whether through output_config.format or a strict tool, are not available on Amazon Bedrock for this model [5]. If your routing pipeline runs on Bedrock, you're back to describing the schema in the prompt, using a non-strict tool, and validating the result in code, which is a real regression if you'd standardized on strict mode there.
Haiku 5.5 runs safety classifiers that can decline a request outright, and unlike some earlier models, there’s no server-side fallback to retry with [3]. For a production classification pipeline, that means stop_reason: "refusal" is now a code path you have to handle explicitly, not an edge case you can ignore: route refused items to manual review or a default label rather than letting the pipeline silently drop them. I wrote earlier about what a production agent pipeline should be logging before something breaks, and a refusal with no fallback is exactly the kind of failure mode that post argues you need visibility into before it happens in bulk, not after.
The effort parameter is the other lever worth tuning deliberately rather than leaving at a default. It trades cost and latency against intelligence, and it's the first time a Haiku-class model has exposed that knob at all [1]. For straightforward routing decisions, a low effort setting keeps both cost and latency down; for harder classification calls where accuracy matters more than speed, stepping up to medium or high is a one-line change rather than a model swap. There's no universal right answer here, only a tradeoff worth testing against your own label accuracy.
One more thing worth flagging before you commit: minimum cacheable prompt length dropped from 4,096 tokens to 512 [3]. For short classification prompts that previously couldn’t benefit from prompt caching at all, this is a real, if modest, win. It won’t change your architecture, but it’s free money you weren’t collecting before.
Here’s a worked example, not a real customer’s numbers, just the arithmetic so you can run your own. Say a routing pipeline processes 50 million input tokens and 5 million output tokens a month on Haiku 4.5, at flat rates of $1 and $5 per million [2]. That’s 50 × $1 + 5 × $5 = $75/month.
Move the same text to Haiku 5.5’s tokenizer and it inflates by roughly 30%, so you’re now counting 65 million input tokens and 6.5 million output tokens [3]. If each individual request stays under the 100k-token threshold, which is likely for short routing prompts, that’s priced at $0.10 and $0.50 per million: 65 × $0.10 + 6.5 × $0.50 = $9.75/month.
That’s an 87% reduction for this specific shape of workload, a little better than Anthropic’s own blended “~75% cheaper on average,” because small, short-prompt classification work sits in the most favorable pricing tier [1][2]. A pipeline that routinely sends longer prompts, closer to or over 100k tokens, will land nearer that 50%-cheaper figure instead, so run the math on your own prompt-length distribution before you forecast savings.
Latency is harder to generalize from vendor numbers alone, but the direction in Anthropic’s reported customer results is consistent: faster, not just cheaper, across the board [1]. If your pipeline is latency-sensitive (live routing in a support queue, for instance) that’s worth validating with your own traffic before rollout, not assuming from a benchmark table.
None of this is a reason to migrate blindly. If you’re on Bedrock and leaned on strict structured outputs, that gap is real and worth weighing against the price cut. If your pipeline forces labels through prefill, budget time to rewrite that path properly rather than patching around the 400 error. But for a straightforward classification or routing workload running on the Claude API or Google Cloud, with short prompts and no hard dependency on forced sampling, the migration checklist is short and the savings are not theoretical.
If you enjoyed the article and wish to show your support, make sure to:
Moving Your Classifier to Claude Haiku 5.5: What Changes was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.