Anthropic launches Claude Haiku 5.5 at 75% lower cost

Key takeaways

• Claude Haiku 5.5 costs 75% less than its predecessor at $0.10/$0.50 per million tokens, matching OpenAI's GPT-6 Luna pricing.
• The new model introduces effort controls (low, medium, high, xhigh, max) so you can tune cost against intelligence for each task.
• Haiku 5.5 uses a less efficient tokenizer that consumes about 1.25x more tokens on the same prompts, creating a hidden price increase.
• Pricing jumps 5x after 100,000 tokens, making GPT-6 Luna cheaper for longer context workloads.
• The model pairs well with Opus 5.5 in manager-worker patterns where Opus plans and Haiku executes at scale.

What shipped

On October 7, Anthropic released Claude Haiku 5.5 (https://simonwillison.net/2026/Oct/7/claude-haiku-5-5/), a significant update to its smallest, fastest model. The new version costs $0.10 per million input tokens and $0.50 per million output tokens for prompts up to 100,000 tokens. That matches OpenAI's GPT-6 Luna pricing exactly and represents a roughly 90% price drop from the previous Haiku 4.5, which cost $1/$5 per million tokens.

Beyond 100,000 tokens, Haiku 5.5's pricing jumps 5x (https://simonwillison.net/2026/Oct/7/claude-haiku-5-5/) to $0.50/$2.50, while Luna only increases to $0.20/$0.75 at 272,000 tokens. The model is available now on Amazon Bedrock and Claude Platform on AWS (https://aws.amazon.com/blogs/machine-learning/introducing-claude-haiku-5-5-on-aws/).

The previous Haiku 4.5 launched nearly a year ago and had become expensive relative to competitors. Haiku 5.5 closes that gap while adding new capabilities, particularly for agentic workflows.

How it works

Haiku 5.5 introduces effort controls to the Haiku line for the first time. You can set reasoning effort to low, medium (the default), high, xhigh, or max. Testing shows (https://simonwillison.net/2026/Oct/7/claude-haiku-5-5/) the difference is real. A low-effort SVG generation task completed in 7 seconds and cost 0.0936 cents, while the same task at max effort took over 5 minutes but still only cost 3.38 cents.

You cannot disable reasoning entirely. The model always applies at least a low level of effort, which means every call incurs some reasoning overhead compared to purely feed-forward models.

Here is how you test it using Simon Willison's llm tool:

``bash llm install -U llm-anthropic llm anthropic refresh llm -m claude-haiku-5.5 "your prompt here" -o thinking_effort low ``

Haiku 5.5 uses a new tokenizer that is less efficient than the one used by Haiku 4.5. The same long prompt uses around 1.25x as many tokens (https://simonwillison.net/2026/Oct/7/claude-haiku-5-5/) with the new model, which means a hidden price increase even as the per-token cost drops.

The model supports high-resolution images, multi-step tool use, and computer use (browser and desktop automation). According to AWS (https://aws.amazon.com/blogs/machine-learning/introducing-claude-haiku-5-5-on-aws/), it handles agentic coding tasks, can act as a computer use subagent for repetitive tasks, and is suitable for iterating quickly on UI and UX changes across multiple files.

What it changes for builders

Haiku 5.5 makes high-volume AI workflows economically viable in a way the previous version did not. If your application processes thousands or millions of requests per day, a 90% price drop matters.

The effort control gives you a new lever. You can run classification or routing tasks at low effort and save time and money, then dial up to medium or high for summarization or code review. This was not possible with Haiku 4.5.

The model pairs well with Claude Opus 5.5, which AWS positions (https://aws.amazon.com/blogs/machine-learning/introducing-claude-haiku-5-5-on-aws/) as the planning layer. Opus handles complex reasoning and judgment calls, while Haiku executes well-defined subtasks at scale. This is the classic manager-worker pattern, now with tunable effort on the worker side.

Integration is smoother than before. Simon Willison notes (https://simonwillison.net/2026/Oct/7/claude-haiku-5-5/) that the llm-anthropic plugin no longer requires a new release for every new model, which means faster access to future updates.

Gotchas and limits

The tokenizer change is the biggest hidden cost. If you migrate from Haiku 4.5 to 5.5, expect to use 25% more tokens on the same prompts. Run your own comparisons with representative data before committing.

Haiku 5.5 is cheapest under 100,000 tokens. If your use case regularly exceeds that threshold, GPT-6 Luna becomes significantly cheaper. Luna holds its lower pricing up to 272,000 tokens, while Haiku jumps to five times the base rate at 100,001 tokens. Do the math for your workload.

You cannot turn off reasoning. Even at low effort, the model applies some reasoning overhead. If you need the absolute fastest, cheapest inference and your task is simple enough, a non-reasoning model may still be a better fit.

Benchmark scores are higher than Luna according to Anthropic, but the sources (https://simonwillison.net/2026/Oct/7/claude-haiku-5-5/) do not detail which benchmarks or by how much. Treat marketing claims carefully and test on your own tasks.

How we would use it

We would use Haiku 5.5 as the execution layer in multi-agent systems. Opus 5.5 would handle requirements analysis, architecture decisions, and code review. Haiku would generate boilerplate, apply formatting rules, run tests, and handle repetitive file edits across a codebase.

For clients with document-heavy workflows, we would route incoming documents through Haiku 5.5 at low effort for classification and metadata extraction, then send only the high-priority items to a more expensive model for deep analysis.

We would monitor token usage closely during migration. The 1.25x tokenizer penalty is manageable at these prices, but it compounds if you also hit the 100,000-token threshold regularly. We would restructure prompts to stay under that limit where possible.

We would not use Haiku 5.5 for tasks that require extended reasoning or nuanced judgment. Those still belong with Sonnet or Opus. Haiku is for speed and volume, not for hard problems.

Finally, we would use effort controls liberally. There is no reason to run every task at medium effort if low effort works. Start low, measure quality, and increase effort only when results justify the cost.