Sonnet 5 vs Opus 4.8: Which Claude Model for Which Job

If you run AI agents all day — building features, fixing sites, migrating data, drafting content — you learn fast that “just use the best model” is a bad default. The best model is also the slowest and the more expensive, and most of the work you throw at it doesn’t need that horsepower. The twist in the current generation: Sonnet 5 has closed so much of the gap that, run well, it matches Opus on most tasks — so reaching for Opus by default costs you speed and money for a quality bump you often don’t get.

We run a multi-model workflow across our whole portfolio, and after a lot of real mileage the rule that stuck is simple:

Sonnet does the work. Opus checks it, decides, and ships it.

This piece explains why, what it actually costs, and gives you copy-paste prompts for both.

The two models in one paragraph each

Claude Sonnet 5 is the workhorse. It’s fast, it’s strong at code, it follows detailed instructions faithfully, and it costs noticeably less than Opus per token. For 80% of day-to-day agent tasks — the ones where you already know what needs doing and just need it done well — Sonnet is not a compromise. It’s the right tool.

Claude Opus 4.8 is the heavyweight. It’s the one you want when the task is genuinely hard: tangled reasoning, ambiguous requirements, a plan that has to be right the first time, or a judgment call where being wrong is expensive. It thinks more deeply and catches things Sonnet misses. You pay for that — in latency and in cost — so you spend it deliberately, not by default.

Both share the same tool-use skills, the same large context window, and the same coding-ability ceiling on straightforward tasks. The gap shows up on the hard stuff, not the routine stuff.

The finding that changed our defaults: turn Sonnet’s effort up

Here’s what we didn’t expect until we measured it. Sonnet 5 run at high reasoning effort produced results very comparable to Opus 4.8 on the great majority of our tasks — including ones we’d previously assumed needed Opus.

Reasoning effort is a dial you control separately from the model. Cranking Sonnet to high tells it to think longer and harder before it answers. It costs more tokens than Sonnet at normal effort (it’s “thinking” more), but each of those tokens is still cheaper than an Opus token — and on most work the output is nearly indistinguishable from Opus.

The practical consequence: your first move when Sonnet’s default output isn’t quite good enough shouldn’t be “escalate to Opus” — it should be “re-run Sonnet at high effort.” That closes most of the quality gap at a fraction of the cost, and it shrinks the set of tasks that genuinely need Opus down to a small, hard core.

The cost math: what Opus actually costs you

First, the real numbers. Here’s the current per-million-token pricing across the lineup:

* Sonnet 5 carries introductory pricing of $2 / $10 per million through 31 August 2026, after which it’s $3 / $15.

So the honest gap is smaller than the old lore suggests: Opus is about 1.7× the price of Sonnet at standard rates — and about 2.5× right now, during Sonnet’s intro period. Not the 5× that earlier Opus/Sonnet generations used to cost. On a subscription plan, that ratio maps roughly onto how fast you burn your usage quota.

Run the numbers on a realistic day of 20 agent tasks (indexed so one Sonnet task = 1 unit, standard pricing):

All-Opus isn’t 1.7× better output — most of those 20 tasks were routine, and Sonnet would have nailed them. But it is ~40% more spend than the split, so you hit your quota limit sooner and wait out more cooldowns, for output that’s no better on the tasks that didn’t need it.

Here’s the part that matters more than the price gap, though. Because Sonnet at high effort matches Opus on most tasks, the split isn’t really a cost-vs-quality trade at all — you’re getting near-Opus quality on the Sonnet tasks. Several jobs you’d instinctively send to Opus stay on Sonnet (just with the effort dial up), and Opus only handles the genuinely hard core. Bumping effort costs a few more thinking tokens, but a Sonnet-high task still lands under an Opus task on price — so it’s almost always the better first move than switching models.

And the savings aren’t only money. Sonnet is faster, so a Sonnet-heavy pipeline finishes more work per hour. You get more done, a bit cheaper, at quality you can’t easily tell apart — because you matched the tool to the job instead of defaulting to the biggest one.

Best use cases: the do / decide split

Think of every task as either execution (there’s a known-good outcome, get me there) or judgment (figure out what the right outcome even is). Sonnet owns execution. Opus owns judgment.

Reach for Sonnet 5 when…

• Building a well-specified feature. You’ve written a clear spec; Sonnet implements it. This is its home turf.
• Mechanical edits at scale. Rename across a codebase, update a config everywhere, apply the same fix to 40 files.
• Data migrations and transforms. Move rows, reshape JSON, backfill a table, wire up an importer.
• Research and gathering. Pull facts, summarize docs, collect competitor data, draft first-pass content.
• Routine bug fixes. The error is clear and the fix is local.
• WordPress / theme / plugin edits where the change is understood and just needs careful hands.
• Verification legwork. Curl the live pages, diff the outputs, check that the thing loads.

Rule of thumb: if you can write the acceptance criteria in two sentences, give it to Sonnet. (And for truly trivial, repetitive checks, drop to Haiku 4.5 — even cheaper.)

Reach for Opus 4.8 when…

• Planning before a big change. Architecture decisions, migration strategy, “what could break.” Getting the plan right saves ten downstream mistakes.
• QA and review — the acceptance gate. Opus reviews Sonnet’s diff, verifies it actually meets the spec, catches the subtle miss, then approves the deploy. This is the highest-leverage place to spend Opus.
• Ambiguous or underspecified problems. When part of the job is deciding what to do, not just doing it.
• Deploy-sensitive or tangled steps where a mistake is hard to reverse and being careful is worth the latency.
• Genuinely hard reasoning — knotty debugging across systems, tricky correctness arguments, tradeoff calls with real consequences.

Rule of thumb: if getting it wrong is expensive or hard to undo, spend the Opus tokens — but if the task is merely hard, not irreversible, try Sonnet at high effort first.

The escalation ladder

Don’t jump straight to the biggest model when output falls short. Climb one rung at a time — most tasks stop before the top:

1. Sonnet 5, normal effort — the default for execution.
2. Sonnet 5, high effort — when the first pass isn’t quite right. This rung catches most of what you’d have escalated to Opus, at a fraction of the cost.
3. Opus 4.8 — reserved for the genuinely hard core: irreversible calls, gnarly cross-system reasoning, the final QA gate.

Only climb when the current rung actually fell short. In practice a lot of work never leaves rung 1, most of the rest is settled at rung 2, and rung 3 is a small minority.

If you use Claude Code, this split is a one-line setting. Claude Code ships a model preset called opusplan that wires the do/decide split in for you: it runs Opus 4.8 in Plan mode (the reasoning and architecture phase) and automatically drops to Sonnet 5 for execution once you approve the plan. You get Opus judgment on the plan — the call that matters — and Sonnet’s speed and cost on the build, without hand-switching models. Turn it on with /model opusplan in-session, claude --model opusplan at startup, or "model": "opusplan" in settings.json. (Use /model opusplan[1m] to force the 1M-token context window across both phases. Note: if Opus is disabled by your availableModels settings, it stays on Sonnet in Plan mode too.)

The pattern that ties it together

The single most useful habit: Sonnet builds, Opus QAs. You write a tight spec, hand the execution to one or more Sonnet agents (in parallel, if the tasks are independent), and then Opus acts as the reviewer — reading the output, checking it against the spec, and making the ship/no-ship call. You get careful judgment on the decision that matters while keeping the expensive model off the routine grind.

It also keeps your own attention free: Sonnet agents churn in the background while you line up the next batch, and Opus only pulls you in at the decision points.

Prompts you can steal

1. Sonnet — build to spec

You are implementing a well-defined task. Do exactly this and nothing more.

TASK: <one clear sentence>
FILES IN SCOPE: <paths>
ACCEPTANCE CRITERIA:
- <criterion 1>
- <criterion 2>

Constraints: match the surrounding code style. Don't refactor unrelated
code. Run the project's check/build before you finish. If a requirement is
ambiguous, make the smallest reasonable choice and note it — don't stall.

Report back: what you changed, the check result, anything you were unsure of.

2. Sonnet — mechanical sweep

Apply this change consistently across every matching location:

CHANGE: <before> -> <after>
SCOPE: <glob or directory>

Find all occurrences first and list them. Apply the change to each. Skip any
that look intentionally different and flag them for review instead of
guessing. Verify nothing else broke. Give me the count and the flagged list.

3. Opus — plan before you build

Before any code is written, design the approach for this change.

GOAL: <what we want to end up with>
CONTEXT: <constraints, systems involved, what must not break>

Give me: (1) the recommended approach and why, (2) the main risks and how
each is mitigated, (3) a step-by-step plan a builder agent can follow, and
(4) one alternative you considered and why you rejected it. Be decisive —
recommend, don't just enumerate.

4. Opus — QA the acceptance gate

You are the QA reviewer. A builder agent produced the change below. Decide
whether it ships.

SPEC / ACCEPTANCE CRITERIA: <the original spec>
DIFF OR OUTPUT: <what the builder did>
EVIDENCE PROVIDED: <check results, screenshots, live URLs>

Verify each acceptance criterion is actually met — don't take the builder's
word for it. Check the evidence is real and sufficient. Look for the subtle
miss: edge cases, unintended side effects, things that pass the check but
violate the intent.

Verdict: PASS (ready to deploy), CHANGES REQUESTED (list exactly what),
or BLOCKED (name what's missing). Justify it.

5. The handoff — one spec, two models

# Opus writes this spec, a Sonnet agent executes it:

TICKET: <id + one-line title>
OUTCOME: <what "done" looks like, in plain terms>
STEPS: <ordered, unambiguous>
DONE WHEN: <checkable criteria>
DO NOT: <out-of-scope things to leave alone>

# Sonnet builds, marks it ready-for-review with evidence.
# Opus then runs prompt #4 against the result and makes the ship call.

A simple decision rule to end on

You don’t need a flowchart. Ask one question about the task in front of you:

“Do I already know what a correct result looks like?”

• Yes → it’s execution. Sonnet 5. (Trivial and repetitive? Haiku 4.5.)
• Almost, but the first pass came up short → Sonnet 5 at high effort before you touch Opus. This is where a surprising amount of “I thought I needed Opus” work actually lands.
• No — part of the job is deciding what correct even is, and it’s costly to get wrong → it’s judgment. Opus 4.8.

And always put Opus on the last step — the review and the ship decision — even when Sonnet did everything before it. The cheapest model that gets the work done, guarded by the smartest model on the call that matters. That’s the whole trick: you spend a little less, move a lot faster, and — because Sonnet at high effort matches Opus on most work — give up almost nothing on quality.

Pricing referenced: Claude Opus 4.8 ($5/$25 per 1M in/out), Sonnet 5 ($3/$15 standard; $2/$10 introductory through 31 August 2026), Haiku 4.5 ($1/$5), Fable 5 ($10/$50) — current as of publication. Pricing is set by Anthropic; check current rates before budgeting.