Turn the reasoning up before you turn the model down

Short: smarter → needs less reasoning → fewer tokens for easy work → cheaper.

That sounds wrong the first time you read it, because we all learned the opposite. Big model expensive, small model cheap… so when the budget gets tight everybody does the same thing: switch to the smaller model and crank the reasoning up to compensate.

And that’s mostly the worst option you have.

Written in July 2026. Model names and effort levels will be outdated pretty quickly, the mechanism won’t.

TL;DR

• There are two dials: model tier and reasoning effort. Most people only ever touch the first one
• Better adjust the reasoning level than switching to a smaller model
• A more capable model needs less reasoning for the same result → it can be cheaper and better at the same time
• Weak model + maximum effort is the worst cell in the whole grid
• Start strong and tune the effort down. Not the other way around.
• Escalating to a better model is cheaper than shipping something mediocre

Two dials, and everybody only turns one

Every serious model today has some reasoning or effort setting: low, medium, high and something above that. And most people I talk to pick a model once, leave the effort on whatever the default was, and then treat “which model” as the only lever they have.

But the effort dial does something really different from the tier dial, and it’s usually the one you actually want.

Reasoning tokens are tokens. They get generated, they get billed, they fill up your context. A model on maximum effort thinks a lot before it answers, that’s the whole point. And for a task that didn’t need it you paid for all of that thinking and got the same answer anyway.

The concrete case

It’s not worth it to use Sonnet on xhigh. Use Opus on medium, it’s a more capable model, needs less reasoning for the same “intelligence” and it’s cheaper.

That’s the sentence I would put on the wall of every team getting nervous about their usage. The smaller model on maximum effort is doing more work to get to a worse answer, and you pay for the extra work.

Why? Because reasoning is how a model compensates for not immediately knowing. A stronger model needs fewer steps to get to the same place: you pay for capability once, instead of paying for extra thinking on every single task.

The worst cell in the grid

If you lay both dials out as a grid, one square is clearly the loser: weak model, maximum effort.

It burns the most tokens per task of all the small-model configurations, it’s slow, and it still lands below what a stronger model gives you on medium. You get the cost profile of the expensive option with the quality profile of the cheap one.

And it feels responsible while you do it, which is maybe why it’s so common. You didn’t reach for the expensive model, you were being careful. But you weren’t, the cost just moved to a place the model dropdown doesn’t show you.

So what I do now

The default that works for me:

• take the strongest model I have access to
• tune the effort down until the quality drops
• leave it there

Not the other way around. Starting cheap and cranking the effort up until it works means you never find out how good the result could actually be. You only find out how much thinking a weaker model needs to approximate it.

Nearly everything I do daily runs on medium. High is for the genuinely hard stuff where the plan itself is the difficult part. The levels above that burn your tokens in seconds and honestly nearly never change the decision the model ends up with.

Where this flips

There is one case where “just take the small model” is right: bulk mechanical work with a fully specified spec. Migrations, mass renames, data shape changes, the fifteenth similar handler. Intelligence buys you nothing there because there is no judgment left in the task, somebody already made all the decisions and volume is the only cost driver.

Which is also why this fits together with putting the strong model into the orchestrator seat instead of letting it type. The strong model decides, the cheap ones execute the decided part. Same principle, one level up.

Escalating is cheaper than shipping bad work

Last thing… and this one really took me the longest to accept.

If a cheaper model gives you something that doesn’t meet the bar, don’t review it, don’t patch it, don’t argue with it in three follow-up prompts. Just run it again on a better model.

Re-running a task costs a few cents. Reviewing and fixing a weak result costs your attention, which is the actually scarce thing. And merging it costs whoever touches that code next, forever. The price tag on the model dropdown is the smallest number in that whole comparison and it’s the only one we ever look at :D

So: judge the output, not the price tag.