Claude Sonnet 5 vs Opus 4.8 (2026): The Cost Math I Actually Use to Pick

Everyone opens the comparison the same way: Sonnet 5 costs less per million tokens than Opus 4.8, therefore Sonnet 5 is the budget pick. That's true and it's also the exact reasoning that quietly runs up my bill when I'm not careful. Per-token price is an input. The thing you actually pay is tokens spent × price × attempts-until-it-works, and a cheaper model that needs three attempts on a hard task can cost more than the expensive one that nails it on the first.

So the metric I route on is cost-per-completed-task: total token spend to actually finish a job — retries, failed edits, and recovery included — over successful completions. On simple work the two models land close on tokens, so the cheaper per-token model wins outright. On hard, open-ended work a more capable model reaches the answer with less flailing, and that efficiency is why a 67% higher sticker price doesn't become a 67% higher bill.

Here's the honest side-by-side. Prices are per million input/output tokens; benchmark numbers are the agentic-coding ones I actually care about.

Notice the gap on SWE-bench Pro is about six points — real, but smaller than the Opus-vs-Sonnet gaps of a year ago. Sonnet 5 closed most of the distance. That's the whole reason the routing question got interesting: Sonnet is now good enough that Opus has to earn the upgrade on a given task rather than being the obvious default for anything serious.

Sonnet 5 is my default because most agent work isn't actually hard — it's just repetitive. The blog post you're reading was researched, written, illustrated, QA'd, and published by a Claude Code agent, and Sonnet 5 does that job for pennies. Anything with a clear path and a clear finish line belongs here:

• High-volume, scheduled automation where I'd never want to pay a premium model per run.
• Well-scoped edits, tests, and refactors where the plan is obvious before the run starts.
• Latency-sensitive work — chat, real-time tools — where Sonnet's speed is a feature.
• Anything I run hundreds of times, where a small per-token saving compounds into real money.

The move that saves the most here isn't the model choice at all — it's not re-buying the same context every run. I get more out of prompt caching on the stable prefix than I do from any Sonnet-vs-Opus decision, and I fence the unattended runs with hard cost controls so a runaway loop can't quietly cost me $40.

I reach for Opus 4.8 the moment a task shows the loop signal: the run starts re-reading the same files, retrying the same failing edit, or spending turns without visible progress. That flailing is Sonnet telling me the task is above its comfort zone — and every one of those wasted turns is tokens I'm paying for anyway. Switching to Opus there frequently ends up cheaper per finished task, not more expensive, because it stops the spiral.

• Sprawling multi-file reasoning where the fix in one place depends on three others.
• Non-obvious debugging — the bug isn't where the stack trace points.
• Long-horizon agent jobs where staying coherent over many steps matters more than speed.
• Anything where a wrong answer is expensive: migrations, money logic, irreversible writes.

The counterintuitive part I keep having to re-explain to clients: paying more per token can lower your total bill. A model that finishes a hard task in one clean pass beats a cheaper one that needs three attempts plus the human time to notice it failed. That's the same token-economics lesson I ran into with fan-out in why Claude subagents cost 4x more tokens — the per-unit price is never the number that matters on its own.

Concrete example from my own stack. My daily content agent runs on Sonnet 5 and finishes a full research-write-illustrate-publish cycle well inside a dollar — do that every day and it's a rounding error. But when I point an agent at a real refactor across a dozen files, Sonnet sometimes gets 80% there and then starts thrashing on the last hard 20%: re-reading, re-editing, second-guessing. Left alone, that tail can burn more tokens than the productive first 80% did.

Escalate that same task to Opus 4.8 and it tends to walk straight through the part Sonnet choked on. Yes, each token is roughly 1.7x the price. But it uses far fewer of them and doesn't need a do-over, so the finished-task cost lands close to Sonnet's — and I get the result instead of a half-broken branch. Sonnet-by-default, Opus-on-escalation isn't a compromise; it's the cheapest reliable option once you count retries.

If you want the deeper version of this thinking, I broke down single-model spend in my Sonnet production review, and the tool-choice layer above the model in Claude Code vs n8n. The official Claude models overview and Anthropic's pricing are worth checking straight from the source, since intro rates change.

• Sonnet 5 is cheaper per token ($3/$15, $2/$10 intro thru Aug 31) than Opus 4.8 ($5/$25) — but per-token price isn't your real cost.
• Opus 4.8 leads agentic coding (~69% vs ~63% on SWE-bench Pro) and finishes hard tasks in fewer tokens and fewer retries.
• Route on cost-per-completed-task, not cost-per-million-tokens — a cheap model that needs three tries can cost more than one clean expensive pass.
• Default to Sonnet 5 for volume, structure, and speed; escalate to Opus 4.8 the moment a run starts looping on a hard task.
• Caching the stable prefix and capping runaway loops saves more than any Sonnet-vs-Opus decision on its own.