Claude Sonnet 4.6 vs Opus 4.6 — A Task-by-Task Selection Guide From Daily Use

When I Surrender and Reach for Opus 4.6

The flip side: tasks I struggled with on Sonnet for hours and resolved instantly by switching to Opus.

Structural refactoring across multiple files. "Separate this feature's responsibilities into auth / business logic / data access layers" — the kind of request where Sonnet polishes individual files but loses overall coherence. Opus aligns these much more reliably.

Hard debugging. Bugs whose causes are tangled and don't yield to log inspection. Sonnet tends to stack guesses ("might be this... or this..."), while Opus's hypotheses feel one notch more confident.

Greenfield design. "Design a multi-site automation foundation" — anywhere chained tradeoffs determine the answer, Opus pushes further. Sonnet gives a safe answer; Opus often adds reasoning like "if you put a queue here, future expansion gets easier, but the first six months might be YAGNI."

Long-form logical consistency checks. Whether checking an article's argument flow or a contract draft for contradictions, Opus's detection rate is clearly better.

How I Decide in the Gray Zone

The hardest cases are the in-between ones. My decision criteria:

"How costly is a retry?" If the output requires a one-hour code review, Opus's accuracy premium is worth it. If you can eyeball quality in seconds, Sonnet plus more attempts is rational.

"Who suffers if it fails?" A Stripe webhook implementation that ships to production is safer in Opus's hands than in mine reviewing it longer. An internal tool's admin styling? Sonnet is fine.

"Is this question searchable?" If something on Stack Overflow probably answers it, Sonnet's enough. If you're certain no one in the world has solved your exact problem, Opus earns its keep.

"Switch to Opus when stuck." I've made it a habit. Three rounds with Sonnet without progress, paste the context into Opus. It's rare for that not to break the impasse.

A Side Trick: Send the Same Question to Both

A slightly unusual pattern I use frequently: for high-stakes decisions, ask both Sonnet and Opus the same question and compare answers.

Example: "For this stack, Cloudflare Workers or Vercel Edge?" Reading both answers side by side reveals the shared concerns and the angles only Opus surfaced. The cost is one extra call but it's far cheaper than 30 minutes of my own searching.

I don't run this pattern for code generation — merging outputs is too expensive. It's specifically for "I want to compare answers" situations.

Surviving "Opus is Slow"

Opus's experiential weakness is response time. It's noticeably slower than Sonnet, and the gap widens with longer answers. In interactive sessions, the latency disrupts thought rhythm.

Two coping strategies. First, "format Opus prompts as longer, fuller requests." For rapid-fire short questions, use Sonnet. For one big package, send Opus. Spamming short questions at Opus wastes its capability and your time.

Second, "switch tasks while Opus thinks." While Opus chews on something, run another task on Sonnet, reply to email, brew coffee. Sitting and waiting is the worst use of the latency.

Know Each Model's Failure Modes

Both models have their typical "miss" patterns. Knowing them lets you spot a bad output faster.

Sonnet's classic miss: "plausible but shallow." Looks structurally right, but on closer reading the reasoning is thin or edge cases are dropped. In code, the happy path runs but error handling is sloppy.

Opus's classic miss: "excessive politeness." Explanations of things you didn't ask about that dilute the main point. Long hedges like "of course this is ultimately your decision." This is partly because Opus is trained to be more cautious — not a bad property — but in a hurry, it's noise.

I counter each with explicit prompts: "lead with a one-line conclusion" against Opus's hedging, and "list 5 edge cases" against Sonnet's shallowness.

Backing the Feel with Numbers — What the Benchmarks Show

So far I've been sharing how the two models feel in daily use. Feel alone isn't always convincing, though. When you line up the benchmarks published at the time, they map closely onto the way I split my work.

The coding gap is about one point, and GUI control is essentially level. For everyday code generation and automation, there's little reason not to reach for Sonnet, which runs at a fifth of the cost. That's exactly why I hand routine code generation to Sonnet without a second thought — the numbers back it up.

The 17-point gap on GPQA Diamond, on the other hand, is precisely the territory I call "reluctantly an Opus job." The deeper the chain of reasoning, the more that gap shows up in practice — the same moment when switching a hard debugging session or a from-scratch design over to Opus suddenly unblocks it.

Both models ship with a standard 200K-token context window. Opus 4.6 supports a 1M-token window in beta, which becomes a deciding factor when you want to read a large codebase in one pass.

Going Further — Let Opus Architect, Let Sonnet Mass-Produce

The choose_model helper above routes a whole task to one model or the other. You can go one level deeper and split the roles within a single task: Opus as the advisor that designs and reviews, Sonnet as the executor that does the repetitive work.

This is the shape I settled on as an indie developer running multi-site automation on my own dime. I consult Opus once at the start — what should I build, and in what order? — and it returns a plan with its reasoning attached. I hand that plan to Sonnet, which mass-produces the code or prose for each step. Then I run the whole thing past Opus one final time for a consistency review.

So Opus is called only twice: the initial design and the final review. Everything in between runs on Sonnet. Opus's judgment is concentrated on the two points where it matters most, and the bulk work flows at Sonnet's cost. A variant that pushes the orchestrator onto an even cheaper model is covered in detail in A Two-Tier Setup — Haiku 4.5 Orchestrator with Opus 4.6 Worker for Balancing Cost and Quality.

import anthropic
 
client = anthropic.Anthropic()
 
ADVISOR = "claude-opus-4-6"     # design and review
EXECUTOR = "claude-sonnet-4-6"  # mass production
 
def plan(goal: str) -> str:
    """Ask Opus for steps at a granularity the executor can start from."""
    msg = client.messages.create(
        model=ADVISOR,
        max_tokens=2048,
        messages=[{
            "role": "user",
            "content": (
                f"Goal: {goal}\n"
                "List the steps to implement this, each at a granularity that can "
                "be started independently. For each step, state its input, the work, "
                "and its completion criteria."
            ),
        }],
    )
    return msg.content[0].text
 
def execute(step: str) -> str:
    """Let Sonnet carry out each step — all the high-volume work lives here."""
    msg = client.messages.create(
        model=EXECUTOR,
        max_tokens=4096,
        messages=[{"role": "user", "content": f"Implement the following step:\n{step}"}],
    )
    return msg.content[0].text
 
def review(goal: str, outputs: list[str]) -> str:
    """Run the whole thing past Opus one last time for consistency."""
    joined = "\n\n---\n\n".join(outputs)
    msg = client.messages.create(
        model=ADVISOR,
        max_tokens=2048,
        messages=[{
            "role": "user",
            "content": (
                f"Goal: {goal}\nHere are the per-step results.\n{joined}\n\n"
                "Point out any contradictions, gaps, or duplication across the whole, "
                "and suggest fixes if needed."
            ),
        }],
    )
    return msg.content[0].text
 
# Opus twice (design + review) + Sonnet N times (production)
steps_text = plan("Design a shared pre-deploy check for several repositories")
steps = [s for s in steps_text.split("\n") if s.strip().startswith(("-", "1", "2", "3"))]
results = [execute(s) for s in steps]
final = review("Design a shared pre-deploy check for several repositories", results)
print(final)

Since adopting this, my Opus call count has dropped to roughly a fifth of what it was, while the design quality is nearly indistinguishable from running everything on Opus. As long as the initial plan is sound, Sonnet follows through on each step just fine.

One caveat: pass the advisor's output to the executor in a form it can act on directly. A vague plan handed to Sonnet lets interpretation drift propagate into every step. Ask Opus to plan at a granularity each step can start from immediately, and the downstream becomes far more stable.

Putting a Yen Figure on Rework — When the 5x Gap Flips

Early on I noted that people overlook rework cost. Here is the rough model I actually keep in my head, turned into numbers. Having a yardstick to return to when a call feels uncertain removes a lot of hesitation.

Two line items matter: the API cost per attempt, and the human cost of checking the output (time). For the API cost I reuse the article's premise — treat Sonnet as 1 and Opus as roughly 5.

Looking only at the API line, three Sonnet attempts (¥24) beat one Opus call (¥40). But checking each output takes 10 minutes, and valuing my time at ¥3,600/hr puts the review at ¥600 per attempt. Since attempt count multiplies review count, three Sonnet runs cost ¥1,800 in review alone versus ¥600 for one Opus run. Totals: ¥1,824 for three Sonnet attempts, ¥640 for one Opus — a 5x API gap that flips the moment you add review cost.

The break-even is simple: review cost per rework divided by the API price gap. The more human effort a check requires, the more Opus wins; outputs you can judge in seconds, like a visual tweak, have near-zero review cost, so adding Sonnet attempts is always cheaper. In the gray zone, this is the first thing I estimate in my head.

As a procedure, four steps settle it in about 30 seconds:

1. Estimate how long checking the output takes (seconds / minutes / tens of minutes).
2. If it is seconds, send it to Sonnet and push on attempt count.
3. If it is minutes or more, mentally multiply expected reworks by review cost.
4. If that exceeds the API price gap, hand it to Opus in one shot.

This yardstick pays off when paired with monthly cost design. Per-token reduction is covered in Anthropic API Cost Optimization Guide: Cut Your Monthly Bill by 50-70%, and end-of-month forecasting in Forecasting Claude API token costs with ±10% accuracy from the first three days. Layer those two onto model routing and you can see which task runs on which model for how much per month.

Turning the Mental Math into a Function — Escalate on Failure

The yardstick above works fine when I am the one typing the prompt. It falls apart inside an automated pipeline, where there is no human left to do the arithmetic.

My first attempt hardcoded the routing by task type. It broke almost immediately. "Production review goes to Opus, drafts go to Sonnet" sounds clean until a genuinely hard draft shows up.

What I run now sends everything to Sonnet first, then promotes to Opus only when a machine-checkable verification fails.

from dataclasses import dataclass
from typing import Callable
 
import anthropic
 
client = anthropic.Anthropic()
 
SONNET = "claude-sonnet-4-6"
OPUS = "claude-opus-4-6"
 
 
@dataclass
class RouteResult:
    text: str
    model: str
    escalated: bool
 
 
def _ask(prompt: str, model: str) -> str:
    message = client.messages.create(
        model=model,
        max_tokens=2048,
        messages=[{"role": "user", "content": prompt}],
    )
    return message.content[0].text
 
 
def route(prompt: str, verify: Callable[[str], bool]) -> RouteResult:
    """Sonnet first. Promote to Opus only when verify() returns False."""
    draft = _ask(prompt, SONNET)
    if verify(draft):
        return RouteResult(draft, SONNET, escalated=False)
 
    final = _ask(prompt, OPUS)
    return RouteResult(final, OPUS, escalated=True)
 
 
# Keep verify to things a machine can decide in seconds
def valid_json(text: str) -> bool:
    import json
    try:
        json.loads(text)
    except json.JSONDecodeError:
        return False
    return True
 
 
result = route("Reshape the following log into a JSON array: ...", verify=valid_json)
print(result.model, result.escalated)

Everything hinges on verify. Does the JSON parse? Do the generated tests pass? Does the linter stay quiet? The moment you put a criterion in there that only a human eye can settle, the whole mechanism gets swallowed by the review cost from the previous section.

When Escalation Beats Going Straight to Opus

Let r be the escalation rate, Cs the Sonnet price, Co the Opus price. Escalation costs Cs + r × Co in expectation; going straight to Opus costs Co. The former wins under this condition:

At a 5x gap, "Sonnet first" stays correct until Sonnet fails eight times out of ten. Almost no real task reaches that. My own pipelines sit between 12% and 18%.

So default to escalation when you are unsure. Just make sure escalated lands in your logs. A task type whose r suddenly climbs is telling you that Sonnet was never the right fit — and from there you can decide whether to fix the prompt or route it to Opus directly.

Carrying the 4.6 Yardsticks Over to the Current Lineup

Everything above is a record from when the 4.6 series was current. Sonnet 5 has since become the default model, and Opus has moved on to 4.8.

The names changed. The yardsticks didn't — cost of rework, who gets hurt when it fails, whether the question is searchable. What changes is the numbers you plug into them.

The code migration itself is a constant swap.

# 4.6 generation
SONNET = "claude-sonnet-4-6"
OPUS = "claude-opus-4-6"
 
# Current generation
SONNET = "claude-sonnet-5"
OPUS = "claude-opus-4-8"

Three things, though, don't end with swapping constants.

A Narrower Price Gap Moves the Escalation Break-Even

When a new generation arrives, the price ratio between Sonnet and Opus changes. Introductory pricing and revision dates come and go, so always confirm the numbers yourself on the official pricing page.

The escalation condition from the previous section, r < 1 − Cs / Co, follows the price ratio directly. The "r < 0.8" that came out of a 5x gap gets stricter as that gap narrows.

At a 1/2 ratio, a 50% escalation rate is the break-even. My pipeline's 12–18% still has room, but "send it to Sonnet first and it's cheaper" stops being unconditionally true.

Practically: once September starts, pull your escalated logs and rerun the math at that month's actual rates. Finding which row of the table your escalation rate lands on takes a few minutes.

"It's Long, So Send It to Opus" No Longer Applies

In the benchmark section I listed the million-token context as a point in Opus's favor. At the time it was a beta feature on Opus 4.6.

Whether the current Sonnet handles long contexts is something to confirm in the official model specs. If it does, input length has essentially stopped being a reason to reach for Opus; what remains is depth of reasoning, not size of input.

I moved my own "read several repositories' code at once" work over to Sonnet accordingly. The volume you feed a model and the difficulty of the judgment you pull back out of it turned out to be separate axes.

Audit Parameters That Get Retired

When models change, generation-specific options (a setting like speed: "fast", for example) can be retired. Once one is, sending the parameter may make the call fail. Check the official deprecations list for the actual date.

Settings buried in an automation pipeline are the ones you never reread while they're working. Three checks are enough to avoid a surprise on the day.

Miss the third one and a nightly batch fails without a sound, night after night. That cost me a full day once, and ever since I check the notification path before the migration itself.

My Current Ratio

For reference, back when I was running the 4.6 generation, my mix sat at roughly 80% Sonnet and 20% Opus. That split has barely moved across generations. As the top model gets stronger, the tier below it rises too, so the ratio itself stays fairly stable.

Sonnet at 80% isn't laziness — it's that most tasks genuinely fit Sonnet. The 20% Opus mostly gets consumed at the moment "Sonnet clearly isn't going to make it."

The thing to try this week: measure your own ratio. Note every time you reached for Opus, then count how often Opus was truly necessary. Below 30% means you can probably swap most Opus calls for Sonnet with no quality loss and a smaller bill. If you find lots of "I used Sonnet but it should have been Opus" moments, you have an underused quality lever.