Claude Haiku 5.5 vs Sonnet 5.5: Which of Three Everyday Tasks Can You Downgrade?

I ran three small jobs I do every week on both Claude Haiku 5.5 and Sonnet 5.5, three times each: sorting 30 support messages into categories, pulling fields out of 10 order emails, and boiling a memo down to 3 bullets.

The short version. For classification and field extraction, Haiku can replace Sonnet. On my samples the quality gap was too small to matter. Summaries depend on what the summary is for: Haiku keeps to the word limit better, Sonnet drops fewer facts. Twice, Haiku made the memo sound more certain than the memo did.

The list prices differ by 20x. What I actually paid differed by 4x to 10x. Below are the numbers, the outputs, my call on each task, and a way to rerun the whole thing on your own data.

#Official pricing: a 20x gap on the price list

Anthropic announced Haiku 5.5 on Oct 7, 2026. The model ID is claude-haiku-5-5. The announcement page (https://www.anthropic.com/claude-haiku-5-5) lists these prices, per million tokens, for prompts up to 100k tokens:

Past 100k tokens of prompt, Haiku 5.5 costs $0.50 for input and $2.50 for output. So the $0.10 and $0.50 in the headline are the short-prompt prices. Every test below used prompts of a couple thousand tokens, so they all sit in the short tier.

The official positioning is worth reading before the numbers. It lists summarization, compression, database queries and classification as good fits, the high-volume, cost-sensitive kind of work. It also mentions sub-agents, real-time customer support and browser use. The caveat is that "well-scoped tasks" suit it best, and complex agentic coding should still go to Sonnet 5.5 or Opus 5.5. On Terminal-Bench 4.0 the page shows Haiku 5.5 at 39.2% and Sonnet 5.5 at 70.6%. On OSWorld 2.1 (offline subset) it shows 72.4% against 83.9%. I read those figures through a fetch tool that summarizes pages, and the column order was inferred by the tool, so check them against the original page before you quote them.

What this tells you: Sonnet scores higher on every benchmark the page lists, and Haiku is 20x cheaper. It does not tell you whether your everyday tasks land where the gap is small. So I ran them.

#How I tested

Each conclusion below needs a discount for these conditions:

• Tool: Claude Code in headless mode, claude -p --model haiku (or sonnet), with the system prompt You are Claude, a helpful AI assistant., no tools, no project settings loaded, run in an empty folder
• Models actually used: the modelUsage field in the output shows claude-haiku-5-5 and claude-sonnet-5-5
• Date: Oct 28, 2026 (UTC)
• Runs: 3 per task per model, 18 in total. That is a small sample. It describes what I saw in these runs and has no statistical weight
• Data: all three datasets are made up by me, with the answers fixed before any run. The source is in runs/data.py, and every run's full input, raw output and cost is saved in runs/results/

The test data is written in Traditional Chinese, because I wrote it for the Chinese edition of this article. Quotes from it below are my English translations of the Chinese originals. I did not rerun the experiment in English, so the scores describe Chinese-language inputs. English would likely behave similarly, but I haven't checked.

Made-up data has one upside: I know the right answers. It also has downsides. It is cleaner than real data, and it reflects my own taste in test design. When we get to extraction you'll see that one of my "right answers" was itself wrong.

#Task 1: classify 30 support messages. Haiku scored 29, 28 and 30; Sonnet scored 30 every time

The prompt was short: six categories (login, billing, feature request, bug report, refund, other), 30 messages, and a request to output only a JSON array. Of the 30 messages, 24 have an obvious category. Six are deliberately gray, for example: "After logging in, the payment page goes blank and I can't update my credit card, so this month's charge will probably fail." My answer key goes by the main complaint. This message is about a broken page, so it's labeled "bug report".

Results:

Haiku missed in two places. Message 25, the blank payment page, was labeled "billing" twice. That one is gray, and "billing" is defensible. It just disagrees with my key. Message 12, "Do you offer a student discount?", was labeled "billing" once. That one isn't gray. The key says "other", so this was a real Haiku miss.

Sonnet gave identical results across all three runs, even on the gray cases, and matched my judgment on every one. That doesn't make Sonnet more correct, since I set the gray-case answers myself.

My call: if classification just decides which team gets the ticket, a wrong label costs a manual reroute. One or two misses per hundred is tolerable, and Haiku is enough. If the label triggers something automatic, like a refund or an account suspension, the gray cases shouldn't ride on one model call, whichever model you use. Have the model output a "low confidence" flag as well, and route flagged items to a person. I suspect that works better than paying for the bigger model, but I did not test the flag this time. Try it on your own data.

#Task 2: pull 6 fields from 10 emails. Both models scored 58/60

I made this one harder on purpose. The 10 emails mix Chinese and English, Republic of China (ROC) calendar years, DD/MM/YYYY and MM/DD dates, amounts written in Chinese numerals ("三千五百元整", which means NT$3,500 exactly), totals that are only correct after a discount, and missing fields that should come back as null. The fields: order number, date (converted to YYYY-MM-DD), amount, currency, recipient, and whether it's urgent.

Results: Haiku scored 57, 58 and 58 out of 60. Sonnet scored 58 all three times.

The lost points are nearly identical on both sides, and they all sit in the "urgent" field. Email 8 gave only the subtotal, the discount and the amount due, with no mention of urgency, and my key said false. Email 10 said only that "the amount and recipient aren't decided yet", and my key said false there too. Both models answered null every time. Looking back, my prompt said "fill null for fields not in the email, don't guess", so the models did the right thing and my key was wrong. Haiku had one extra miss in run 1: email 2, an English email that said only "Standard delivery", came back null where my key said false. Same gray area.

So the more accurate statement is this: on the tricky formats I designed (ROC years, day-month order, Chinese numerals, discounts, missing fields), both models got every cell right. What worried me most was Haiku misreading a date like 12/11/2026. All three runs followed the DD/MM/YYYY label in the email and produced 2026-11-12. ROC year 115, August 12, was converted to 2026-08-12 all three times.

My call: extraction is the best candidate for downgrading in this whole test. The more precisely the format is specified, the less the two models differ. If you switch, put two lines in the prompt: "use null when the email doesn't say" and the date order. I believe those two lines carry most of the accuracy, but I didn't remove them and rerun as a control, so I can't be sure.

One experiment I didn't do changes how you should use this. I never removed the "fill null, don't guess" line to see whether either model starts inventing values without it. All I can say is that with the line in place, both models followed it across six fields and ten emails. If your data has more fields or messier formats, try Haiku first. Mistakes can often be fixed by adding one rule, and then you can decide whether to upgrade.

#Task 3: summarize a memo, and this is where they differ

I used a made-up 915-character memo (an evaluation of a cloud backup service redesign) and asked for 3 bullets, no more than 150 characters in total, using only what's in the memo and adding no judgment. I planted 10 key facts in it: restoring 200 GB takes 6 hours 40 minutes, the decision to pilot with 200 customers for 8 weeks, a budget cap of NT$600,000, a report due by Oct 31, and so on.

Length, counted as characters with whitespace and line breaks removed, punctuation included. The memo and summaries are in Chinese, so the limit is Chinese characters:

Haiku stayed under 150 all three times. Sonnet went over all three times, by as much as 81. "No more than 150" is a plain constraint, and Sonnet missed it every run. That surprised me. I don't know why, and can only report that these three runs did.

Key facts captured (out of 10, accepting variants like "600k" or "NT$600,000"): Haiku got 8, 9 and 8. Sonnet got 10 every time. But Sonnet bought those hits by going over the limit, while Haiku had less room to fit things in.

What matters more than the hit count is whether the content drifted. The memo says: "Customer support reports that 41% of churned customers contacted support before leaving, and the most common complaint was slow restores."

• Haiku run 1: "41% of churned customers contacted support, most often complaining about slow restores", which matches the memo
• Haiku run 2: "41% of churned customers complained about slow restores"
• Haiku run 3: "41% of churned customers complained that restores were slow"

(These are my translations of the Chinese summaries.) Runs 2 and 3 compressed "among the churned customers who contacted support, the top complaint was restore speed" into "41% of churned customers complained about slow restores". The meaning got pushed to sound more certain. The support lead in the memo specifically warned afterward that "no data shows restore speed is the only reason for churn, and price also came up". Neither of those two Haiku summaries carries that caveat.

Sonnet isn't clean either. In run 2 it wrote "restore speed is a main cause", and the memo makes no claim about a "main cause". In the same run, though, it did carry over the support lead's caveat. In run 1 it cited the product manager's 4.5% churn estimate and added "not verified by finance", a note that is in the original.

My call: whether to downgrade summaries depends on whether anyone will check them against the source. For a daily digest you read yourself, or a message preview in a chat, Haiku is fine and follows the format better. If the summary feeds a decision or gets forwarded to people who haven't read the source, this kind of "sounds more certain than the source" error is hard to spot, and Sonnet is the safer pick. Another option is to add a line to the prompt: "after each bullet, quote the sentence from the source it comes from", so a reader can trace it back. I did not test whether that works on Haiku.

#What I actually paid: 4x to 10x, not 20x

These are the total_cost_usd values reported by Claude Code, averaged over 3 runs. The output token counts below come from the modelUsage it reports and include thinking tokens. The cost includes the roughly 2,100 tokens of system prompt that Claude Code always adds, so it runs a little above what my own input alone would cost.

The ratios are well under the 20x on the price list. The reason is output tokens: Haiku 5.5 thinks more. On classification, Haiku's three runs produced 1,310, 1,701 and 1,634 output tokens (thinking included), against 425, 329 and 308 for Sonnet. On summarization the gap was larger: Haiku used 3,604, 2,035 and 2,603, while Sonnet used 308, 279 and 272. Haiku's unit price is far lower, but it spends several times as many tokens, and the two effects partly cancel. The announcement page also says Haiku 5.5 uses somewhat more tokens than the previous generation. What I saw is a bigger gap than "somewhat", but that comparison is against Sonnet, not Haiku 4.5, which I did not test.

Two more warnings. First, the costs are noisy. Sonnet's first classification run cost $0.01415 and the next two about $0.0084. My guess is prompt-cache writes, though I didn't check, so treat the ratios as orders of magnitude. Second, I did not test Haiku 5.5's effort setting (Low through Max). If lowering effort trims the thinking tokens on summaries, the real gap would move closer to the list-price gap. That's worth trying yourself.

A rough scale estimate from these numbers: one classified message costs about $0.000048 on Haiku and $0.000345 on Sonnet (the 30-message batch cost divided by 30). At 100,000 messages a month, that's about $4.80 against $34.50. This scales the 3-run average directly. Real traffic will differ in caching and length.

#What to downgrade and what to leave alone

Across these 18 runs, this is what I would do.

Switch to Haiku directly:

• Data extraction with clear rules: both models did equally well here, and the cost per call was about a tenth (10.4x measured)
• Classification, as long as a wrong label means a manual reroute rather than an automatic action: Haiku's misses were on gray cases plus one plain error
• Summaries and previews for your own reading: it follows the format better than Sonnet did

Add a safeguard before switching:

• Summaries that get forwarded: require the source sentence for each bullet, or spot-check
• Classifications that trigger actions: add a low-confidence flag and send those to a person

Leave alone for now:

• Coding and multi-step agent work. Anthropic's own Terminal-Bench 4.0 numbers are 39.2% against 70.6%, and the page says plainly that complex agentic coding should stay on Sonnet 5.5 or Opus 5.5. I didn't test coding, so my results can't back Haiku there
• Work that depends on noticing what the source doesn't say. This is my suspicion: Haiku's summary drifted twice and Sonnet's run 2 drifted on "main cause", so neither is perfect. An example is checking whether a contract leaves out a clause

#Try Haiku first, escalate if unsure: working it out with my numbers

I didn't test this routing setup, but my measured costs can tell you whether it would pay off. Say every item goes to Haiku first, and the ones Haiku flags as low confidence get rerun on Sonnet. For classification, a Haiku batch cost $0.00144 and a Sonnet batch $0.01034. If a fraction p of items escalates, the average batch cost is $0.00144 plus p times $0.01034. At p = 20% that's about $0.0035, one third of the all-Sonnet cost. It takes p near 80% before it matches running everything on Sonnet.

Two assumptions here are unverified. First, Haiku can actually flag the items it is unsure about. I didn't ask it for a confidence value this time, so I don't know how accurate its flags would be. Second, the escalated items have to be sent again in full, and if each item is long, that resend has its own cost. So what I would do first: take 30 of your own samples, ask Haiku to output confidence: low|high on each, and check whether the low-confidence ones are the ones it got wrong. Then decide on routing.

#Rerun it on your own data in about 15 minutes

My data is made up and yours isn't, so the most useful thing you can do is repeat this on your own samples.

1. Pull 30 items from real work and write the answer key yourself first. Include gray cases. That's where the two models will disagree
2. Feed your current prompt, unchanged, to both models, 3 runs each. A single run won't show how stable it is
3. Score against the key with a script or by eye, and record the cost. If you use Claude Code, add --output-format json, and the output includes total_cost_usd and modelUsage
4. Log errors in two buckets: plain errors and gray-area errors. If a task has many plain errors, don't downgrade it
5. If the errors cluster in gray areas, try writing the judgment rule into the prompt (my "use null if missing" line is an example) and compare again

A command template (run it in an empty folder so it doesn't pick up project settings):

claude -p --model haiku \
  --system-prompt "You are Claude, a helpful AI assistant." \
  --tools "" --setting-sources "" \
  --output-format json < prompt.txt

Swap haiku for sonnet for the control.

#What this test didn't answer

• Three tasks, 3 runs each, made-up data that is cleaner than real data
• Test inputs are in Traditional Chinese and I did not rerun in English
• I didn't test effort settings, long prompts (the over-100k price tier), or languages other than Chinese
• I didn't test the "Haiku first, escalate to Sonnet" routing, only suggested it
• I didn't compare against Haiku 4.5, so "how much better than the last generation" can only cite the official numbers
• The official benchmark table came through a summarizing tool, so the column order needs checking against the original page
• I counted summary length as characters with whitespace removed. Other counting methods (say, excluding punctuation) would make Sonnet look like it overshot by less, but all three runs still came out over 150

#FAQ

How big is the price gap between Haiku 5.5 and Sonnet 5.5? The list price (prompts up to 100k tokens) is $0.10 against $2.00 for input and $0.50 against $10.00 for output, a 20x gap. In my three tasks the actual cost gap was 4.4x to 10.4x, because Haiku used more output tokens.

Which tasks can move to Haiku 5.5? In this test, rule-clear data extraction scored 58/60 on both models, and classification scored 28 to 30 for Haiku against 30 for Sonnet. For summaries, Haiku follows length limits better and Sonnet drops fewer facts, so it depends on the use.

Can I use Haiku 5.5 for coding? I didn't test it. The announcement page shows Terminal-Bench 4.0 at 39.2% against 70.6%, and recommends Sonnet 5.5 or Opus 5.5 for complex agentic coding.