Stop Paying Opus Prices for Sonnet Work

Same ticket. Same repo. Same setup. I sent one real planning task to Sonnet 5 and its twin to Opus 4.8, measured the real bill from the transcripts, and priced it with each model's actual rate card. Sonnet cost $3.99. Opus cost $10.18, about 2.5× (on Sonnet's intro pricing; closer to 1.7× once that ends, more below).

The specs were close on surface quality. Opus did catch one nastier issue, which I'll get to. But close enough that the price gap, not the quality gap, is what should drive your routing.

So here's the rule I run now: send the work to Sonnet by default, and pay Opus prices only for the tickets that actually earn them. The instinct I see most often is the opposite, reach for the biggest model "to be safe." On this ticket that instinct cost more than it bought.

One honesty note up front, because it's load-bearing: this is one task run once (a scoped single-file Python bug). The dollars are measured (computed from the run transcripts against the published per-token rates, not the agent's own guess at its usage), but one measured run is not a controlled benchmark. Treat the numbers as a real receipt from my setup, not a law of nature.

Why does the bigger model cost more even when it writes less?

Here's the part that broke my intuition. Opus didn't just cost more; it cost more while using fewer tokens.

The Sonnet run burned about 1.88M effective-billable tokens. The Opus run: 1.74M. Opus did the same job with a slightly smaller total token bill (mostly cache, not output) and still charged 2.5× as much.

So the gap comes down to the rate. Opus 4.8 bills $5 / $25 per million tokens in/out; Sonnet 5 is on intro pricing at $2 / $10 through 2026-08-31 (then $3 / $15). The frontier model charges more per token, full stop. The comforting story that the smarter model is more concise, so it evens out? It doesn't even out. You pay the premium rate on every token, and the token count doesn't drop enough to save you.

If you've been justifying the bigger model to yourself with "it'll be more efficient," check the receipt. Mine didn't cooperate.

Where does the money in an agent run actually go?

Not where you'd think. On the Opus run, generation (the actual spec it wrote) was the minority of the bill.

The breakdown: $5.18 to write context into the cache, $2.83 to read it back. That's $8.01 of the $10.18, about 79%, spent on cache traffic (measured). The model's output was the cheap part.

Part of why: a real planning run re-reads, a lot. It spawns an audit loop, an auditor and a judge that re-read the ticket, the code, and the draft spec to check the work, and each sub-agent re-pays to move that context around. But even without the audit loop, cache creation and reads dominate the bill. It's a general property of an agent that keeps reloading context it has already seen.

This is the same lesson as the context tax: the cost lever on a long-running agent is how efficiently it handles context it's already seen, not how short you can make the output. Trimming the model's answer to save money optimizes the 21%.

Is turning up "reasoning effort" worth it?

Yes, and it's a safer dial to turn than jumping model tiers, because turning effort up keeps the per-token rate fixed. As long as you measure it honestly.

I ran Opus at three effort levels on the same ticket. (These runs used a lighter planning path with no audit loop, so their dollars aren't directly comparable to the $10.18 full-run probe above; the audit loop is a chunk of that gap. Compare them only to each other.) Measured from transcripts:

• medium — $5.23. Fixed the primary bug and missed a sibling case.
• xhigh — $7.05. Caught both, and was the only run to stop and ask whether the fix was even correct.
• max — $7.79. Caught both, plus a latent bug and an import constraint.

Cost ramps cleanly with effort. Quality is messier. xhigh caught the core bugs and uniquely questioned whether the fix was right. Max, for about 10% more, found two more latent issues that xhigh missed. I lean xhigh — near-top results at about 90% of max's cost, and it was the one run to check its own premise. But that's a judgment call about which kind of catch matters more.

The research on test-time compute says more thinking helps, then flattens, and can even backfire at the very top (Inverse Scaling in Test-Time Compute). I didn't see max backfire here; it caught the most. So I reach for xhigh by default and save max for when I want every last latent bug.

(Caveat: this effort sweep was Opus-only, one run per level — a direction, not a law.)

But isn't Opus just better?

A little. Not 2.5×-better, at least not here, and I want to be careful not to oversell it, because it rests on a single matched pair.

When effort was held equal, Opus caught a nastier issue than Sonnet: it flagged that a regeneration command in the plan would have clobbered baseline data, where Sonnet raised a softer accuracy warning. Opus's internal judge also demanded another review round. So on quality, Opus is at least as strong as Sonnet once you stop under-powering it — a real edge, but a marginal one, seen on one run. I wouldn't route on the quality gap. I'd route on the price gap, which is measured and large.

Worth saying plainly: an earlier round of this same study had Opus looking worse than Sonnet. That was an artifact. I'd tested Opus only at an effort setting that under-grounds on this kind of work, so it turned in a thin spec. Control the effort dial and that result reverses. A lot of "model X is worse" takes are really "I ran model X wrong."

So what's the routing rule?

Route by the ticket's actual difficulty:

• Sonnet by default. Near-Opus quality at roughly two-fifths the cost (intro pricing; nearer three-fifths once it ends). This is where the bulk of the work should go.
• Opus for the genuinely hard tickets, where a marginal quality edge is worth paying 2.5× for. They exist. They're rarer than your instinct says.
• Fable for the hardest / longest-horizon work only. At $10 / $50 per million it's about 2× Opus again, so call it ~$20 on this workload (extrapolated from the rate, not a measured Fable run). Reserve it.

This isn't a fringe idea, and I'm not the first to measure it. FrugalGPT reported matching a top model's quality at up to 98% lower cost by trying cheap models first and escalating only when needed. RouteLLM hit 85% cost savings (on MT-Bench) at 95% of GPT-4's quality, sending only 14% of queries to the strong model.

The difference: those are benchmark numbers from routing a fleet of queries. Mine is one coding agent, one ticket, with the dollars measured off the actual run. Smaller claim. But it's a receipt, not a leaderboard, and it points the same direction.

The knob you didn't know you were turning

One trap worth naming, because it quietly changes what you're paying for. How you launch the agent changes what it actually runs.

When I spawned /plan as a proper sub-agent, it ran the full thing, auditor and judge and all. When I ran the same command inside a workflow, it silently degraded to a lite version with no audit loop at all, because a workflow-spawned agent has no way to spawn its own helpers. Same command. Same model. Quietly different behavior, and no error to tell you. That's also why the effort-sweep numbers above ran cheaper than the full-run probe: no audit loop to pay for. If you care about the audit loop that catches the expensive mistakes, check that your launch path can actually run it.

Takeaways

• Default to Sonnet. On a matched run it did the job for $3.99 vs Opus's $10.18, about 2.5× on Sonnet's intro pricing, nearer 1.7× once that ends (measured, one ticket). The quality gap didn't come close to justifying it.
• The bigger model's per-token rate is the cost, not its verbosity. Opus used fewer tokens and still cost more. "It'll be more concise" won't save you.
• About 79% of an agent run's bill is cache traffic (measured). Optimize context re-reading.
• Effort buys quality and cost together. I default to xhigh at about 90% of max's cost, and save max for when I want every last latent bug.
• Reserve the frontier model for the tickets that earn it.

Biggest isn't best. Biggest is just biggest. Pick the model the task actually needs, and keep the frontier tier for the day the task actually needs it.

FAQ

Will Sonnet still be cheaper than Opus after the intro pricing ends?
Yes, just by less. Sonnet 5's intro rate is $2/$10 per million through 2026-08-31; after that it's $3/$15, versus Opus 4.8 at $5/$25. So the matched-run gap narrows from about 2.5× ($3.99 vs $10.18) to roughly 1.7×. Still Sonnet-favorable.

Should I just set reasoning effort to max to be safe?
Usually no. Cost rises cleanly with effort while the extra quality flattens near the top. On my runs, xhigh caught the core bugs and uniquely questioned the fix at about 90% of max's cost; max found a couple more latent issues for the extra spend. I default to xhigh.

Is one measured run enough to route all my work on?
No, and I'm not claiming it is. These are measured dollars from a single ticket in my setup, not a controlled benchmark. Treat the direction as solid — route cheaper by default, reserve the frontier tier — and re-measure on your own workload before hard-coding a policy.