AI release analysis
Claude Opus 5.5 and Haiku 5.5: split the workload
Should the model investigating a difficult support case also label every incoming message? The Claude Opus 5.5 and Haiku 5.5 releases give product teams a reason to revisit that choice. A smaller model may handle a tightly defined step, while a larger one takes on the work that needs more interpretation.
The release sequence, checked on 17 October
Anthropic announced Opus 5.5 on 22 September 2026, positioning it for complex work with improvements in performance, communication and operating efficiency. Sonnet 5.5 followed on 28 September as a faster option for well-scoped everyday work. These descriptions come from Anthropic's launch materials, rather than a Rubix comparison test.
Haiku gives the smaller jobs more attention
Haiku 5.5 arrived on 7 October. Anthropic describes it as a small model for high-volume work such as classification, summaries and compaction, and introduced an adjustable effort setting for this Haiku generation. The announcement also distinguishes its narrow-task role from the more complex agentic coding work suited to larger models.
Look for a step with a small input and an answer you can check: choosing from five approved queue labels, for instance. That's a manageable place to evaluate Haiku. Replacing the model across an entire support workflow would make it much harder to see where quality changed.
Route by task before routing by confidence
In a hypothetical support product, a message asking for an invoice might go straight to a billing queue. A complaint that two account records disagree needs investigation. Define those task types first, then test a model for each. Keep a path to a stronger model or a person when the request doesn't fit.
A model saying 'I'm confident' isn't enough to select that path. Check things the application can verify: an allowed category, the required fields and a source that supports the answer. Give the model a way to leave the result unresolved when the evidence is missing.
| Example job | Candidate evaluation | What stays outside the model's authority |
|---|---|---|
| Tag an incoming request | Small model against an approved category set | Access to records beyond the authenticated account |
| Summarize supplied documents | Small or mid-size model with source checks | Deciding that an absent fact must be true |
| Investigate conflicting records | Stronger model with a reviewable evidence trail | Resolving a consequential business decision alone |
| Change a live customer record | Application validation and authorized approval | Granting its own permission to write |
Every extra route adds another handoff
A system with several models can lose information between steps. The first summary might omit the detail the second model needs. A retry may run a different route. A classification change may send the same request to two queues. Keep the original input available under the correct permissions and preserve the decision history.
Someone also has to maintain the router. Each model change introduces another combination to evaluate, and each fallback adds a failure to diagnose. If volume is low or the task boundaries keep changing, one model may be a less expensive first release overall.
Rubix Labs' advice is to introduce routing when there is a specific job to move and evidence that the change helps. We currently recommend Astra as a starting point for complex agentic work; that studio preference leaves room to evaluate Claude's smaller models for bounded jobs. We have not published a cross-vendor result that establishes the best combination.
Compare the cost of a completed job
A lower per-token price can be useful, but it is only part of the bill. Count repeated calls, fallback requests, retrieval, verification and human correction. Include the time the product spends waiting for all those steps. A cheaper first answer may need a more expensive second attempt.
Build a small evaluation around the actual task boundary. Keep examples of ambiguous inputs, invalid outputs and legitimate requests the model declines. Record which route ran and why, so a quality change can be traced to the relevant model or routing rule.
Keep the routed version only if it finishes the same jobs reliably and the saving survives review, retries and maintenance. A cheaper first call won't help if the team spends its afternoon fixing what happened afterwards.
