Opus vs Sonnet: what the smarter model actually costs

The two numbers that matter

Every frontier model lab currently ships at least two tiers of the same generation: a larger, more capable model and a smaller, cheaper sibling trained to handle most of the same workload at a fraction of the cost. Anthropic's current lineup is a clean example — Claude Opus 5 at $5 / $25 per million input/output tokens, and Claude Sonnet 5 at $3 / $15 (discounted to $2 / $10 through an introductory window). Same generation, same API, a real gap in price.

The question worth working through carefully is not "which one is better" — Opus-tier models are, by design, the stronger model on hard reasoning and long-horizon work. The question is what that price gap actually costs you across a real coding-agent workload, and where it's worth paying it. That's an arithmetic question with a documented rate card, not a mystery.

The published rate gap

Here's the published Anthropic rate card as of this writing, per million tokens:

At sticker price, Opus-tier costs about 1.67x Sonnet-tier on both input and output. During the introductory window that ratio widens to 2.5x, because Sonnet's promo pricing doesn't touch Opus's rate. Structurally this isn't unique to Anthropic — every lab running a two-tier lineup prices the larger model at roughly 1.5x–3x the smaller one on both sides of the token ledger. The exact multiplier moves with each pricing update; the shape — a consistent output-heavier premium on the larger model — is the durable part.

Why output tokens dominate the bill

It's tempting to think about cost as roughly symmetric between what you send the model and what it sends back. For agentic coding work, it isn't, for two independent reasons that compound.

• Output is priced higher everywhere. Anthropic prices Opus output at 5x its own input rate, and Sonnet output at 5x its own input rate too — this 5x input-to-output ratio is a durable industry pattern, not an Anthropic quirk.
• Agentic loops generate a lot of output relative to input. A single turn in a coding agent might read a modest prompt or diff, but the model's response can include extended reasoning, a multi-file patch, and a sequence of tool calls — output tokens accumulate fast in a way that a short instruction doesn't.

Put those together and the practical conclusion is: the tier you pick matters most on the output side of the ledger. A workload that's input-heavy and output-light (classification, short extraction, single-field answers) is far less sensitive to which tier you use than a workload that's output-heavy — long generations, multi-file edits, verbose reasoning traces. Coding-agent work is squarely the second kind.

A worked example (illustrative, not measured)

To make the tradeoff concrete, here's an illustrative calculation — made-up but representative token counts, run through the real rate card above. This is arithmetic on assumptions, not a benchmark result.

Suppose a single agentic coding turn involves 3,000 input tokens (file context, instructions, prior turns) and 2,000 output tokens (reasoning plus a patch). At sticker pricing:

Opus-tier turn:
  input:  3,000 tokens * $5.00 / 1,000,000  = $0.0150
  output: 2,000 tokens * $25.00 / 1,000,000 = $0.0500
  total:                                      $0.0650

Sonnet-tier turn (sticker, not intro pricing):
  input:  3,000 tokens * $3.00 / 1,000,000  = $0.0090
  output: 2,000 tokens * $15.00 / 1,000,000 = $0.0300
  total:                                      $0.0390

ratio: $0.0650 / $0.0390 ≈ 1.67x

Now scale that to a session with, say, 40 turns of similar shape — again, illustrative, not a measured session length. That's roughly $2.60 on Opus-tier versus roughly $1.56 on Sonnet-tier, a gap of about a dollar per session. Whether that gap matters depends entirely on what you're doing with the session — for a single engineer running occasional sessions it's noise, for a fleet of agents running thousands of sessions a day it's a real line item worth managing deliberately rather than defaulting into.

Notice what drove the gap: the output side. In this example, output tokens accounted for $0.05 of the $0.065 Opus-tier turn — about 77% of the cost — because output is priced 5x higher than input on both tiers. Shifting a workload's balance toward longer generations (more reasoning, bigger diffs, more retries) increases the tier gap faster than shifting the input side does. This is the mechanism, not a coincidence of the specific numbers chosen above.

The actual decision framework

None of this argues for always picking the cheaper model, and it doesn't argue for always picking the larger one either. It argues for a default plus an escalation path, which is how most teams running coding agents at any scale actually operate in practice:

• Default the execution loop to the cheaper mid-tier model. Most of a coding session is mechanical: reading files, making an edit that's already been planned, running tests, fixing an obvious lint error. The mid-tier model handles this well, and it's the loop that runs the most turns — so it's also where the price gap compounds the most.
• Escalate to the larger model for planning. Before a nontrivial change, a single planning pass on the stronger model — deciding the approach, the files touched, the risk areas — is usually a small number of tokens relative to the execution that follows it, and a bad plan is far more expensive to correct later than a good plan is to buy up front.
• Escalate to the larger model when the cheaper one gets stuck. If the mid-tier model fails a task twice, or produces a fix that doesn't hold, that's the signal to hand the specific failing step to the larger model rather than retrying the same tier a third time. This targets the spend at the moment it has the best chance of actually paying off.
• Don't escalate the whole session because one step needed it. The point of tiering is that the escalation is scoped to the hard step, not the whole conversation — most agent harnesses can swap models mid-session without losing context, so there's no reason to pay the larger model's rate for the mechanical turns that follow a hard one.

Caching changes the math, not the shape

Prompt caching complicates the raw numbers above without changing the conclusion. Cached input tokens are billed at a steep discount off the base input rate on both tiers, which lowers the input side of the bill for both models roughly proportionally — it doesn't flip which tier is cheaper, and it doesn't touch output pricing at all. If anything, caching makes the output-token gap a larger share of the total bill, because it shrinks the input side while leaving the output side untouched. The decision framework above holds either way: caching is an optimization layered on top of the tier choice, not a substitute for making it deliberately.