Claude Haiku 5.5 vs Sonnet 5.5 vs Opus 5.5: What Real Tests Cost

Overview

Short answer: on scoped coding jobs with a clear finish line, Claude Haiku 5.5 did the same work as Sonnet 5.5 and Opus 5.5 for a fraction of the price. It made the same bug fix as Opus for 1.3 cents instead of 43 (33 times cheaper), passed a 26-test implementation task at every effort level, and documented 56 React components as accurately as an Opus-led team of subagents for 14 cents instead of 85. It gets expensive in one specific way: prompts over 100,000 tokens cost five times more, and an agent that reads a whole repo into one conversation crosses that line fast.

I ran these tests on October 16 and 17, 2026 in Claude Code, headless, with every API request logged. Every time, cost and pass rate below is from my own runs unless I name another source. How I tested, and the limits of a test this size, are at the end.

New to effort levels, subagents or context windows? My glossary of 75 Claude concepts defines each one in a line: Claude Concepts

Haiku 5.5 pricing and the 100k token tier

Haiku 5.5 has two prices. Per Anthropic's launch page, prompts up to 100,000 tokens cost $0.10 per million input tokens and $0.50 per million output tokens. Over 100,000 tokens, the same model costs $0.50 in and $2.50 out, five times more. Sonnet 5.5 is $2 in and $10 out at any length, so a short Haiku request is 20 times cheaper per token than Sonnet.

Anthropic says prompts up to 100,000 tokens made up around 90% of requests to the previous Haiku. That fits summaries and classification. It does not fit a coding agent. By the time Claude Code has loaded its system prompt, the tool definitions, your CLAUDE.md and a few files, one request is already big: in my smallest test, the largest request from each model was 58,000 to 64,000 tokens. Keeping your project instructions short is part of keeping Haiku cheap: How to Write an AGENTS.md File for Design Projects

Haiku 5.5 is also the first Haiku with an effort setting (low, medium, high, xhigh and max), so you choose how long it thinks. Test 2 measures what that buys.

The results at a glance

Every run of every test passed. The differences were cost and time. Test 1 shows the median of three runs; tests 2 and 3 show the average of two (one for Haiku alone in test 3); test 4 is one run each.

Test 1: the same bug, three models

The repo is a finance dashboard I built (React and Vite, 89 files). I broke one function on purpose: the net worth history picks each account's oldest balance snapshot instead of the newest, so 2 of 7 tests fail. The prompt was one sentence: npm test fails, find and fix the bug, do not modify any test file. Three runs per model, default effort.

All nine runs made the same one-line fix, flipping a sort order in calculations.ts, and none touched a test file. Every model took four or five turns. Opus skipped the edit tool and patched the line with sed.

Haiku 5.5, 12.5 s

$0.013

Sonnet 5.5, 10.6 s

$0.21

Opus 5.5, 23.6 s

$0.43

I expected Haiku to take more steps and hide them behind cheap tokens. It didn't. On a scoped bug with a failing test, all three models did the same work, so the only real difference was the price per token: Haiku was 16 times cheaper than Sonnet and 33 times cheaper than Opus. Sonnet was the fastest.

Test 2: does higher effort make Haiku better?

A harder task: a new budgeting module with four functions and 26 tests written up front, including edge cases around month boundaries. The prompt asked for an implementation that passes every test without touching the test file. I ran Haiku at all five effort levels, two runs each, against Sonnet at its default medium effort.

Low effort passed everything. I expected it to miss an edge case, and it didn't. That turns the effort ladder into a tax: each step up added time and money and nothing else. Max effort cost about 8 times as much as medium and took about 5 times as long, for the same 26 green tests. Part of that is the tier, because max effort pushed 7 or 8 of each run's 12 or 13 requests over 100,000 tokens.

Haiku at max was still cheaper than Sonnet at medium ($0.17 against $0.27), but about 8.5 times slower. On this evidence, Haiku 5.5 is a low or medium effort model. Turn the effort up when a run fails at medium, not by default.

Test 3: Opus with Haiku subagents vs Haiku alone

This is the setup Anthropic recommends: a big model leading, Haiku doing bounded work underneath. The task was to document every React component in the repo (56 files) as JSON: the component name, a one-sentence description and its props. I scored each run against the names and props parsed from the source. Three setups: Opus alone, Opus delegating the reading to Haiku reader subagents, and Haiku alone.

All three covered 56 of 56 files and named every component correctly. Opus alone cost $0.99 and took 61 seconds, with a 91% props match. Opus orchestrating nine Haiku subagents cost $0.85 and took 83 seconds, with 95%. Haiku alone cost $0.14 and took 65 seconds, also with 95%.

The recommended pattern saved 14% and ran 35% slower. The orchestrator does not get cheaper: Opus still planned the split, held every subagent's findings in its own context and wrote the file. Priced at list rates, the nine Haiku readers cost about 4 cents between them and Opus cost about 80 cents to supervise them.

Haiku doing the whole job alone was 7 times cheaper than Opus alone, at the same accuracy as the subagent setup and about the same wall clock.

Set the subagent model explicitly

Per Claude Code's subagent docs, a subagent's model comes from, in order: a model Claude passes for that call, the model field in the agent's file, the CLAUDE_CODE_SUBAGENT_MODEL environment variable, and finally the main conversation's model. So if your agent file has no model line and nothing else sets one, an Opus session runs its helpers on Opus, and you pay Opus prices for the grunt work.

The fix is one line in the agent's frontmatter: model: haiku. My reader agent for test 3 had tools limited to Read, Glob and Grep, and that model line. If you are building your own agents and skills, my guide to Claude skills for designers covers where these files live: Claude Skills for Designers

Test 4: what the 100k tier does to a real bill

A bigger repo this time: a Nuxt app with about 300,000 tokens of source. The task was to read every file and write an architecture doc. I ran Haiku on its own and Haiku delegating each directory to a subagent, one run each. Read this as a demonstration of the pricing, not a benchmark. I checked that each run wrote the doc; I did not grade the docs for quality.

Haiku alone did what a model with a large context window does: it read everything into one conversation. Its largest single request was 467,516 tokens, 6 of its 8 requests were over the 100,000 line, and the run cost $0.53. The same tokens priced at the under-100k rate would have cost $0.13. The tier made the run about 4 times more expensive.

The subagent version kept the main conversation smaller: 63 requests, the largest 137,115 tokens, $0.43. That is about a fifth cheaper, and 7 requests still crossed the line, because even one directory of this repo is big.

Haiku's price is ten cents per million input tokens only while each request stays under 100,000 tokens. Hand it a whole repo in one context and you are on a different price list.

When to use Haiku, Sonnet or Opus

This is how I would split work across the three models after these runs. Each pick traces back to a result above.

Two habits matter more than the model choice. Give Haiku whole bounded jobs, not just crumbs from an expensive orchestrator: the biggest savings in my tests came from Haiku doing an entire task alone. And keep each request small, because the 100k tier is where a cheap run stops being cheap.

For UI design the question is different, since taste matters more than cost per token. My take on picking a model for interface work is in the Fable 5 guide: Claude Fable 5 for UI Design: Beautiful Output Every Time If you design in Claude Design rather than Claude Code, the same model picker drives how fast you burn your plan's limit: Claude Design Pricing and Limits (October 2026)

How I tested

• Claude Code 2.1.302, headless (claude -p) with stream-json output so every API request's token usage was logged. Default effort unless stated. Each run started from a fresh copy of the repo.
• Models: claude-haiku-5-5, claude-sonnet-5-5 and claude-opus-5-5. Tests 1 to 3 used the 89-file React dashboard; test 4 used a Nuxt app with about 300,000 tokens of source.
• Runs: test 1, three per model; test 2, two per effort level; test 3, two per Opus setup and one for Haiku alone; test 4, one per setup. That is small. Treat these as hands-on evidence, not a leaderboard.
• Scoring: tests 1 and 2 ran vitest and checked that the test files were byte-for-byte unchanged. Test 3 compared each component's name and props with the source (the props score is set overlap). Test 4 only checked that the doc was written.
• Costs: tests 1 to 3 use Claude Code's own reported cost per run. For runs that stayed under 100,000 tokens it matched my per-request recalculation from list prices. For the Haiku runs that crossed the line it ran higher (test 2 at max effort: $0.17 against $0.13), so I report the higher number. Test 4 uses my per-request recalculation, because which side of the line each request lands on is the point of the test; Claude Code's readout for those two runs was $0.59 and $0.40.
• Vendor facts: the price table, the 90% of requests figure and the guidance that Sonnet and Opus remain better for complex agentic coding come from Anthropic's Haiku 5.5 launch page. Subagent model resolution comes from Claude Code's subagent docs.

FAQ