Is Sonnet good enough for real work?

For a large share of an ordinary day, yes, and the phrasing of the question is part of the trouble. "Good enough" implies you're accepting a lower ceiling. On tasks that never needed the larger model, the smaller one produces the same result rather than a worse one. Tasks where the tier genuinely changes the outcome are a real category, but renames, config edits, boilerplate, and well-specified small functions aren't in it.

How do I know if I over-modelled?

You can't tell from the output, which is the whole difficulty. A correct answer from an oversized model is indistinguishable from a correct answer from a right-sized one. There's no warning and nothing degrades. The only reliable way to find it is afterwards, by looking at what you ran and asking which of those tasks a cheaper tier would have handled.

Does switching models mid-session help?

Going forward, yes. It refunds nothing. Cost is charged per turn as you go, so switching down partway means the remaining turns are cheaper while the turns already taken are already paid. The larger lever is the decision at the start of a task rather than a correction inside one.

Isn't the smaller model a false economy once you count retries?

It can be, and that's the honest counterweight. Under-modelling costs retries plus your own attention, and three failed cheap attempts are worse than one adequate expensive one. That's why the goal is right-sizing rather than down-sizing. The argument isn't that smaller is better, it's that the choice should be deliberate instead of a setting you picked months ago.

Does the hosted right-sizing analysis send my code?

No. It sends a gist of each task plus metadata: model used, token counts, the shape of the turns. Never your code, your prompts, your file paths, or your repo names. It's also opt-in. A plain run transmits nothing, and the flag is the consent.

July 26, 2026

Opus vs Sonnet: when the bigger model is the wrong call

You picked your model once and it has answered every question since. The reason that happens is an asymmetry in the feedback you get: too small announces itself immediately, too big never does. Which work genuinely needs the frontier tier, which doesn't, and one question that sorts most of a working day.

Paarth Jamdagneya

when to use opus vs sonnetopus vs sonnetclaude model choicemodel right-sizingwhich claude model should i useclaude code model selectionsonnet vs opus coding

Think about the last time you chose which model to use.

For most people the honest answer is that it wasn't recent and it wasn't really a choice. You set it once, probably to the largest thing available, because nobody wants to be the person whose agent failed at something because they were economizing. It has answered every question since. Refactors, config edits, one-line fixes, genuinely hard debugging. Same model, no decision made.

This is one of the easiest ways to spend a weekly allowance without getting anything back, and it survives for a specific and interesting reason.

Over-modelling has no symptom

Under-modelling announces itself instantly. The model doesn't quite manage the task, the output is wrong, and you know within a turn or two. It's loud, immediate, and instructive. You move up a tier and stay there.

Over-modelling never announces itself. An oversized model on a simple task doesn't fail, doesn't warn you, and produces nothing you'd look at twice. It quietly costs several times more for an outcome you would have got anyway.

The feedback loop is therefore one-sided. Every time the model is too small you find out. Every time it's too big you don't. Run that loop for a few months and it has exactly one stable resting point: everything on the frontier tier, forever, with nobody having decided that.

Worth sitting with, because the same asymmetry shows up all over engineering. Costs that announce themselves get optimized. Costs that stay silent accumulate until something external forces an audit. Model choice is a small instance of a large pattern, and the fix is the same one it always is, which is to go and measure the thing that isn't shouting at you.

The economics in one line

Model tiers differ severalfold in cost per token. It's a multiple rather than a margin. A task that would have succeeded on a mid-tier model and ran on a frontier one cost you that multiple for an identical result.

Once is nothing. The trouble is that it isn't once. It's the default, applied to every mechanical task you'll do this week, and mechanical tasks are most of them.

Right-sizing is not down-sizing

Before the practical part, a necessary caveat, and a real one. The name for this is model right-sizing, and the load-bearing half of the word is right.

Using the cheap model for everything is also a way to lose money. A model that can't quite do the task produces a wrong answer, you re-prompt, it tries again, you correct it, and three cheap attempts plus twenty minutes of your attention cost more than one adequate attempt would have. Worse, some of those failures don't look like failures. They're plausible answers you accept and discover later.

So this isn't an argument for the cheap tier. It's an argument against the choice being automatic. "Always the biggest" and "always the cheapest" are both ways of not thinking, and they fail in different directions.

What genuinely needs the frontier model

Reach for the top tier when the work has one of these properties.

It holds a lot at once. A change spanning several files whose interactions matter. When a model loses the thread here the failure mode isn't broken code, it's subtly wrong code that passes, which is the expensive kind.

The problem is genuinely ambiguous. Debugging where the cause isn't known and the useful work is forming hypotheses and discarding them. This is reasoning under uncertainty, and it's what the tier gap actually buys you.

The decision is expensive to reverse. Interface shape, data model, anything you'll live with. Cheap to get right now, costly to unwind in a month.

You're in unfamiliar territory. A language, framework, or codebase where you can't yourself tell a good answer from a plausible one. This last one is about you rather than the task, and it's the one people skip.

What doesn't need it: mechanical refactors with a clear rule, boilerplate, scaffolding, config, test fixtures, renames, moves, formatting, well-specified small functions, and reading something to summarize it. None of these improve on a bigger model. They come out identical, for a multiple.

One question to decide with

Rules per language or per repo don't survive contact with real work, because the same file can warrant different tiers on different days. What does survive is a question you can ask in two seconds at the start of a task.

Do I already know what a correct answer looks like here?

If yes, you can catch it being wrong, so a smaller model is usually fine. Your review is the safety net and it works regardless of which tier produced the code.

If no, you're trusting rather than checking. There's no safety net, so the first answer needs to be right, and that's precisely what the larger model is for.

That question sorts most of a working day correctly. It also has a property the tier-by-task-difficulty framing lacks: it's about your own knowledge, not some inherent difficulty score, which is why two competent people can reasonably make opposite calls on the same ticket and both be right.

Finding the ones you already got wrong

The asymmetry means you can't audit this from memory or by eye. Over-modelled sessions left no trace in the output, which is the definition of the problem. They exist only in the record of what you ran, and Claude Code has been writing that record to ~/.claude/projects the entire time.

npx @promptster/cc-audit --judge

A plain npx @promptster/cc-audit prints your local breakdown and transmits nothing. Adding --judge sends a gist of each task plus metadata, meaning the model used, token counts, and the shape of the turns, to a hosted model that reads back which of your premium-model tasks a cheaper tier would have handled and what the difference cost. It never sends your code, your prompts, your file paths, or your repo names. The flag is the consent: type it, or nothing leaves.

There's a knob for how eagerly it flags candidates, because how much risk you'll accept on a downgrade is a judgement call and not one a tool should make for you. It prices the decision. You still make it.

Which is the point. You've been making this call by accident since the day you set it. Making it on purpose, a few times a week, is most of the win.

Frequently asked questions

Is Sonnet good enough for real work?
For a large share of an ordinary day, yes, and the phrasing of the question is part of the trouble. "Good enough" implies you're accepting a lower ceiling. On tasks that never needed the larger model, the smaller one produces the same result rather than a worse one. Tasks where the tier genuinely changes the outcome are a real category, but renames, config edits, boilerplate, and well-specified small functions aren't in it.
How do I know if I over-modelled?
You can't tell from the output, which is the whole difficulty. A correct answer from an oversized model is indistinguishable from a correct answer from a right-sized one. There's no warning and nothing degrades. The only reliable way to find it is afterwards, by looking at what you ran and asking which of those tasks a cheaper tier would have handled.
Does switching models mid-session help?
Going forward, yes. It refunds nothing. Cost is charged per turn as you go, so switching down partway means the remaining turns are cheaper while the turns already taken are already paid. The larger lever is the decision at the start of a task rather than a correction inside one.
Isn't the smaller model a false economy once you count retries?
It can be, and that's the honest counterweight. Under-modelling costs retries plus your own attention, and three failed cheap attempts are worse than one adequate expensive one. That's why the goal is right-sizing rather than down-sizing. The argument isn't that smaller is better, it's that the choice should be deliberate instead of a setting you picked months ago.
Does the hosted right-sizing analysis send my code?
No. It sends a gist of each task plus metadata: model used, token counts, the shape of the turns. Never your code, your prompts, your file paths, or your repo names. It's also opt-in. A plain run transmits nothing, and the flag is the consent.