Haiku 5.5: Anthropic Is Turning Model Capability into a Division of Labor
The value of Claude Haiku 5.5 is not only that it answers faster and costs less, but that it begins to turn model calls into infrastructure that can be deployed at scale.
Haiku 5.5: Anthropic Is Turning Model Capability into a Division of Labor
The value of Claude Haiku 5.5 is not only that it answers faster and costs less, but that it begins to turn model calls into infrastructure that can be deployed at scale.
Anthropic released Claude Haiku 5.5 on 7 October 2026. One name is easy to mix up: in Anthropic's public materials, the model name is Claude Haiku 5.5 and the model ID is claude-haiku-5-5. There is no official model named "Claude Hiya 5.5". This article uses Haiku 5.5 throughout.
Anthropic's positioning is explicit. This is a small model for high-concurrency, low-latency, cost-sensitive work: classification, information extraction, summarization, context compression, database queries, browser actions, and agent subtasks. Anthropic says the average cost of running Haiku 5.5 is about 75% lower than Haiku 4.5. It is also the first Haiku model with an adjustable effort setting.
That changes the question from "is this another stronger small model?" to a more practical one: when a model is cheap enough to be called in large numbers, what happens to the division of labor among models in an AI product?
The Claude 5.5 family is forming a clear division of labor
Looking only at the names, it is easy to treat Opus, Sonnet, and Haiku as three rungs on one capability ladder. A more accurate reading is that they are forming a division of labor across different workloads.
| Model | Better suited as | Typical tasks |
|---|---|---|
| Claude Opus 5.5 | Expert on complex problems and long-horizon planner | Complex agents, long coding sessions, hard reasoning, critical decisions |
| Claude Sonnet 5.5 | Default model for everyday work | Code changes, document generation, analysis, multi-step knowledge work |
| Claude Haiku 5.5 | High-frequency execution layer | Classification, extraction, summarization, compression, routing, browser actions, and subagent tasks |
Anthropic's model overview uses a similar placement. Opus 5.5 is for long-running agent coding and knowledge work. Sonnet 5.5 emphasizes the balance of speed and intelligence. Haiku 5.5 is for high-concurrency, low-latency classification, extraction, and routing.
This means Haiku 5.5's advantage does not have to show up as "stronger than a mid-size model at everything." It is more likely to show up somewhere else: whether it can turn many local tasks that were not worth automating, because of cost, latency, or throughput, into system steps that can keep running.
A lower price changes how calls are made
Haiku 5.5's official price has to be read as two ranges. For requests whose input prompt does not exceed 100K tokens, input is $0.10 per million tokens and output is $0.50 per million tokens. Above 100K tokens, those prices are $0.50 and $2.50.
| Request size | Input | Output | Cache read |
|---|---|---|---|
| Up to 100K tokens | $0.10 / MTok | $0.50 / MTok | $0.01 / MTok |
| Over 100K tokens | $0.50 / MTok | $2.50 / MTok | $0.05 / MTok |
Two details are easy to miss.
First, a lower unit price and a lower real cost are not the same thing. Anthropic's "about 75% lower average running cost" already includes the change in token use from the new tokenizer. Dividing the old and new price per million tokens does not tell you that a product bill will fall by the same ratio.
Second, whether the model actually finishes the task changes the real cost. One call can be cheap, and the task can still be expensive if it needs retries, a fallback to Sonnet, or extra human review.
Product teams should watch this measure instead:
Cost per successful task
= total model and tool spend to finish the tasks ÷ number of tasks finished successfully
A comparison across architectures should also put retries, fallback, tool calls, and human takeover into the total bill.
One of the most important changes in Haiku 5.5 is adjustable effort
Haiku 5.5 is the first Haiku model with adjustable effort. That setting means model choice is no longer the only cost switch. A system can also change how much reasoning it spends inside the same model.
Think of it as a car's driving modes:
- For simple classification and format conversion, use a lower effort and favor speed and low cost.
- For structured extraction and long-document compression, use a medium effort and balance quality against spend.
- For tasks that need multi-step judgment, raise the effort.
- If the task still fails, move up to Sonnet or Opus.
That produces a new decision formula:
Final result = model × effort × context × tools × retry policy
Comparing models is then no longer only "which is stronger, Haiku 5.5 or Sonnet 5.5?" The further questions are:
- On the same task, which effort level is the better deal?
- Does the quality gain from a higher effort cover the extra cost?
- On a simple task, does a higher effort only add waiting time?
- Is it cheaper to let Haiku try once more, or to call Sonnet once?
This is why Haiku 5.5 is better judged by task-level cost than by how one output feels.
Agents may move from one large model to layered collaboration
Many agents have been shaped like this: after the user makes a request, one large model plans, retrieves, calls tools, organizes the results, and writes the final answer.
User request → large model plans → large model searches → large model summarizes → large model answers
The shape is simple, and it also spends the same expensive model on every local action. For an agent that searches dozens of documents, processes hundreds of records, or keeps calling a browser, cost and latency add up quickly.
Haiku 5.5 fits a layered shape like this:
User request
↓
Sonnet or Opus splits the task and makes the plan
↓
Haiku 5.5 searches, classifies, extracts, summarizes, and makes single tool calls
↓
Sonnet or Opus reviews the results and makes the final decision
In this shape, Haiku 5.5's value is not finishing the hardest task on its own. It becomes the agent's worker layer. It handles the local work that is most numerous, relatively structured, and possible to check.
Work that fits Haiku 5.5
- Route a user request into different workflows.
- Extract fixed fields from one document or a few documents.
- Classify tickets and set their priority.
- Compress a long conversation into the context the next agent turn needs.
- Deduplicate search results and write a first-pass summary.
- Perform one explicit browser action.
- Check code formatting, generate a simple test, or explain a local piece of code.
- Finish a short piece of work as a subagent of Sonnet or Opus.
Work that should not go to Haiku 5.5 by default
- Complex projects that need long-horizon planning.
- Code changes that touch many files, many dependencies, and several rounds of feedback.
- Critical decisions where one mistake is expensive.
- Work that must keep a complex state across a long process.
- Tasks with no automatic check, where a person has to judge the result.
The point is not to label a model "can" or "cannot." It is to judge the cost of failure. When a task can be checked automatically and retried after a failure, Haiku 5.5's price-to-result ratio is more attractive. When failure is expensive, Sonnet or Opus is still the steadier choice.
How an ordinary developer can choose among the three
Start with a simple route based on task complexity and the cost of failure:
| Task | Default | Move up when |
|---|---|---|
| Fixed output format that can be checked automatically | Haiku 5.5 | Repeated format errors, or a required field is missing |
| High call volume and sensitivity to latency | Haiku 5.5 | p95 latency or the failure rate crosses the product threshold |
| Summarization, compression, classification, or extraction | Haiku 5.5 | Cross-document reasoning or a context conflict appears |
| Ordinary knowledge work and code changes | Sonnet 5.5 | The task spans a long horizon or needs several rounds of planning |
| Complex agents and long-horizon coding | Sonnet 5.5 or Opus 5.5 | Tolerance for mistakes is very low, or the task needs deep reasoning |
| High-stakes judgment and final review | Sonnet 5.5 or Opus 5.5 | Decide from the cost of an error and from how well the result can be checked |
This table is not a permanent answer. Before production, measure your own task set and find where each model separates on success rate, latency, and cost per successful task.
100K tokens is a price boundary to watch
Haiku 5.5's advertised price is low, and the price rises sharply after 100K tokens. Teams building on long documents, code repositories, or long conversations cannot look only at the published starting price.
A long-context workflow can be split into steps:
- Build a cache the first time the document is read.
- Use Haiku 5.5 to compress the context.
- Send Sonnet only the passages that matter to the current question.
- Save intermediate results as structured state.
- Do not resend the full history on every turn.
This does two things. It lowers the chance of crossing the 100K price range, and it lets different models carry different work.
The long-context value of Haiku 5.5 is therefore not measured only by "how many tokens it can read." The practical questions are:
- How much raw material has to enter the model?
- Which material should be compressed first?
- What is the cache hit rate?
- Is the price above 100K still acceptable?
- Can the information lost in compression make a later task fail?
The Haiku 5.5 release also changes what evaluation should measure
The official page already lists results for GDPval-AA, OSWorld, Humanity's Last Exam, Terminal-Bench, and others. Those results help a reader see the rough range of the model. A product team still needs tests on its own tasks.
In a real system, the number worth watching is not one score on one benchmark. It is this set:
- Task success rate.
- Output quality.
- p50 and p95 latency.
- Input and output token counts.
- Retry rate.
- Tool-call error rate.
- Fallback rate.
- Human takeover rate.
- Cost per successful task.
Pay particular attention to stability across repeats. One attractive answer to one prompt only shows that this run succeeded. It does not show that the model will reliably finish the same kind of task in production.
A more reliable test looks like this:
- Prepare an independent sample set for each kind of task.
- Run them with the same system prompt, context, tool definitions, and region.
- Repeat each sample several times.
- Judge the results with rules, held-out tests, or a blind human review.
- Report the success rate and the confidence interval.
- List the worst cases and the failure types separately.
That method moves evaluation from "which output was the best one?" to "can this system keep finishing the work?"
What Haiku 5.5 means for an individual user
An individual user may not feel the API unit price directly. Haiku 5.5's place can still be read from three angles.
First, it fits fast, repeated work with a clear boundary: organizing text, extracting information, generating a structured draft, and handling a large number of small questions.
Second, it does not have to replace every stronger model. Complex writing, long-horizon planning, difficult code, and work that must keep state across a long stretch still depend more on Sonnet or Opus.
Third, the difference between models looks more and more like a difference in how the work is done, not a simple high-versus-low ranking. Choose a model by looking first at how often the task runs, how much latency it can take, what an error costs, and how the result can be checked. Look at single-call ability after that.
What a product team has to recalculate is the economics of one unit of work
Haiku 5.5 makes it easier to try steps that were not worth automating:
- One more layer of input classification.
- One more pass that compresses retrieval results.
- One more subagent dedicated to documents.
- One more low-cost check of the output.
- One more structured check before the final answer.
Those extra steps increase the number of calls. If they lower the final failure rate, the cost of the product as a whole can still fall.
That is why a single model price is not enough. A product team needs to compare:
Cost of one call
→ total cost of one task
→ total cost of one successful task
→ total cost of one deliverable result
When Haiku 5.5 is cheap enough, a system can trade several small tasks for a more reliable final result. That change affects how agents are designed, how a product's margin is structured, and which work a team decides to hand to a model.
Closing: Haiku 5.5 is an architecture change
The release of Haiku 5.5 can be read as a small-model upgrade. It can also be read as Anthropic pushing the shape of the model product forward.
It puts three questions on the same decision sheet:
- How much intelligence does this task need?
- How much latency can this task bear?
- How much money is this task worth?
Once model choice sits with task routing, effort, cache, retries, and human takeover, "which model is the strongest?" is no longer the only question. The more important question becomes:
Which model should handle which call, and how do you get a reliable enough result at the lowest end-to-end cost?
The point of Haiku 5.5 may be that this question is cheap enough, for the first time, to be worth asking at scale.