Claude Haiku 5.5 in production: when the cheap model is enough

Published on the TEN INVENT blog · October 2026

Anthropic released Claude Haiku 5.5 on 7 October 2026, and the pricing line is the kind you read twice: $0.10 per million input tokens and $0.50 per million output tokens. Haiku 4.5 was $1 and $5. On paper that is a tenfold price cut, together with a context window that grew from 200K to 1M tokens and an output limit that doubled to 128K.

On paper. In practice the cut is smaller, there is a price cliff in the middle of that 1M window, and a classification route that ran fine on Haiku 4.5 can start returning 400 errors the day you change the model ID. We wrote this article for teams that run high-volume AI work (triage, extraction, routing, sub-agents) and want to know where the cheap model is enough and where it isn't. All prices and API behaviour below come from Anthropic's official documentation at launch. Where we make assumptions, we say so.

The numbers that matter

The model is available on the Claude API as claude-haiku-5-5, on Amazon Bedrock as anthropic.claude-haiku-5-5, and on Google Cloud, Microsoft Foundry and Claude Platform on AWS under the plain ID. Cache reads are 0.1× the input rate, five-minute cache writes 1.25× and one-hour writes 2×, the same multipliers as the rest of the family.

Why tenfold is really about 7.7×

The first thing the migration guide tells you, a few paragraphs in, is that Haiku 5.5 uses a newer tokenizer and the same text counts as about 30% more tokens than on Haiku 4.5. The price per token dropped tenfold, but you now pay for 1.3 tokens where you used to pay for one. Ten divided by 1.3 is about 7.7. That is still a very large cut, but it's the number to put in a budget, not 10×.

The second thing that moves the bill is thinking. Haiku 4.5 only reasoned when you asked it to, with a manual token budget. Haiku 5.5 runs adaptive thinking by default, at medium effort, on every request that doesn't say otherwise. Thinking tokens are billed as output tokens. On a classification prompt that used to return one word, you may now be paying for a few hundred tokens of reasoning before that word. The fix is cheap: set output_config.effort to low on simple routes, where the model thinks less and can skip thinking entirely on easy inputs. But it has to be done on purpose, because the default won't do it for you.

The price cliff at 100K tokens

This is the detail we'd most like every team to see before they design anything around the 1M context. Haiku 5.5 has two rate cards, chosen by prompt length. Up to 100K tokens of prompt you pay $0.10 / $0.50. Above 100K you pay $0.50 / $2.50, five times as much, and the documentation describes it as the rate for the request, not just for the tokens above the threshold.

A 99K-token prompt costs about a cent. A 101K-token prompt costs about five. For a single request that's nothing. For a pipeline that sends a million of them a month, it is the difference between $10,000 and $50,000 in input alone. We haven't seen the threshold explained in detail for prompts that are mostly cache reads, so treat the cached part as counting toward the 100K until your invoice tells you otherwise.

What it means in practice: the 1M window is real, but it's priced for occasional use. For a high-volume route, design to stay under 100K. Retrieval that brings the five relevant chunks instead of the whole manual, conversation histories that get compacted, tool outputs trimmed before they go back to the model. If a route truly needs 300K tokens of context on every call, that route is no longer a Haiku route by price, and Sonnet 5.5 at $2 flat may come out close.

What Haiku 5.5 is good for

Anthropic positions it for "high-volume, latency-sensitive work such as classification, routing, extraction, and sub-agent tasks", and says it's substantially better than Haiku 4.5 at following instructions and at running as a sub-agent. From the work we do for clients, these are the routes where we'd try it first:

• Ticket and email triage. Category, priority, language, whether a human must see it. Short input, a structured answer, millions of calls.
• Extraction into a schema. Invoices, CVs, contracts, form submissions. With structured outputs the model can't return malformed JSON, which matters more than raw intelligence here.
• Routing in front of a bigger model. Haiku decides whether a question is a FAQ answer, a database lookup, or something that needs Sonnet or Opus.
• Reading-heavy sub-agents. In an agent that has to go through fifty files or a hundred web pages, the expensive model doesn't have to read everything. A Haiku worker reads and summarises, the main model decides.
• Log and event summarisation. Turning a night of CloudWatch noise into five lines a person will actually read.
• Moderation and PII checks before text is stored or sent further.

Where we would not use it: long agentic coding sessions, large refactors, multi-step research where the next search depends on judgment about the last one, and anything where a wrong answer is expensive and hard to detect. That's what Sonnet 5.5 and Opus 5.5 are for, and we look at that boundary in the Opus 5.5 vs Fable 5.1 comparison.

A real cost comparison

Let's price a concrete route: ticket triage at one million requests a month. Each request has a 3,000-token prefix that is identical every time (system prompt, category definitions, a few examples), so it's served from cache. Then 1,000 tokens of fresh input, the ticket itself, and 300 output tokens including the thinking at low effort. We assume the same token count for the 5.5 models and divide by 1.3 for Haiku 4.5, as the tokenizer note says. Cache writes are left out because at this volume the prefix stays warm.

Per request that is $0.00028 on Haiku 5.5, $0.0053 on Sonnet 5.5 and $0.0106 on Opus 5.5. Haiku 5.5 is about 19 times cheaper than Sonnet and 38 times cheaper than Opus on this profile. Notice where the money goes: on Haiku 5.5 more than half the cost is output, so the effort setting moves the bill more than the prompt length does. Double the thinking and you almost double the cost.

One caution before anyone builds a three-tier cascade on the strength of a chart like this. Anthropic's own cost guidance says to measure the simpler option first: the stronger model at lower effort on the same tasks. A cascade has hidden costs. Caches are per model, so every escalation pays for its prefix again. A wrong answer from the cheap model that gets caught later costs a retry on the expensive one, and a wrong answer that doesn't get caught costs more than any token. Judge cost per completed task, not per request. For triage and extraction Haiku usually wins on both counts. For anything that needs judgment, check with your own evals.

Breaking changes if you're coming from Haiku 4.5

Existing Haiku 4.5 prompts should mostly work, according to Anthropic. The request code around them may not. These are the changes that return errors or silently change output:

1. budget_tokens returns a 400. Thinking is adaptive only. Replace the budget with output_config.effort.
2. temperature: 0 returns a 400. Sampling parameters must be left at their defaults; top_k is rejected outright. Classification routes almost always set temperature: 0, so this is the one that breaks first. Constrain the output with structured outputs or an enum in a tool schema instead.
3. Assistant prefill returns a 400, even with thinking off. If you used a prefill to force JSON, use structured outputs. If you used it to skip a preamble, say so in the system prompt.
4. Thinking counts toward max_tokens. A max_tokens: 50 sized for a one-word label can be used up by thinking, and you get stop_reason: "max_tokens" with no text at all. Leave room, around 1,000 tokens on a short route, or lower the effort.
5. The first content block may be thinking. Code that reads response.content[0].text breaks. Read blocks by type.
6. Safety classifiers can decline a request, and on Haiku 5.5 there is no server-side fallback to another model. Handle stop_reason: "refusal" in your own code.
7. Thinking blocks are bound to the account and to the conversation. Pass them back unchanged with tool results and don't edit earlier turns.

Turning thinking off is still possible with thinking: {type: "disabled"}, but only at low, medium or high effort, and the documentation is fairly clear that lowering effort is the better lever.

What it looks like in code

This is roughly what we put in front of a support inbox, in TypeScript, with a Zod schema so the answer can't come back malformed:

import Anthropic from "@anthropic-ai/sdk";
import { z } from "zod";
import { zodOutputFormat } from "@anthropic-ai/sdk/helpers/zod";

const Triage = z.object({
  category: z.enum(["billing", "bug", "how-to", "account", "other"]),
  priority: z.enum(["low", "normal", "urgent"]),
  needs_human: z.boolean(),
});

const client = new Anthropic();

export async function triage(ticket: string) {
  const response = await client.messages.parse({
    model: "claude-haiku-5-5",
    max_tokens: 1024, // room for thinking plus the answer
    output_config: {
      effort: "low",
      format: zodOutputFormat(Triage),
    },
    system: [
      { type: "text", text: TRIAGE_RULES, cache_control: { type: "ephemeral" } },
    ],
    messages: [{ role: "user", content: ticket }],
  });

  if (response.stop_reason === "refusal") return null; // no server-side fallback on Haiku
  return response.parsed_output;
}

Three details carry most of the value. The rules sit in a cached system block, so the 3,000-token prefix costs a tenth of the input price. Effort is set to low explicitly, because the default is medium. And there is no temperature anywhere, because sending one is now an error.

Our recommendation

If you have a high-volume route on Haiku 4.5, migrate it. Even after the tokenizer, the price drops by a factor of about 7.7, the model is better at following instructions, and the code changes take an afternoon if you go through the list above. If you have a route on Sonnet that only classifies or extracts, run it on Haiku 5.5 against your evals. On our example the saving is 95%, and for that kind of work the quality difference is often smaller than people expect.

Two rules to keep it cheap: stay under 100K tokens per prompt, and set effort explicitly on every route. And if you'd like a second pair of eyes on where your AI bill actually goes, that's work we do for clients.