Model Guide

Claude Sonnet vs Opus: Current Prices and a Narrow Coding Test

Choose a specific Sonnet and Opus version before comparing cost. As of October 12, 2026, Sonnet 5.5 lists at $2/$10 per million input/output tokens and Opus 5.5 at $4/$20. Our archived July test covers six older configurations, all scoring 9/9 on short Python tasks. It does not establish that today's models are equal on production coding agents.

First choose the meter: subscription allowance or API work

Your actual questionUse this evidenceDo not substitute
Why did Opus consume my app allowance faster?Actual plan, selected model and the app's usage noticeA per-million API price ratio
Which API route costs less for accepted coding work?All usage and retries divided by accepted tasksEqual token counts or nine easy passes
Did the newer pair perform better?A paired run of those exact versions on the intended taskThe July chart of older models

The historical chart is now beside its July table rather than before the current decision. Its six configurations and original prices remain unchanged. This page does not convert those results into a new 5.5 benchmark.

The practical choice: compare successful work, not family names

For a cost-constrained workload, a sensible experiment is to establish a Sonnet baseline and test whether Opus reduces failures, retries, or review effort enough to justify its higher rate. That is an evaluation proposal, not a measured result for the 5.5 models.

Anthropic's current models overview recommends Opus 5.5 as its starting point for most workloads and Fable 5.1 for demanding work that still falls short. Our budget-first experiment is a different editorial choice; it should not be presented as Anthropic's recommendation.

If the task is a short, unambiguous function, the archive below is relevant evidence. If the task requires repository exploration, multiple edits, commands, or recovery from a bad step, the archive is not enough to select a production model. A test that is easy for both models can hide the difference you are trying to measure.

Current API prices, separate from the archive

These are Anthropic's direct-API USD rates, checked October 12, 2026. They are not chat subscription prices or a quote from an intermediary. Official pricing

Version Input / 1M Output / 1M Cache read / 1M Evidence on this page
Sonnet 5.5 $2 $10 $0.10 Documentation; not benchmarked here
Opus 5.5 $4 $20 $0.20 Documentation; not benchmarked here
Sonnet 5 $2 $10 $0.20 Archived July run below
Opus 5 $5 $25 $0.50 Archived July run below
Sonnet 4.6 $3 $15 $0.30 Archived July run below
Opus 4.8 $5 $25 $0.50 Archived July run below

The current table still lists Sonnet 5 at $2/$10. The previous article's forecast that it would become $3/$15 on September 1 is not used as a current price. This correction does not promise that today's rates are permanent.

The 5.5 pair has a 2x base token-price ratio, while Sonnet 4.6 versus Opus 4.8 has a different ratio. Specify the versions when answering "is the Opus premium worth it?" Cache writes, actual token counts, routing, and tool charges can change the cost of completed work. A per-token ratio is not a measured cost-per-task ratio.

API cost is not Claude subscription usage

If your question is "why does Opus use up my Claude plan faster?", a dollar-per-million API table is the wrong meter. Compare the allowance notice and usage shown for the actual app, plan, model, and session. This page does not assign a universal message-to-token conversion or claim the allowance multiplier equals the API price ratio.

For an API workload, keep the model ID, provider, rate date, input/output usage, cache categories, tool charges, and retry costs in the evaluation record. For a subscription workload, keep its observed allowance and reset notice separate. Do not convert one into the other without product-specific evidence.

The Claude API pricing guide provides broader billing context. If the problem is an error rather than model selection, use the rate-limit guide.

Archived July results: six configurations, the same 9/9

The following rows are retained from the previously published benchmark. Their measured score, mean latency, reported reasoning-token count, and historical pricing dates have not been replaced with current rates. No new model run was performed for this revision.

ModelScoreMeasured cost / 1k tasksMean latencyReasoning tokensList price in / out per 1MPriced at
Claude Haiku 4.59/9$0.943.7 s0$1 / $52026-07-29
Claude Sonnet 59/9$1.677.2 s0$2 / $102026-07-17
Claude Sonnet 4.69/9$2.224.9 s0$3 / $152026-07-29
Claude Opus 4.89/9$4.056.1 s0$5 / $252026-07-17
Claude Opus 59/9$5.645.3 s6$5 / $252026-07-30
Claude Opus 5 Fast9/9$10.203.4 s6$10 / $502026-07-30
The Claude ladder: same 9/9, $0.94 to $10.20 per 1,000 tasksNine executed Python tasks, temperature 0, one scored attempt each. Every bar below scored 9/9.Claude Haiku 4.5$0.94Claude Sonnet 5$1.67Claude Sonnet 4.6$2.22Claude Opus 4.8$4.05Claude Opus 5$5.64Claude Opus 5 Fast$10.20One scale throughout: 55 px per dollar. Cost is measured token counts multiplied by list price on the date shown in the table above.
Archived July 2026 test: six configurations, nine tasks each. Costs are derived from reported usage at the original dated rates, not invoices. No Sonnet 5.5 or Opus 5.5 result is plotted.

Cost here is the provider-reported token usage multiplied by the captured list price and normalized to 1,000 tasks. It is not an invoice for 1,000 executed tasks; the scored set contained nine tasks per model. Different rows were captured on different July dates, not in one simultaneous experiment.

For this set, Sonnet 5's derived $1.67 cost was lower than Opus 4.8's $4.05 and Opus 5's $5.64, with all three scoring 9/9. That gives a reason to test a cheaper configuration on similarly bounded work. It does not show that a newer Opus costs more than Sonnet on every task or that nine successes establish equal general capability.

The $5.64 versus $4.05 Opus difference came from reported token usage at the captured rates, not a change to either row's list price. The archive cannot isolate answer length, tokenizer behavior, or other causes of that difference. Latency is also a sample observation, not a service-level promise.

What the test did not reach

The nine tasks were two_sum, valid_parentheses, merge_intervals, roman_to_int, lcs_len, flatten, top_k_words, token_bucket, and parse_csv_line. Each was a self-contained Python function with a stated contract and hidden assertions. There were no repository edits, tools, multi-turn recovery, vision tasks, or long-context trials.

The published harness used temperature 0, a 4,000-token output ceiling, one scored attempt, and isolated execution with a 12-second timeout. API-error retries were permitted; wrong answers did not get another scored attempt. Calls used OpenRouter rather than DataLLM Lab's gateway. See the full benchmark and methodology for the shared method.

Nine tasks and one run per configuration do not estimate a broad failure rate. The output ceiling can also affect verbose answers. Keep the original settings and capture dates with the results; do not relabel them as Sonnet 5.5 or Opus 5.5 results.

A transparent cost example, not a bill

Take an invented request with 50,000 uncached input tokens and 2,000 output tokens, with no cache writes, server-side tools, fast mode, or other pricing modifiers:

Model Input calculation Output calculation Hypothetical request cost
Sonnet 5.5 50,000 / 1,000,000 x $2 2,000 / 1,000,000 x $10 $0.12
Opus 5.5 50,000 / 1,000,000 x $4 2,000 / 1,000,000 x $20 $0.24

This calculation holds token counts equal on purpose. Real model outputs need not be equally long, and an Agent run may make many calls. Recompute using the usage actually reported for each configuration rather than applying this example to a real bill.

Suppose, purely as an illustration, that a Sonnet workflow costs $0.12 per attempt and succeeds on half its attempts, while an Opus workflow costs $0.24 and succeeds on all of them. The average cost per success would be $0.24 for each. Those success rates are invented for the arithmetic; neither appears in our benchmark. The point is to include failed attempts rather than to infer an Opus advantage.

Test the premium on a real coding-agent task

Use a fixed repository snapshot and a task with an independent acceptance test. One candidate is a small cross-file API change that requires updating validation, a caller, and tests while preserving an existing behavior. Write the success criteria before either model starts. Do not choose or change the grader after seeing the outputs.

The following evaluation contract is a proposal, not an executed comparison:

Field Keep fixed or record
Starting point Same commit, dependencies, task description, and allowed context
Configuration Exact model ID, provider, effort setting, cache state, and rate date
Permissions Same file, shell, and network boundaries; no production credentials
Limits Same approved time, spend, and tool-call ceilings; stop on any exceeded limit
Grader Hidden tests plus a review of unintended changes and unsafe operations
Repeats Predeclare repeat count and retry rules; record every failed run
Cost All calls and retries, cache categories, and tool charges, including failures
Timing Full time to accepted result, not just the first response
Decision Cost per accepted task alongside completion rate and required human review

Compare total evaluated spend / accepted tasks for the same task set. If a configuration accepts no tasks, report zero completions rather than inventing a finite cost per success. Keep a failure log so a model that produces plausible but unusable code cannot look economical merely because its calls are cheap.

Escalating only failed cases to Opus is a third configuration, not the same experiment as all-Sonnet or all-Opus. Measure the initial call, escalation, lost time, and review together. Do not advertise a savings percentage before running that configuration.

Keep historical comparisons in their historical context

Searches such as "Sonnet 4.5 vs Opus 4.1" concern different versions, availability, and rates. Neither model is in this page's six-row test. As of October 12, Anthropic lists Opus 4.1 as retired since August 5, and Sonnet 4.5 as deprecated with retirement scheduled for November 30, 2026. Partner-operated platforms can have different schedules. Official deprecation list

Do not apply the old pair's premium to the current 5.5 pair. For an existing integration, check its provider's actual model ID and availability before deciding whether to preserve, migrate, or benchmark it.

This page's job is family selection with a clearly bounded archive. The Haiku 4.5 review and Opus 5 review retain their model-specific context. The common method stays linked, instead of being reproduced as a new benchmark on every comparison page.

FAQ

Should I choose Sonnet or Opus for production coding?

Test the exact versions on representative work. The July single-function archive supports a cheaper baseline experiment, but it does not measure production Agent quality or the 5.5 pair.

Did the latest Sonnet and Opus both score 9/9 here?

No. The six archived configurations scored 9/9; Sonnet 5.5 and Opus 5.5 were not run for this page.

Is the Opus premium 1.67x or 2x?

It depends on versions and billing categories. The October 12 direct-API base rates for Sonnet 5.5 and Opus 5.5 have a 2x ratio. That is not a subscription allowance multiplier or a measured task-cost ratio.

Is the archived cost my expected bill?

No. It is derived from nine-task usage and historical list rates. Your task size, output, retries, cache use, provider, and pricing modifiers will differ.

Written by

Prepared with AI assistance. This revision checks documentation, consolidates dated records and tests offline examples. It does not claim new model, integration or hardware runs.