Most conversations about Claude models start with Opus and Sonnet, because that's where the headline benchmarks live. But a decent share of the AI work running inside Australian businesses right now doesn't need frontier reasoning at all. It needs something fast, cheap, and consistent enough to run thousands of times a day without anyone noticing the bill. That's the job Haiku 4.5 does, and in production it's often the model doing the most actual work, even if it never gets mentioned in a pitch deck.
We build automation for small and mid-sized Australian businesses, and one pattern shows up again and again once a client moves past their first pilot project: the moment they stop routing every request through the biggest available model is the moment their AI spend starts making sense on a monthly invoice. Haiku isn't a fallback for when budget runs out. It's a deliberate choice for a specific class of task.
Where Haiku actually wins in production
Haiku 4.5 is built for high-volume, low-latency tasks where the input is well-defined and the output doesn't need much creative judgement. In practice that covers a surprising amount of the automation work we build for clients in Sydney and Melbourne.
Classification and routing. Sorting inbound emails, support tickets, or CRM leads into categories before a human or a bigger model touches them.
Structured extraction. Pulling names, invoice totals, ABNs, or dates out of PDFs and emails into clean JSON or spreadsheet rows.
First-pass drafts. Short reply suggestions, subject lines, or summaries that a person reviews before sending.
Real-time chat and voice. Anywhere latency matters more than depth, like a receptionist agent answering a phone call or a website chat widget.
High-frequency background jobs. Tagging, deduping, or scoring records inside a nightly batch that runs against thousands of rows.
None of these need a model reasoning through a multi-step problem. They need a model that responds in under a second, gets the format right every time, and doesn't cost more than the task is worth. A support ticket router that takes three seconds to categorise an email is a worse experience than one that takes half a second, even if both get the category right, because the router usually sits in front of several other automated steps that are all waiting on it.
There's also a reliability argument that doesn't get talked about enough. Smaller models with narrow, well-specified tasks tend to be more consistent than large models asked to do the same narrow task, because there's less room for the model to get creative with the output format. When a downstream system is parsing that output automatically, consistency matters more than raw capability.
The economics of choosing the smaller model
This is where the case for Haiku stops being about speed and starts being about money. We recently helped a Sydney logistics client replace a manual invoice-matching process that was costing the business roughly $120,000 a year in admin hours. The automated version runs on Haiku for the extraction and matching step, with Sonnet called only when the match confidence is low. Running that same volume through a frontier model for every single document would have blown out the API bill for no measurable gain in accuracy, because the task itself doesn't need frontier reasoning.
The pattern shows up across almost every automation build we do for Australian SMBs. A tiered approach, cheap model for the routine 80 percent, a stronger model reserved for the hard 20 percent, keeps monthly running costs predictable while still giving the business a fallback for genuinely difficult cases. For a business processing a few hundred documents or conversations a day, that difference compounds fast over a financial year. A retail client we work with in Melbourne runs product tagging and review sentiment scoring on Haiku across roughly 15,000 records a month; the equivalent Opus bill would have made the project hard to justify against the labour cost it was replacing.
There's a second, less obvious saving too: development time. Because Haiku responds quickly, testing and iterating on a prompt during the build phase is faster. When you're running the same prompt against fifty sample documents to check accuracy before going live, the difference between a one-second response and a six-second response adds up to a lot of waiting around during development.
How to decide which tier a task belongs on
Before defaulting to the biggest available model, it's worth running each task through a short checklist.
Does the task require multi-step reasoning, or is it pattern matching against a known format?
Is the volume high enough that per-call cost actually matters to the monthly bill?
Does a human review the output before it goes anywhere important, or is it acting autonomously?
Would a wrong answer be mildly annoying, or would it create a compliance or Privacy Act problem?
Tasks that are high-volume, well-defined, and reviewed by a person are strong Haiku candidates. Tasks that touch financial decisions, legal interpretation, or anything customer-facing without review still belong on Sonnet or Opus, at least until the pattern is proven safe to hand down a tier. The safest way to move a task down a tier is gradually: run Haiku alongside the existing model for a couple of weeks, compare outputs on real production data, and only cut over once the accuracy gap is genuinely negligible for that specific task.
A worked example: escalation-only routing
One pattern we reuse across almost every client build is escalation-only routing. Haiku handles the first pass on every request, whether that's an inbound email, a chatbot message, or a document upload. If Haiku's confidence score comes back low, or the request matches a pattern flagged as sensitive, it gets escalated automatically to Sonnet or Opus for a second look. In practice this means an Australian business ends up paying frontier-model prices for maybe 10 to 20 percent of its total volume, while the bulk of the work runs at a fraction of the cost with no drop in the quality a customer actually experiences.
Building this kind of tiered model routing isn't complicated once someone has mapped out where each task actually sits, but most businesses haven't done that mapping yet. If you want a second set of eyes on where your automation spend is going and which tasks could move to a cheaper, faster model, book a session with us and we'll walk through it together.
