Claude Haiku 5.5 vs Sonnet 5.5 for Support
Compare Haiku 5.5 and Sonnet 5.5 on support-ticket routing with a fixed policy and synthetic cases. Measure unsupported answers, escalation and review effort.
Published · 5 min read
At a glance
- Evaluate routing and drafting as separate tasks.
- Include unknown, conflicting and policy-exception cases.
- Choose from reviewed results rather than provider benchmarks.
Choose by the support job
Anthropic introduced Claude Haiku 5.5 on October 7, shortly after Sonnet 5.5. Its announcement positions Haiku for narrower tasks and describes a different role for larger models. That gives a useful starting hypothesis: test Haiku on a bounded routing task and compare Sonnet on cases needing more interpretation. It does not establish the result for your policy. Read the Haiku announcement.
This article provides a controlled comparison plan, not measured model results. The target is a draft support workflow with human review. No customer messages should be sent during the exercise.
Define routing before response writing
Create a short fictional policy with three categories and an escalation rule. For example, route password-help questions to account support, delivery-status requests to order support and policy exceptions to a person. Define unknown as an acceptable result when evidence is missing.
Separate classification from drafting. A correct category can accompany an unsupported answer, while a courteous draft can hide a wrong route. Give each stage its own checks. Keep the policy version fixed across both model trials so changes in the rules do not masquerade as model differences.
Build a balanced synthetic fixture
Write straightforward tickets, ambiguous tickets and edge cases. Include a message with two requests, one with missing order details and one asking for an exception the policy does not permit the assistant to grant. Use fictional names and no genuine customer identifiers.
Write expected labels before running the models. Ask a colleague to review unclear cases if possible. If people cannot agree on the correct route from the policy, repair the policy or mark the case ambiguous. A model comparison cannot resolve a missing business decision by itself.
Use the same task contract
Apply the same instructions and output fields in both accessible environments. Record model identifiers, date and relevant settings. Keep a separate column for any correction you give after the initial answer.
Classify each synthetic ticket using only this policy version.
Return category, evidence phrase and escalation reason.
If the policy cannot resolve a case, choose human review.
Draft a reply only from approved facts. Do not promise refunds,
account changes or delivery dates that the source does not give.
Do not send anything.
Score errors by their consequences
Count incorrect routes, missed escalations, unsupported commitments and unnecessary escalations separately. A high overall accuracy figure can hide the error you most need to prevent. Inspect every policy-exception case even if the total score looks good.
Record the time required to correct drafts. Compare the current provider charges for the actual workload, including retries and any extra review stage. Do not assume a cheaper initial request produces a cheaper finished answer. Keep a plain cost worksheet rather than a price copied into the article.
Choose a simple routing policy
If your results support it, use the narrower model for cases with clear evidence and route uncertain cases to a stronger review path or a person. Do not use an uncalibrated confidence number as the only escalation rule. Prefer observable conditions such as conflicting facts or an unsupported request.
Start with a draft queue and review a new sample after a model or policy change. The n8n triage workflow covers the automation structure, while AI automation tools can help you choose an implementation environment. Keep model choice separate from permission to act on a customer account.
Worked example: one ticket contains two jobs
Create a fictional message asking where an order is and requesting an exception to a return policy. The expected response should identify the order-support component and preserve the exception for human review. If your routing system supports only one destination, decide the precedence rule before comparing models.
Run the same case through Haiku and Sonnet with the same policy and fields. Inspect the category and the draft separately. A friendly reply that promises an exception fails the commitment check even if the route is acceptable. A conservative escalation may be appropriate when the policy explicitly requires it, so do not penalize escalation merely because it reduces automation.
Add a similar ticket with no exception request. This checks whether the workflow overgeneralizes from a difficult case and escalates everything. Keep the expected answers tied to the policy rather than the model’s own description of what good support should do. These hypothetical examples define a useful fixture; they are not comparative test results.
Questions before choosing a routing model
Can a larger model fix an incomplete policy? It may produce plausible interpretations, but your organization still needs to decide the missing rule. Is the shortest response always more efficient? Include correction time and downstream review before judging finished-task effort.
Should confidence decide every escalation? Use observable policy conditions and your own validated thresholds where available. A self-reported confidence number is not automatically calibrated. What if one model routes well but drafts poorly? Keep the stages separate and decide whether a different drafting path is worth the added complexity. Your final decision should identify the cases that can stay in the simple path and those that require review, with a clear way to revisit the boundary.
Sources and review notes
Reviewed on 17 October 2026. This is a documentation-based editorial guide with illustrative exercises, not a report of hands-on product testing. Check provider pages for current access, prices, terms and limits.
01 Choose a tool: compare the fit. 02 Use a prompt: start with context. 03 Check the result: keep your judgment.
Did this help you complete your task?
Tell us what needs improving. No account or private output required.
Report incorrect information or a broken linkReview evidence
Documentation-based review · 2026-10-17
Primary documentation reviewed on 17 October 2026. Examples and evaluation methods are illustrative; no hands-on comparative performance results or measured search-volume claims.
