---
title: "Claude Haiku 5.5 at $0.10 Per Million: Where It Fits"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2026-10-18"
category: "Cost & Planning"
tags:
  - Claude Haiku 5.5 pricing
  - Claude Haiku 5.5
  - LLM cost per feature
  - AI subagents
  - model routing
excerpt: "Anthropic released Claude Haiku 5.5 on October 7, 2026 at $0.10 per million input tokens and $0.50 per million output tokens. Here is the real cost math, the jobs it fits, and the pricing traps that change your bill."
reading_time: "9 min read"
canonical_url: "https://kanopylabs.com/blog/claude-haiku-5-5-pricing-subagents-model-routing"
---

# Claude Haiku 5.5 at $0.10 Per Million: Where It Fits

## What Anthropic Shipped on October 7

Anthropic released Claude Haiku 5.5 on October 7, 2026. It is the small, fast, cheap model in the Claude 5.5 family, aimed at high-volume work such as summaries, database queries, classification and coding subagents.

The numbers that matter, as reported by launch coverage that cites Anthropic's documentation:

- **Price:** $0.10 per million input tokens and $0.50 per million output tokens for prompts up to 100K tokens.

- **Cache reads:** $0.01 per million tokens.

- **Batch API:** 50 percent off both input and output.

- **Context window:** 1M tokens, with up to 128K tokens of output.

- **Effort control:** low, medium, high, xhigh and max, with medium as the default. This is the first Haiku that accepts the effort parameter, and it thinks by default through adaptive thinking.

Check Anthropic's pricing page before you build a budget on these figures, because I am relying on secondary write-ups. The shape of the story will not change. This is a model priced at roughly one fortieth of Opus 5.5, which lists at $4 and $20 per million tokens, as we covered in our [Opus 5.5 migration guide](/blog/claude-opus-5-5-migration-pricing-what-breaks).

That gap is the whole reason to care. A founder who routes the right work to the small model can cut an AI line item by an order of magnitude. A founder who routes the wrong work to it ships worse answers and loses users. The rest of this article is about telling those two cases apart.

![Laptop showing a dashboard of API usage and cost charts](https://images.unsplash.com/photo-1551288049-bebda4e38f71?w=800&q=80)

## The Cost Math at Real Volumes

Price per million tokens is hard to feel. Convert it to something you can put in a budget.

Take a feature that processes 10 million input tokens and 2 million output tokens a month. That is a mid-sized support summarizer or a tagging pipeline for a product with a few thousand active users.

- On Haiku 5.5: 10 times $0.10 is $1.00 for input, and 2 times $0.50 is $1.00 for output. About **$2 a month**.

- On Opus 5.5: 10 times $4 is $40, and 2 times $20 is $40. About **$80 a month**.

Scale it up by a factor of a thousand, to 10 billion input tokens and 2 billion output tokens, and you are comparing $2,000 a month with $80,000 a month. At that volume the model choice is a headcount decision.

Now add the discounts. If the job does not need an instant answer, the Batch API halves those numbers. If your prompt starts with a long, stable block of instructions or reference text, cache reads at $0.01 per million tokens make that block nearly free after the first call. A support bot with a 20K-token policy document at the top of every request pays about $0.0002 to read it from cache, instead of $0.002 at the standard input rate. These two levers stack, and they matter more than a small difference in per-token price between vendors.

One honest caveat. These figures are token costs only. They leave out your engineering time, your evaluation work and the retries you pay for when a cheap model gets a task wrong. We will come back to that, because it is where the savings often disappear.

Here is how I count it. A fair comparison is the cost per correct answer, not the cost per call. If Haiku 5.5 is right 92 percent of the time and the larger model is right 97 percent, the cheap model needs about one extra call in twenty to be corrected, by a retry, a fallback or a person. At forty times the price gap, the retry costs almost nothing. If each wrong answer lands in front of a customer or triggers a support ticket, the math flips fast. A single support ticket handled by a human costs more than a month of Haiku calls for the whole feature. Put a dollar figure on a wrong answer before you decide how much accuracy you are willing to trade.

## The Pricing Traps That Change Your Bill

Cheap models have fine print. Three items in Haiku 5.5's pricing can move your real cost well above the headline.

### The 100K token cliff

Prompts over 100K tokens are billed at $0.50 input and $2.50 output per million. That is five times the base rate. One source notes that the higher rate applies to the whole request, not just the tokens over the line. So a 101K-token prompt costs five times what a 99K-token prompt costs, even though it holds only 2 percent more text.

The 1M context window is real, and it is useful, but it is not a license to stuff everything in. If you have a job that sometimes crosses 100K tokens, add a check that trims or chunks the input to land under the line. This is a one-afternoon fix that can save you thousands a month on a heavy pipeline.

### Thinking by default means more output tokens

Haiku 5.5 uses adaptive thinking by default, and the reasoning it does is billed as output. Output is the expensive side at $0.50, five times the input price. A classification call that should return one word may instead spend several hundred tokens thinking about it.

The fix is the effort setting. For routine extraction, tagging and routing calls, set effort to low. Run a sample of a few hundred real inputs at low and at medium, compare accuracy and token counts, and keep the cheaper setting if the accuracy holds. In my experience the answer for simple tasks is usually low.

### Subagent fan-out multiplies everything

The use case Anthropic highlights is coding subagents, where a larger model plans and many small models do pieces of the work. It is a good pattern, and it is also easy to let it run away. Ten subagents each reading a 30K-token codebase slice is 300K input tokens for one task. Put a cap on how many run in parallel, and log token spend per task from the first day. Our guide to [managing LLM API costs](/blog/how-to-manage-llm-api-costs) covers the logging setup.

## Jobs Haiku 5.5 Should Take

The right question for any feature is how bad a wrong answer is, and how easy it is to catch. Haiku 5.5 is a good fit when the answer is short, the task is well defined and a mistake is cheap.

- **Classification and routing.** Is this support ticket about billing, a bug or a feature request? Which of five queues should it land in? These tasks are the textbook case for a small model.

- **Summaries.** Meeting notes, long threads, call transcripts, product reviews. A small model does well when the source text is in the prompt and you are not asking for judgment.

- **Structured extraction.** Pull the invoice total, the dates and the vendor name out of a document. Validate the output against a schema and retry on failure.

- **Natural language to a database query.** Anthropic names this as a target use. Pair it with a read-only database role and a query validator, whatever model you pick.

- **Coding subagents.** Search a repo, run a lint fix, write a test for a function, summarize a diff. Let a stronger model decide what to do and let the small one carry it out.

- **First-pass filtering.** Run every item through Haiku and send only the uncertain ones to a bigger model. This pattern often cuts the big-model bill by more than half.

In all of these, the model's output feeds either a human who can correct it quickly or another system that can validate it. That is the pattern to look for.

## Jobs It Should Not Take

A cheap model that gets the answer wrong costs more than an expensive one that gets it right. Keep these on a larger model.

- **Anything customer-facing where tone and judgment carry the product.** A coaching feature, a sales email draft that goes out under your user's name, an advice engine. Users notice flat or wrong answers fast.

- **Multi-step reasoning with real consequences.** Financial calculations, legal or medical-adjacent summaries, contract review. Use the best model you can afford and put a human in the loop.

- **Long-horizon agent work.** A task that takes dozens of tool calls and must stay coherent. Small models drift. Use a larger one as the planner.

- **Ambiguous tasks with no easy way to check the result.** If you cannot write a test or a validator, you cannot tell whether the cheap model is good enough, and you will find out from a support ticket.

I would not tell any founder to move their entire AI stack to the cheapest tier because a launch post looked good. Move the boring, high-volume calls. Leave the calls your product is known for on the model that earns them.

![Charts and spreadsheets on a screen comparing monthly cost across two options](https://images.unsplash.com/photo-1460925895917-afdab827c52f?w=800&q=80)

## How to Test It Without Guessing

Do not decide from benchmark tables. Decide from your own traffic, and do it in a week.

1. **Pick one feature.** Choose the highest-volume call that looks like a good fit from the lists above.

2. **Collect 200 to 500 real inputs.** Pull them from logs, with personal data removed. Include the ugly edge cases, not just the clean ones.

3. **Get ground truth.** Use the answers your current model gave if users accepted them, or have a person label a sample. Fifty good labels beat five hundred sloppy ones.

4. **Run Haiku 5.5 at low and medium effort.** Record accuracy, token counts, latency and cost per call for each.

5. **Set a bar before you look.** For example, within two points of the current model on accuracy, and at least 70 percent cheaper. Decide the bar first so you do not argue yourself into the result.

6. **Ship behind a flag.** Send 5 percent of traffic to the new path, watch quality metrics and user complaints, then step up.

This is the same discipline we recommend in our article on [model routing and LLM cost optimization](/blog/ai-model-routing-llm-cost-optimization). It is dull and it works. If you do not have an evaluation set at all, build one before you change any model, because you will need it again the next time a vendor ships something new. That happens about once a month now.

## Routing: The Pattern That Makes Cheap Models Safe

The strongest use of Haiku 5.5 is rarely a full replacement. It is a router in front of a stronger model.

Here is a simple version. Every request goes to Haiku first, at low effort, with a prompt that asks for an answer and a confidence rating. If the confidence is high and the output passes validation, you return it. If not, you send the same request to a larger model. You pay the small price on every call and the large price only on the hard ones.

The split in your traffic decides the savings. If 80 percent of requests resolve at the small tier, your blended cost is about 80 percent small and 20 percent large. With Opus 5.5 as the large model, that is roughly a 75 percent reduction against sending everything to Opus, before you count caching and batch discounts. If only 40 percent resolve, the savings are far smaller, and the added latency from the second call may not be worth it. Measure the split on your own data.

A few details make routers work in practice. Log which tier answered each request so you can audit quality by tier. Keep the validator strict, because a wrong answer with high stated confidence is the failure you are guarding against. And re-run your evaluation set whenever you change a prompt or a model version, since both shift the split.

![Team reviewing a system architecture diagram on a whiteboard](https://images.unsplash.com/photo-1553877522-43269d4ea984?w=800&q=80)

## What to Do This Week

You do not need a migration project. You need an audit and one experiment.

First, list every place your product calls a model, and write next to each one the monthly token volume and the model in use. Most founders have never seen this table, and it usually surprises them. Second, mark the calls that are short-answer, high-volume and easy to validate. Those are your candidates. Third, run the one-week test above on the biggest candidate. If it clears the bar, ship it behind a flag.

Also check three settings before you touch a model string: your effort level on every call, your prompt sizes against the 100K line, and your cache setup for any long, stable prompt prefix. In many codebases those three fixes alone cut the bill before any model changes.

If you would like help reading your bill, setting up the evaluation set or designing a router that does not hurt your product, that is work we do for founders every month. [Book a free strategy call](/get-started) and bring your current model spend and a list of where your app calls an AI model.

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/claude-haiku-5-5-pricing-subagents-model-routing)*