Claude Haiku 4.5,
and when small wins.
Most people pick a model once and never think about it again, usually the biggest one available to them. That habit is expensive, and on a decent share of everyday work it is also slower.
Haiku 4.5 arrived in October 2025 as Anthropic’s small model, priced at $1 per million input tokens and $5 per million output. Anthropic’s claim at launch was similar coding performance to Claude Sonnet 4 at one third of the cost and more than twice the speed, with 73.3% on SWE-bench Verified. The number that matters most for how you work, though, is the speed one.
Speed changes which workflows are possible
A cost saving is nice. A latency saving changes what you are willing to build. Anything with a person waiting at the other end, a chat assistant, a support agent, pair programming, has a threshold beyond which people stop using it. Halving response time moves tasks across that line, which is why Anthropic pitched it at real-time work and at making multi-agent projects and rapid prototyping feel responsive. A task you would never automate at thirty seconds a call becomes obvious at three.
The context window is smaller, and that is the real constraint
Haiku 4.5 carries a 200,000 token context window and up to 64,000 tokens of output, where the newest larger models reach a million. For most single documents and most conversations, 200,000 is more than enough. For anything that involves reading a large codebase or a folder of long reports in one pass, it is the wall you will hit first, and no amount of cost saving compensates.
Check the knowledge cutoff before you trust a factual answer
Haiku 4.5 has an earlier reliable knowledge cutoff than the newer models. That is fine for reformatting, extraction, classification and code you supply yourself. It is not fine for questions about recent events or recently changed APIs, where a confident answer from a model with older knowledge is worse than no answer at all.
What it is genuinely good at
High-volume, well-specified, repetitive work: pulling structured data out of unstructured text, triaging or routing incoming messages, first-pass classification, quick edits inside a codebase where you already know what you want. Work where you can describe the output precisely and check it quickly. The common pattern in teams running Claude at volume is a small model doing the bulk of the passes and a larger one handling the cases the small one flags.
Choose per task, not per account
The useful habit is treating model selection as part of the task, the way you would choose whether to write a script or do something by hand. Reach for the larger model when the work involves judgement, novelty or a very large context. Reach for Haiku when the work is defined and the volume is the problem. Nobody uses a lorry for the weekly shop, and nobody should be paying frontier prices to reformat a list of postcodes.
Take the task you run most often, run it on both, and compare the outputs side by side rather than trusting your instinct about which should win. If the smaller model handles it, you have made every future run of that task cheaper and faster in one afternoon. If it does not, you now know precisely why, which is worth something too. Our Claude Code coaching covers this kind of routing for teams running work at volume.
Things people
usually ask.
Model availability differs between the Claude apps and the API, and the line-up changes as new models ship. Check the model picker in your own account rather than relying on an article, including this one.
At the time of writing the current small model is Haiku 4.5. Anthropic has not shipped a Haiku release for every Sonnet and Opus revision, so the small model tends to lag the larger ones by a version.
On tasks that need judgement or long context, yes, noticeably. On defined, repetitive work with a checkable output, often not at all. The honest answer is that it depends on the task, which is why running your own comparison beats reading a benchmark table.