The expensive-model myth: when the top AI model is really worth it

There is this reflex to always take the most expensive model, because expensive must mean better. And sometimes that is true. But mostly you pay the surcharge for reasoning depth your task never calls on. You have a model that could think through a complicated architecture refactor rewrite an email instead. That is like buying a sports car to fetch bread rolls and then being surprised that fuel is expensive.

This playbook is the honest decision guide I would have wanted at the start. Not a marketing table, but one rule of thumb per use case that you actually remember afterwards. We go through coding, writing, agents and routine tasks and look at where the top class is worth its price and where the middle class delivers exactly the same result for a fraction.

The myth in one sentence

The belief goes: the best model always delivers the best result, so when in doubt take the most expensive. Sounds logical, but it is wrong. What is correct: the best model delivers the best result on tasks that need genuine reasoning depth. On everything else it delivers the same result as the middle class, you just pay more for it.

The error hides in the word "better". A top model is not generally better, it is better at thinking. If your task needs little thinking and a lot of throughput, then "better at thinking" is a property you pay for without using it. That is exactly where most people burn money.

The three classes, without a price table

Instead of confusing you with concrete cent amounts that change every month anyway, remember the three classes relative to each other. The top class (at Anthropic it is called Opus, other providers have their own most expensive tier) costs a multiple of the middle class per token. The middle class (Sonnet at Anthropic, comparable tiers elsewhere) is the daily driver for almost everything. The small class (Haiku, or the Flash tier at Google) is considerably cheaper again, and fast.

The exact factors keep shifting, which is why I deliberately name no fixed numbers here. What stays stable is the ratio: top is expensive and slow-thorough, middle is the all-rounder, small is cheap and fast. If you hold that in your head, you make 90 percent of the decisions correctly without ever opening a price list.

The one question that decides everything

Before you pick a model, ask yourself a single question: would an experienced person have to think long about this task, or do they do it in their sleep? If they have to think long, you need reasoning depth, so lean top class. If they do it in their sleep, you need throughput, so middle or small class.

An example makes that tangible. "Find the bug in this nested async code that only shows up under load" is a think-long task. "Turn these bullet points into a clean paragraph for me" is a do-it-in-your-sleep task. The first justifies the surcharge, the second does not. That question replaces roughly half of all model discussions I have ever had.

Coding: this is where top pays off most often

Coding is the area where the top class earns its money most often, but not always here either. On a larger refactor across several files, on a bug that runs through three layers of abstraction, or on an architecture decision with many dependencies, the top class wins noticeably. It holds more in its head, it gets tangled less often, it produces fewer follow-on errors that you then clean up by hand.

But, and this is the point the sports-car crowd misses: most daily coding is not that hard. Writing a function, adding a test, generating a piece of boilerplate, wiring up an API whose docs you have open next to you. The middle class does that just as well. My practical cut: middle class as the default in the IDE, and only when I notice "it is going in circles or missing the connection" do I switch up to top for that one task. That way you pay the surcharge only for the ten percent of tasks that really need it.

Writing: almost always middle, rarely top

With writing the ratio flips completely. The vast majority of texts, so blog paragraphs, product descriptions, emails, summaries, social posts, are do-it-in-your-sleep tasks for a good model. The middle class writes them cleanly, in the right tone, and without you being able to tell from the result that no top model was involved. Paying the surcharge here is almost always money thrown away.

There are exceptions, and honestly they are rare. A long text that has to hold a continuous line of argument across many paragraphs without contradicting itself. A piece that has to weigh real domain knowledge properly. There, top can make the difference. But if you need a newsletter, a landing page or ten variants of a subject line right now, take the middle class and enjoy the difference on the bill at the end of the month.

Agents: the crux is mixing, not maximising

With agents most people make the most expensive mistake of all: they set the most expensive model switch for the entire agent and then let it run hundreds of steps. An agent that makes twenty tool calls to find a file, read a table and post a status barely thinks at all on most of those steps. You still pay the top rate for every step.

The trick is mixing. The heavy planning decision at the start ("how do I approach this problem, which steps in which order") can go to a top model. The blunt execution afterwards ("call this tool, read the result, move to the next step") runs just as reliably on the middle or small class. When you build an agent, ask yourself per step type which class it needs, instead of nailing one class to the whole agent. That is often the difference between an agent that pays for itself and one that eats your budget.

Routine tasks: top is pure money burning here

Classifying, tagging, formatting, extracting three fields from a text, short summaries, simple yes-no decisions. Those are routine tasks, and they are where the small class shines. Fast, cheap, and for this kind of task just as accurate as anything above it. Turning a top model loose on a tagging task is like paying a professor to sort index cards.

The temptation to take the big class anyway usually comes from insecurity ("what if it does get more complicated"). Better to build in a small escalation: small class as the default, and only the cases where it is unsure or that obviously fall outside the pattern get passed up to the middle class. On volume tasks, where you run thousands of passes, this one choice decides factors on the bill, not percentages.

The advisor trick: top plans, middle executes

There is a pattern that brings the advantages of both worlds together, and it works surprisingly often. You let the top class make the plan once at the start, the heavy thinking, the strategy, the architecture. Then you hand that plan to the middle class, which works through it step by step. One expensive thinking call, many cheap execution calls.

That adds up, because thinking is rare and executing is frequent. You pay the top rate exactly once for the part that is worth it, and not for the twenty blunt steps afterwards. We have a separate playbook for this (Opus as advisor, Sonnet as executor) that shows the setup in detail. If your use case has a clear split between "think hard once" and "then work through a lot", that is almost always the most economical route.

Test it yourself instead of believing it

Here is the mini experiment that ends every faith-based discussion. Take ten real tasks from your own work, not made-up ones. Have each done once by the top class and once by the middle class. Then put the results side by side and ask yourself honestly: on how many do I really see a difference that is worth something to me?

For most people the answer is sobering: on two or three out of ten. Which means that for seven out of ten tasks they have been paying the surcharge for nothing. And exactly those two or three tasks where the difference was visible, those are your top candidates. From now on you send the rest to the middle class. This test takes a quarter of an hour and often saves you money for months, because afterwards you no longer guess, you know.

The rule of thumb that sticks

If you remember only one sentence from this whole playbook, make it this one: take the middle class as your default and only switch up to top when the task demands genuine, deep thinking that an experienced person could not do in their sleep either. Coding refactor across many files, tricky bug, hard architecture decision, long text with a continuous argument. Those are the top cases. Everything else the middle class can do, and routine goes to the small one.

Expensive is not better, expensive is more thorough. And thoroughness is only an advantage when the task actually calls on it. As soon as you start asking per task instead of taking the big class across the board, your bill often drops drastically without the quality of your results suffering a millimetre. That is not a trick, that is simply no longer paying for reasoning you do not use.

If you want to go deeper: the playbook "Opus as advisor, Sonnet as executor" shows the advisor setup step by step, and "Claude Code cost controls for daily drivers" helps you build the switch-up to top into your day in a controlled way. If you want to start right at the beginning, look at the model comparison lesson in level 1, that is where we lay the foundation this playbook builds on.