When Should You Use a Cheaper AI Model?
Anthropic has just released Claude Haiku 5.5, and it costs $0.10 per million input tokens. That's a tiny fraction of what the biggest models cost, but those bigger models are still noticeably better at the hard stuff.
So which tasks actually need the smartest model, and which ones can you hand to something cheaper? In this guide, we'll compare cost, speed and capability, then go through which tasks fit where, so you can get a feel for picking the cheapest model that's still good enough. Let's dive in.
How big is the price difference?
Haiku 5.5 costs $0.10 per million input tokens and $0.50 per million output tokens. For comparison, Sonnet 5.5 is $2 and $10, Opus 5.5 is $4 and $20, and Fable 5.1 is $10 and $50.
Per token, Haiku is 20 times cheaper than Sonnet, 40 times cheaper than Opus and 100 times cheaper than Fable. For comparison, Haiku 4.5 was $1 and $5, so the cheap end has got a lot cheaper.
There are a couple of things to keep in mind, though. Haiku's prices only apply to prompts up to 100K tokens, and anything longer is billed at $0.50 and $2.50. It also uses a newer tokenizer that turns the same text into roughly 30% more tokens than Haiku 4.5 did, so it's a little less cheap than the price list suggests.
Speed is harder to pin down with numbers, but smaller models respond faster, and Anthropic pitches Haiku as its fastest model for work you run over and over. If someone is sitting there waiting on the response, like a chat reply, that matters as much as the price.
On capability, the bigger models are better, and that's what you're paying the extra for.
Why we default to the smartest model
When you're building something new, it makes sense to reach for the best model available. You want to know whether the idea works at all, and you don't want to be wondering whether a bad result came from your prompt or from the model.
That's absolutely fine while you're prototyping. The problem comes when the prototype turns into a feature that runs thousands of times a day, and nobody goes back to look at which model it's using.
Let's put some numbers on it. Imagine you're classifying 50,000 support tickets a month, and each one takes around 800 input tokens (your instructions plus the ticket) and returns about 100 output tokens. That's 40 million input tokens and 5 million output tokens a month, which comes to roughly $6.50 on Haiku, $130 on Sonnet, $260 on Opus and $650 on Fable.
These are rough numbers. They ignore prompt caching (which would bring the input cost down on every model) and thinking tokens (which push the output cost up). Even so, tagging tickets on Fable costs a hundred times what it does on Haiku, and Haiku can do the job.
Cost per task
Price lists compare models per token, but it's more useful to think about how much it costs to get a task done correctly.
Behind the scenes, a cheaper model that gets something wrong costs you more than the failed request. You pay for the retry, and in an agent that can mean extra turns spent reading the same files again. Then there's your own time spent spotting the mistake and fixing it.
This works the other way too. Anthropic's own cost guidance points out that a bigger model running at a lower effort level can sometimes finish a task for less than a smaller model, because it gets there in fewer steps. Effort is a setting on the current Claude models that controls how much the model thinks before it answers, and it's worth trying a lower one before you switch models at all.
I'd also compare models on your hardest examples rather than your typical ones. On an easy task, every model looks about the same and the cheapest one looks best, so it's the hard cases that tell you whether the cheaper model holds up.
What a cheap model handles well
The tasks that suit a cheaper model tend to have a few things in common. They're clearly defined, the model has everything it needs in the prompt, and it's easy to tell whether the answer is right. Here are the ones I'd hand to Haiku first.
Classification and routing
This covers things like tagging support tickets, detecting spam, deciding which queue a job goes on, or even deciding which (more expensive) model should handle a request. The model is picking from a short list, so there isn't much room for it to go wrong.
If you're calling the API yourself, pair this with structured output, which constrains the response to a schema you pass in. Give it a list of categories, and the model can only come back with one of them, so there's no paragraph of explanation to parse and anything that does come back wrong is easy to catch.
It's also a good place to turn effort down to low, since sorting a ticket into one of a handful of categories doesn't need much thinking. Haiku 5.5 is the first Haiku model to support effort levels, and it defaults to medium if you don't set one.
If you're already running something like this on Opus, switching usually means changing the model string to claude-haiku-5-5 and nothing else, so it's easy to try.
Summarisation
Summarising a long thread, a pull request, a changelog or a meeting transcript is something smaller models are good at. All the information is there in the prompt, and the model only has to condense it rather than work anything out.
Saying that, if a summary needs real judgement about what matters (like summarising the findings of a security review), I'd step up a tier.
Extraction
Pulling structured data out of messy text is another good fit, like names and amounts from an invoice, dates from an email, or fields from a form someone filled in badly. Pair it with structured output, and you can validate every result before it goes anywhere near your database.
Simple code changes
Plenty of coding work is mechanical once you know what needs doing. That includes renaming something across a few files, adding types to a function, writing a commit message from a diff, or writing a test that follows the pattern of the ten tests next to it.
What these have in common is that they're fully spelled out and there's an obvious way to check them. If the tests pass and the diff looks right, you're done.
Subagents that search and read
When a coding agent needs to find where something is defined or how a feature is wired together, a lot of tokens go into reading files that turn out not to matter. That's a good job for a cheaper subagent, which does all the reading and reports back a short summary to the main model.
The main model only sees that summary, so you're not paying top prices for every file the search opened along the way.
Repetitive work across many items
If you're running the same small task hundreds or thousands of times, like writing alt text for every image on your blog, the price difference really adds up. It's also the kind of work where you'd happily check a sample of the results rather than every single one.
What still needs a frontier model
On the other side, there's work where the extra capability is worth paying for.
Planning and architecture
This is work like deciding how a feature should be built, how your data should be modelled or how two systems should talk to each other. A cheap model will happily give you a plan, but it's much more likely to miss a constraint or pick an approach that falls apart later, and you might not notice until you've built half of it.
Debugging when you don't know the cause yet
If you already know what's wrong, a cheap model can usually fix it. But when all you've got is a symptom, the model has to come up with a theory, test it and throw it away when it's wrong, and that's where the bigger models are noticeably better.
Changes that cut across your codebase
Refactoring something used in dozens of files, upgrading a framework version or changing how authentication works all need the model to keep a lot in its head at once. A smaller model is more likely to miss one of the places that needs updating.
Long agent runs
The longer an agent runs on its own, the more small mistakes pile up. A wrong assumption early on can send the whole run in the wrong direction, so for anything you're leaving to run for a while, it's worth paying for the model that makes fewer of them.
Anything where a wrong answer is hard to spot
If you can't easily tell whether the answer is right, like with a security review, saving money on the model doesn't help much when it gives you a plausible answer that turns out to be wrong.
Mixing models
You don't have to pick one model for everything, and the most practical setup usually uses a few. A bigger model does the planning and makes the decisions, and cheaper models do the bulk of the reading and the repetitive work.
In Claude Code, you can do this with subagents. Each subagent is a Markdown file in .claude/agents, and the model field in its frontmatter decides which model it runs on. Set it to haiku, and that subagent runs on Haiku while your main session stays on whatever model you picked.
So you could create a test writer subagent with model: haiku. When your main session (running on Opus, for example) finishes building a feature, it can hand the tests off to that subagent, which reads your existing tests and writes new ones to match. The model field also accepts sonnet, opus, fable, a full model ID, or inherit to use whatever your main conversation is using.
Claude Code's built-in Explore subagent runs on the same model as your main conversation. If you'd rather your codebase searches ran on Haiku, create your own subagent named Explore with model: haiku, and it'll be used instead of the built-in one.
Splitting work between models has a cost of its own, though. The main model has to write up the task, hand it over and then make sense of what comes back, so when the work is one chain of steps that each depend on the last, a single model usually does it for less. Mixing models pays off when there's a lot of independent work to hand out.
Building an intuition
There's no hard and fast rule for this, but there are a few questions I find myself asking before I pick a model.
Can I check the output cheaply?
If there's a test, a schema or a quick glance that tells you whether the answer is right, a cheap model is a safe bet, because you'll catch the failures. If checking means redoing the work yourself, pay for the better model.
How many times will this run?
A task you run once a week can go on whatever model you like, since the difference is pennies. A task that runs on every request or every record is where the model choice actually shows up on your bill.
Is everything the model needs in the prompt?
Cheap models are good at working with what they're given, and much less good at figuring out what's missing. If you can spell out the whole task up front, try the cheaper model.
Would I hand this to a junior developer?
If you'd happily give the task to a junior developer with a clear brief and expect it back done, it'll probably suit Haiku. If you'd want to talk it through with someone senior first, use a frontier model.
Trying a cheaper model
Your gut feeling will be wrong sometimes, so test it. Grab around 20 real examples of the task (a mix of easy and hard ones), run them through the model you're using now and the cheaper one, and compare the results side by side.
If the cheaper model holds up, switch. If it doesn't, try the model one tier up rather than going straight back to the most expensive one, and try a lower effort setting on your current model too.
You can also run everything on the cheap model first and only send the failures to a bigger one. As long as you've got a way to tell when something's failed (a failing test, for example), you get most of the savings with very little risk.
Wrapping up
Most of us (me included) default to the best model for everything, and for a lot of work that's still the right call. But cheap models are good enough now that it's worth asking the question each time, especially for anything that runs at scale.
I'd start with whatever task you're running most often and see whether Haiku can handle it.
