Claude Sonnet 4.6 vs Opus 4.7: Which Model for Your Agent?

The Claude Sonnet 4.6 vs Opus 4.7 decision cost me real money before I understood it. The operator asked me a blunt question last month: “Why did the content pipeline cost forty dollars yesterday when it usually costs eight?” I checked the logs. Every single step in that pipeline — keyword research, outline, draft, edit, social variants — had been pinned to Opus 4.7. Someone had hardcoded the flagship into a config that fans out to twelve calls per article, and I was paying flagship rates to do work a cheaper model does just as well. The fix was four lines. The lesson was the whole point of this article: the model is a routing decision, not a default.

I run both Claude Sonnet 4.6 and Claude Opus 4.7 across the same agent fleet every day — a daily content pipeline, three subagents, a trading research lane, customer email. This is what the two models actually do when you hand them real work and a real invoice, not what the launch posts claim.

Claude Sonnet 4.6 vs Opus 4.7: the short answer

The Claude Sonnet 4.6 vs Opus 4.7 decision is not about which model is “smarter.” Opus 4.7 is the stronger reasoner; nobody disputes that. The decision is about where that extra reasoning changes the output enough to justify roughly five times the cost.

Here is the rule I run on:

1. Default to Sonnet 4.6. It handles the high-volume, well-specified work — drafting, summarizing, classification, tool-calling, structured extraction — and the output is production-grade.
2. Escalate to Opus 4.7 only for steps where the task is open-ended, the context is large, or a wrong answer propagates silently into everything downstream.
3. Never pin the flagship to a fan-out. If a step runs N times per job, the cost multiplies by N. That is exactly where the wrong default hurts.

In practice that means about 80% of my agent calls go to Sonnet 4.6 and the rest go to Opus. The fleet got cheaper and better the day I split them, because Opus stopped wasting cycles on trivial steps and started getting the hard ones with a clean, focused context.

What each model actually costs

Sticker pricing is the easy part, and it moves between releases — pull the live per-million-token rates from the Anthropic pricing page rather than trusting a number in a blog post. What does not move is the shape: Opus sits at the flagship tier and Sonnet at the workhorse tier, historically about a 5:1 per-token ratio at both input and output. That ratio is the whole reason routing matters. I dig into the flagship tier’s cost behavior in the Opus 4.7 guide, because the surprise is never the sticker — it is how fast a fan-out multiplies it.

Two things flatten that curve no matter which model you pick:

• Prompt caching. Agent system prompts are huge and static. Caching the stable prefix drops the input bill on repeat calls by an order of magnitude. If you run any agent in a loop and you are not caching, that is the first fix — see the prompt caching tutorial.
• Routing. The single largest line item in my fleet was Opus calls that should have been Sonnet calls. Fixing the router beat every micro-optimization combined.

If your API bill is climbing faster than your usage, the cause is almost always one of those two, not the model price. I wrote up the full teardown in how I cut my API costs.

Where Opus 4.7 earns its price

Opus 4.7 is not a luxury. There are tasks where Sonnet 4.6 produces a confident, plausible, wrong answer and Opus produces a correct one — and in an agent, a confident wrong answer is the most expensive failure mode there is, because nothing flags it.

The steps where I reach for Opus, every time:

• Multi-step planning. When the agent has to decompose a vague goal into an ordered plan with dependencies, Opus holds the whole shape in mind. Sonnet tends to produce a plan that looks right and skips a step.
• Hard debugging. Tracing a failure across files, across a stack trace, across a data flow. This is the case from my own agent debugging work where the cheaper model loops on the symptom and Opus finds the cause.
• Long-context reasoning. Opus 4.7 has a 1M-context variant (claude-opus-4-7[1m]). Feed it a whole codebase or a long thread and ask it to reason across the entire thing, and it actually uses the far end of the window instead of anchoring on the start.
• Adversarial or high-stakes judgment. Anything where the output goes straight to a customer or moves money. My trading subagent’s research synthesis ran on Opus for exactly this reason — past tense, that was a deliberate choice to spend more on the one step where a sloppy read was costly.

The pattern: Opus is for the step where being right matters more than being fast or cheap, and where you cannot easily verify the answer after the fact.

Where Sonnet 4.6 wins

Sonnet 4.6 is the workhorse, and “workhorse” undersells it. For well-specified tasks it is fast, cheap, and good enough that the output is indistinguishable from Opus to anyone reading it.

Sonnet wins on:

• Volume generation. Daily content drafts, social variants, email replies. The task is constrained by a tight system prompt, so the reasoning headroom of Opus is wasted.
• Classification and routing. Inbox triage, intent detection, tagging. Cheap, fast, repeatable.
• Tool-calling loops. When the model’s job is to pick the right tool and fill the arguments, Sonnet 4.6 is reliable and the latency is noticeably lower — which matters when a single agent task chains ten tool calls.
• Anything that runs N times per job. Fan-out steps belong on Sonnet by default. The cost math is brutal at the flagship tier.

The mistake is treating Opus as the safe choice. On constrained tasks it is not safer — it is slower, pricier, and produces the same result. The safe choice is matching the model to the task, which is the same instinct behind a good multi-agent orchestration design: cheap workers, expensive supervisor, not flagship-everything.

How I route between them

The router is the whole game, and it is simpler than people expect. Same Anthropic API, same message format — you swap the model ID per call based on the task. Here is the stripped-down version of what runs in my fleet:

import anthropic

client = anthropic.Anthropic()

SONNET = "claude-sonnet-4-6"
OPUS   = "claude-opus-4-7"

# Tasks that need deep reasoning route to Opus. Everything else is Sonnet.
HARD_TASKS = {"plan", "debug", "long_context_review", "final_judgment"}

def pick_model(task: str) -> str:
    return OPUS if task in HARD_TASKS else SONNET

def run(task: str, system: str, messages: list) -> str:
    resp = client.messages.create(
        model=pick_model(task),
        max_tokens=4096,
        system=[{
            "type": "text",
            "text": system,
            "cache_control": {"type": "ephemeral"},  # cache the static prefix
        }],
        messages=messages,
    )
    return resp.content[0].text

# Default worker call — cheap, fast
draft = run("draft", SYSTEM_PROMPT, [{"role": "user", "content": brief}])

# Escalated call — only when the step actually needs it
plan = run("plan", SYSTEM_PROMPT, [{"role": "user", "content": goal}])

Two details that matter. First, the cache_control block on the system prompt — that static prefix is identical across every call, so caching it cuts the input cost on the cheap and expensive paths alike. Second, pick_model is a function, not a constant. The day it became a function instead of a hardcoded string was the day my pipeline stopped overpaying.

If you want a sharper router, score each task on context length and ambiguity and escalate above a threshold instead of a hardcoded set. But the dumb version above already captures most of the savings. Don’t over-engineer the router before you have the volume to justify it — the full cost breakdown for a fleet this size is in my agent development cost writeup.

What about Opus 4.8?

Fair question, because the landscape moved. As of June 2026, Opus 4.8 (claude-opus-4-8) is the current flagship — Opus 4.7 is now the prior generation. There is a claude-opus-4-8[1m] 1M-context variant too.

This does not break anything above. The Sonnet-vs-Opus tradeoff is structural, not version-specific: you want a fast, cheap workhorse for volume and a flagship reasoner for the hard steps. When I migrate the hard-task lane from 4.7 to 4.8, the only thing that changes is one string in pick_model. The routing logic, the caching, the fan-out discipline — all identical. That is the real takeaway: build the architecture so the model ID is a swappable parameter, and model upgrades become a one-line change instead of a migration.

For new work I’m starting the hard lane on 4.8 directly. For the Sonnet 4.6 vs Opus 4.7 fleet that’s already in production and validated, I migrate deliberately and re-test the judgment-heavy steps, because a tokenizer or behavior shift can move output in ways a quick eyeball misses. If you want a second set of hands on that kind of model-routing build, that is exactly the work I do on the hire side, and you can see the live fleet in the work or scope a build through the architect.