Claude Opus vs Sonnet for Coding: The Honest Split

Every Claude shop faces the same question on every ticket: Opus judgment or Sonnet value? The price gap is wide — roughly 60/40 on blended workloads — while the quality gap is narrow on routine work and decisive on hard problems. Getting the split right is the single highest-leverage cost decision for Claude-heavy teams. This guide maps which tickets genuinely need Opus, which finish identically on Sonnet, how to route between them per ticket, and the measurement habit that keeps the split optimal as generations turn over.

Tickets where Opus pays for itself

Opus earns its premium exactly where mistakes are expensive: autonomous multi-file refactors, subtle Heisenbugs, architecture decisions with blast radius across services. On these tickets the relevant cost is not tokens but supervision cycles — and Opus consistently needs fewer of them. One avoided wrong-direction refactor pays for weeks of price difference.

The tell is reversibility cost. When a wrong approach wastes hours of review and rework, flagship judgment is cheap insurance. When mistakes cost minutes, it is overinsurance. Classify tickets by reversibility before assigning models and the split becomes mechanical rather than philosophical. Most teams find 10 to 20 percent of tickets genuinely deserve Opus; the argument is only ever about which 10 to 20 percent.

• Judgment errors cost hours, tokens cost cents
• Autonomous refactors and subtle debugging
• Architecture decisions with blast radius
• Supervision cycles as the real currency

Tickets where Sonnet is identical

The large majority of tickets do not need flagship judgment: bulk renames, boilerplate generation, test scaffolding, CRUD endpoints, dependency updates, mechanical migrations. Sonnet completes these indistinguishably from Opus at a fraction of the price — same merged diffs, same test results, same review time. Defaulting these to Opus is the most common overspend in Claude shops.

Well-specified tickets especially favor Sonnet: when acceptance criteria are crisp, judgment has little room to add value and execution speed dominates. Write better tickets and watch Sonnet-adequate share grow — specification quality and model requirements trade off directly. Teams that invest in ticket clarity routinely run 80-plus percent of volume on Sonnet with zero quality regression.

• Bulk edits and boilerplate
• Well-specified routine tickets
• Test scaffolding and CRUD
• Same output, fraction of price

Route per ticket, not per team

Static assignment — everyone on one model — wastes the gap in both directions. Route per ticket instead: default Sonnet, with escalation triggers for known-hard categories (concurrency, distributed systems, security-sensitive code) and stall signals (two failed approaches, growing diff without progress). The router can be a human dispatcher, a triage prompt, or team convention; sophistication matters less than consistency.

Document the convention where developers find it: default model, escalation triggers, who decides. Review routing decisions monthly against outcomes — escalations that changed nothing indicate trigger drift; tickets that struggled on Sonnet indicate missing triggers. Dynamic routing feels like overhead until the first invoice comparison; then it looks like the obvious professionalism it is.

• Difficulty signals at dispatch
• Stall detection and escalation
• Static defaults with dynamic override
• Documented routing convention

Measure the split, don't debate it

Run identical tickets on both models for two weeks and score merged results per dollar with review time included. The outcome is almost always the same shape — Sonnet-default with Opus escalation — differing only in ratio. That ratio is your team's number; no benchmark or blog post (including this one) substitutes for it.

Publish the result internally with the methodology attached. Future model generations change the numbers but not the method; re-running the same experiment quarterly takes days and keeps routing optimal permanently. Teams that measure stop arguing about models entirely — the spreadsheet routes, humans review, and the discussion moves to ticket quality where it belongs.

• Identical tickets, both models
• Merged results per dollar
• Review time included always
• Ratio varies, pattern persists

Keep the split optimal forever

Revisit quarterly as generations turn over: each new Sonnet absorbs yesterday's Opus-adequate tickets, each new Opus redefines the top end. Telemetry should pressure downgrades — steady success on Sonnet for a category retires its escalation trigger. Keep both models configured permanently; either can have outage days, and mutual fallback costs nothing idle.

The durable asset is the routing habit, not any particular ratio. Teams that route deliberately spend less every quarter while changing nothing about workflows. Teams that set and forget watch the gap decay as prices and capabilities move. Five minutes of dispatch thought per ticket beats five figures of annual overspend — the cheapest senior judgment you will ever buy.

• Quarterly generation reviews
• Escalation triggers maintained
• Downgrade pressure from telemetry
• Both models warm permanently

Frequently asked questions

When does Opus earn its premium over Sonnet?

Long autonomous refactors, subtle debugging and architecture decisions — work where judgment errors cost hours. For those tickets the premium buys fewer supervision cycles, which usually outweighs the token difference.

Which tickets belong on Sonnet?

Bulk edits, boilerplate, test scaffolding, routine CRUD and well-specified tickets. Sonnet completes these indistinguishably at a fraction of the price — default here and escalate deliberately.

How do I find my team's Opus/Sonnet split?

Run identical tickets on both for a week and score merged results per dollar with review time included. Most teams land on Sonnet-default with Opus escalation; the ratio varies but the pattern rarely does.

Can I route dynamically instead of picking one?

Yes. Route by ticket difficulty at dispatch time: default Sonnet, escalate on stall signals or known-hard categories. Static assignment wastes the price gap in both directions.

How often should the split be reviewed?

Keep both keys configured and review the split quarterly. Model generations move the boundary regularly; today's Sonnet-adequate ticket becomes tomorrow's Opus-worthy and vice versa.

Related guides

• Best AI coding tools 2026: an honest shortlist
• AI Subscription vs API: A Developer Cost Model That Works

Last updated: 2026-09-28