Claude Sonnet vs Opus for Coding: The Ratio Is 2.5x

Claude Sonnet vs Opus for coding gets quoted as a 2.5x decision and then reported by the tool as something near 1.3x, and both numbers are real. On this machine, on 2026-08-17, two runs of the same five-word prompt minutes apart billed $0.093764 on Sonnet and $0.121698 on Opus — a ratio of 1.300x. Priced on identical work at published rates it is exactly 2.500x. This article decomposes the difference into its three terms, shows which one you actually control, and gives the one-line change that moves the choice into git.

Key takeaways

• The model term is exactly 2.500x, for every token shape. Both models use the same cache multipliers, so nothing about how you run a session changes the ratio between them.
• The two runs did not deliver the same tokens. The Sonnet run carried 28% more billable weight than the Opus run, on the same prompt, in the same repository, minutes apart.
• Claude Code billed Sonnet at $3 per million input, not the $2 Anthropic publishes. That single stale rate is worth more than a third of the apparent gap.
• The spec sheet does not separate the tiers. Both reported a 1,000,000-token window and a 64,000-token output ceiling — the latter half the published 128k.
• Opus was faster than Sonnet on the turn we measured, which is one turn and therefore not a latency claim. It is stated because the opposite was expected.

The short answer

Spend the 2.5x where you cannot cheaply check the output. Multi-file reasoning, unfamiliar code, anything whose failure you would not notice in review — that is what the premium buys. Mechanical work you were going to read line by line anyway does not need it, and on that class of task the tier below is where the money is.

What the choice will not do is fix a cost problem. The model is a flat multiplier on a bill that your harness assembles, and on the measurement below the harness moved the number more than the model did. For everything around the model — permissions, subagents, the instruction file — the complete Claude Code guide is the pillar this sits under.

Two turns, same prompt, same repository

The method is two headless invocations with JSON output, at the same effort, minutes apart, differing only in --model. No proxy, no instrumentation, two documented flags.

claude -p "Reply with exactly: ok" --output-format json --effort low --model sonnet
claude -p "Reply with exactly: ok" --output-format json --effort low --model opus

  MODEL             IN    CACHE WR   CACHE RD   OUT   COST        WALL
  claude-sonnet-5   2     14,045     29,490     4     $0.093183  1,962 ms
  claude-opus-5     2     11,054     20,933     4     $0.121117  1,841 ms

The prompt is 2 tokens in both rows. Everything else is the harness, and the harness did not repeat itself: the Sonnet run wrote 14,045 tokens to cache and read 29,490 back, the Opus run 11,054 and 20,933. That is a 36% difference in delivered input tokens between two runs of an identical prompt, and it happened because cache state churns between invocations rather than because of anything either model did.

Both turns also billed a second model. claude-haiku-4-5 handled 521 input tokens and wrote 12, at $0.000581, on both runs and on the earlier probe covered in what model Claude Code actually uses — three probes, byte-identical auxiliary usage. Whatever that call is, it is not affected by the model you pick.

Claude Sonnet vs Opus for coding: what actually differs

Anthropic's cache multipliers are the same for both models: a cache read bills at 0.1x the input rate, a one-hour cache write at 2x, output at 5x. That has a consequence people miss.

Write the cost of any turn as a single billable weight — input, plus twice the cache writes, plus a tenth of the cache reads, plus five times the output — multiplied by the model's input rate. Then the ratio between two models on the same weight is just the ratio of their input rates. It does not matter what the weight is.

  The model term is 2.500x on Opus's shape and 2.500x on Sonnet's. It is the same
  number for every shape, because both models bill cache reads at 0.1x input and
  1-hour cache writes at 2x. Nothing you do to a session changes the ratio between them.

  Priced on identical work: $0.121117 on Opus against $0.048447 on Sonnet.

The script prices both shapes to demonstrate the invariance rather than assert it — 2.500x either way. This is the number the decision actually turns on, and it is the one figure in this article that will not move with your workload.

It also kills a common piece of advice. "Cache reads are cheap, so Opus costs less than you think" is true about the absolute bill and false about the comparison: cheap cache reads are cheap on both cards, in the same proportion. Caching changes what you pay. It does not change which model is cheaper, or by how much.

Cross a vendor boundary and the clean cancellation stops. Google bills cached tokens as rent per hour rather than a fee per write, so the Gemini and Claude comparison turns on how long the session lives — a variable that does not appear on either rate card.

Why your own session reports something else

If the ratio is a flat 2.5x, why does the tool report 1.300x? Three terms multiply, and the check prints all three:

  Model                             2.500x   identical shape, both published cards
  Shape                             0.780x   the two runs did not deliver the same tokens
  Rate the CLI used                 0.667x   Sonnet billed above its published card

  Reported by the CLI               1.300x   = 2.500 x 0.780 x 0.667

The shape term, 0.780x. The Opus run happened to be lighter than the Sonnet run — inverted, the Sonnet turn carried 28% more billable weight. Nobody chose that. It is cache state, and it is the single largest source of noise in any casual cost comparison. Two runs is not a sample; if you are benchmarking your own tiers, run each one enough times to average this term out, because it can easily exceed the effect you are trying to measure.

The rate term, 0.667x. This one is not noise. Solving for the input rate that reproduces each reported cost is arithmetic, and it gives a clean answer:

  MODEL             CONTEXT     MAX OUT    PUBLISHED  IMPLIED $/MTok IN
  claude-sonnet-5   1,000,000   64,000     128,000    $3.00  MISMATCH — card says $2.00
  claude-opus-5     1,000,000   64,000     128,000    $5.00  (card: $5.00)

Opus reproduces its published card exactly. Sonnet reproduces at $3 in and $15 out — the published Claude Sonnet 4.6 rate — while Anthropic's models overview published $2 and $10 for Claude Sonnet 5 when we read it on 2026-08-17. Every Sonnet cost the tool prints is 1.5x the card, and the check exits non-zero on that rather than rounding it away.

The practical reading: if you compared tiers by watching reported costs, you saw Sonnet as more expensive than it is and therefore Opus as better value than it is. The real gap on identical work is 2.5x, not 1.3x.

The spec sheet does not separate them

The other half of the "which Claude model for code" question is usually answered on capacity, and on current numbers there is nothing there.

Both tiers report the same window and the same ceiling. The published ceiling is 128k and the CLI reported 64,000 for both — the second corroboration on this site that Claude Code sets its own output cap at roughly half the API maximum, after the same gap turned up on the account default model in August. Worth knowing before planning a task around a single long generation, and worth knowing that it applies equally to both tiers.

So the tier decision is not a capacity decision. It is a price decision and a judgement about output you cannot verify, which is a narrower question than the comparison usually gets framed as.

Opus was faster on the turn we measured

The expected result was that Sonnet would be quicker — Anthropic's own overview lists Sonnet's comparative latency as "Fast" and Opus's as "Moderate". That is not what the two runs showed:

  claude-sonnet-5   wall 1,962 ms   time to first token 1,925 ms   API 3,709 ms
  claude-opus-5     wall 1,841 ms   time to first token 1,819 ms   API 3,221 ms

Opus finished first on all three timings. This is one turn per model and it is not a latency benchmark — it is reported because it contradicted the expectation, and leaving it out would have made a cleaner article and a less honest one. On a trivial prompt at low effort, whatever separates the tiers on real work is not the dominant term; queue time and routing are. Do not plan around these numbers, and do not plan around the vendor's latency column either without measuring your own workload.

Pinning the choice in the repository

Whichever tier you land on, the answer to "which model built this" should live in git rather than in a menu:

{
  "model": "claude-sonnet-5"
}

Two consequences worth accepting deliberately. A full id stops tracking the family, so you get the model you asked for after the next release and you own the upgrade — where the alias sonnet will silently start meaning something else. And a pinned model overrides the account default for everyone on the repository, which is usually what a team wants and occasionally is not.

The larger lever sits next to it. --effort takes five levels from low to max, and on agentic work it moves the bill and the wall clock more than swapping tiers does — a 2.5x model on low and the same model on max are not close. If a session feels expensive, measure effort before you downgrade the model; where the wall clock actually goes in a Claude Code session covers the other half of that, and best AI model for coding prices the wider lineup on the same measured turn. Both tiers also share one tokeniser, so the byte-to-token ratio is identical across them and the only place that ratio matters is a comparison against another vendor — the per-byte version of this question measures that gap at 1.206x.

What we are not claiming

This article does not rank Sonnet against Opus on output quality, and the omission is deliberate rather than an oversight.

Everything above is accounting: which model was selected, what it reported about itself, what it cost, how long it took. A quality ranking needs a fixed task set neither model has seen and a grader independent of the vendor, and this repository has neither — the committed precondition check reports zero of five met and exits non-zero on that.

Three further limits. The probes are one account, one day, one repository, one effort level, and the shape term above shows how much variance a single pair of runs carries. The rate mismatch is a statement about what the CLI computed, not about what Anthropic invoiced — we can see the tool's arithmetic and not the bill. And the whole measurement uses a deliberately trivial prompt, which maximises the share of the request that is standing context; a session doing real file reads shifts the balance between the cache-write and cache-read terms, and the absolute figures move even though the 2.500x does not.

Common mistakes choosing between Sonnet and Opus

• Reading the reported ratio as the model ratio. On these two runs the reported figure was 1.300x and the model term was 2.500x.
• Comparing two single runs. Cache state moved the bill 28% between identical prompts, with no model change involved.
• Expecting caching to change the ratio. Both models bill cache the same way, so it changes the total and not the comparison.
• Trusting the tool's cost report. One of the two models measured here bills 1.5x its published rate in the tool's own accounting.
• Choosing on context window. Both report 1,000,000 tokens, and both report an output ceiling half the published one.
• Downgrading the model before tuning effort. Effort spans five levels and moves agentic cost further than the tier does.

Conclusion

Put the tier decision where it belongs: 2.5x is the real, invariant premium, and it is worth paying on work whose failure you would not catch in review and not worth paying on work you were going to read anyway. Then commit model in .claude/settings.json so the choice stops living in a menu, and run npm run check:split against your own probes before you trust any cost figure your tooling prints — on this machine it found one of two models billing at a rate its vendor does not publish, which is the kind of thing a comparison built on tool output never surfaces.

Frequently asked questions

Muhammad Kashif

Founder and editor of Devventa, covering AI coding assistants, Next.js and the modern AI development stack.