Most Australian teams default to the biggest, most capable Claude model for every task out of habit, then wonder why the bill is higher than expected. Right-sizing is the discipline of matching model tier to task difficulty. This piece is narrowly about the cost trade-off between Haiku and Opus specifically, not a full model-selection guide across the whole line-up -- if you want the broader by-job-type picture across all four tiers, that's a separate read.
Where Haiku genuinely wins
Haiku is Anthropic's fastest, cheapest tier, and for a specific class of task it's not just adequate, it's the better economic choice even when Opus is available. Classification tasks (is this email a complaint, a lead, or spam), short extraction jobs (pull the invoice number and total from this text), and high-volume, low-ambiguity formatting work are all places where Opus's extra reasoning depth buys nothing, because there's no reasoning depth needed to get the answer right.
Per-request cost on Haiku typically runs a fraction of Opus for equivalent-length inputs, which matters when volume is in the thousands per month
Latency is materially lower, which matters for anything customer-facing or in a live chat flow
For tasks with a small, well-defined answer space, accuracy differences between Haiku and Opus are often negligible in practice
Reserving Opus for the genuinely hard 10-20% of a workflow, rather than all of it, is usually where the real savings live
Where Opus still earns its higher cost
Anything involving multi-step reasoning, drafting nuanced client-facing content, or synthesising information across a long document is where Opus's extra capability shows up in output quality, not just benchmark scores. A Sydney law firm running Haiku on a contract-clause extraction task, then routing only ambiguous clauses to Opus for interpretation, cut their monthly API spend by roughly 55% compared to running everything through Opus, without a measurable drop in the quality of the final review.
A practical routing pattern
Run a cheap classifier pass first, often Haiku itself, to sort inputs by difficulty, then route only the genuinely hard cases to a stronger model. This two-tier pattern is straightforward to build and typically pays for its own setup time within the first month for any workflow processing more than a few hundred items monthly. For a business spending $600 a month on a single-model Opus workflow, this kind of routing commonly brings that down to $250 to $350 without touching output quality on the cases that actually need the stronger model.
Testing before you commit
The mistake to avoid is routing by habit rather than by measurement. Pull 50 to 100 real examples from your workflow, run them through both Haiku and a stronger model, and compare the outputs by hand before deciding where the split should sit. The right ratio is specific to your task and your tolerance for the occasional miss, not a universal number you can borrow from someone else's blog post, including this one.
If you're not sure where your own workflow sits on this trade-off, get in touch through /contact and we'll help you test it against your actual volume and inputs.
What breaks if you route too aggressively toward Haiku
The failure mode of over-optimising for cost is routing genuinely ambiguous cases to Haiku and getting confidently wrong answers back, rather than the honest uncertainty a stronger model would have flagged. This is worse than simply paying more, because a wrong classification that goes unnoticed can cascade into a downstream process making the wrong call. The fix isn't avoiding Haiku, it's building a fallback: when Haiku's own confidence signal is low, or when an output fails a simple sanity check, escalate automatically to a stronger model rather than accepting the cheap answer by default.
For a Melbourne insurance broker sorting incoming claim emails by urgency, this fallback pattern caught roughly 8% of cases that Haiku alone would have misclassified, at the cost of routing that same 8% to Opus for a second pass. The net effect was still a substantial saving over an all-Opus approach, with none of the downside of a confidently wrong triage decision slipping through unnoticed into the claims queue.
It's also worth revisiting the split periodically rather than setting it once. Model pricing and capability both shift over time -- a task that needed Opus eighteen months ago may run perfectly well on a newer, cheaper Haiku release today. Building a quarterly ten-minute review of the routing split into your workflow's maintenance schedule catches these shifts before you've spent another six months paying for capability you no longer need for a task that's stayed the same difficulty the whole time.
