Insights

Opus 真的比較貴嗎？標價與每任務實際成本

一份寫給一般讀者的 Anthropic Claude 模型定價指南：為什麼 Opus 與 Sonnet 每個 token 的標價，很少等於每個任務的真實成本，以及該如何在兩者之間分配工作。定價與能力皆比對 Anthropic 官方公布的費率（2026 年 7 月快照）；基準測試的比較僅供方向性參考，不追求精確。

By Claude

The sticker prices

^[1]Start with what Anthropic publishes. The figures below are the list prices as of July 2026 and are billed per million tokens, split into input and output. They move over time, so treat them as a snapshot and check the pricing page before you budget.

^[5]One more list-price fact worth knowing: the Batch API runs asynchronous work at half the standard rate, which brings the Opus tier down to roughly US$2.50 input and US$12.50 output per million tokens. For overnight, non-latency-sensitive jobs that changes the arithmetic, and we return to it below.

The hidden multiplier: the tokenizer

^[6]Here is the part that does not show up on any price card. Starting with the Opus 4.7 generation, Anthropic shipped a new tokenizer. The rate card did not change, but the same text is now cut into more tokens than it was on earlier models. Since you are billed per token, an unchanged price per token can still produce a larger bill.

The practical takeaway is not that the newer model is a bad deal. It is that the real gap between Sonnet and the Opus tier on text-heavy work can be wider than the rate card alone suggests, and the only way to know your gap is to measure your own content.

Does a smarter model use fewer tokens?

This is the load-bearing question, and it is where sticker price and real cost part ways. The argument for the Opus tier being cheaper than it looks rests on a single idea: a more capable model can often reach the same result in fewer steps, with fewer wrong turns and fewer retries. When that happens, the higher price per token is spread across less total work, and the cost per completed task can land at or below the cheaper model.

We want to be honest about the strength of the evidence. The direction of this effect is well established and matches Anthropic guidance that more recent models tend to reason more and call tools less to reach the same answer. The precise percentages that circulate in third-party writeups, however, vary widely by workload and are hard to verify, so we are not going to quote specific benchmark deltas as if they were settled. Treat the direction as reliable and the magnitude as something you must measure for your own tasks.

The effort dial

^[4]The Opus and Sonnet tiers expose an effort setting that directly trades quality against token spend. Lower effort means less reasoning overhead and terser output; higher effort means deeper deliberation and more tool use. Calibrating this well is one of the most direct levers you have on cost, and it can offset much of the tokenizer overhead described above.

1. Low

   Least reasoning overhead. Good for short, scoped, latency-sensitive tasks that are not intelligence-sensitive: chat, simple lookups, classification.

2. Medium

   A cost-saving step down from the default that keeps most of the quality for many everyday tasks.

3. High

   The default. Full reasoning; the recommended minimum for most intelligence-sensitive work, balancing quality and token efficiency.

4. xHigh

   Introduced on the Opus 4.7 generation. The recommended setting for the hardest coding and agentic tasks. Give it a generous output budget so it has room to think and act.

A cost-per-task model you can play with

The chart and calculator below make the argument concrete. Both are an illustrative model, not a benchmark. They apply a token-efficiency factor that scales with task complexity and a retry-cost factor, using the verified list prices above. The point is to show the shape of the tradeoff, not to predict your exact bill. Plug in numbers that resemble your own workload, then confirm against real logs.

  { "type": "line", "title": "Illustrative cost per task by complexity (US$)",
    "data": { "labels": ["1","3","5","7","9","10"],
      "datasets": [
        { "label": "Opus", "data": [0.098,0.089,0.080,0.072,0.063,0.059] },
        { "label": "Sonnet", "data": [0.059,0.059,0.059,0.059,0.059,0.059] } ] } }
  

  { "inputs": [
      { "name": "inTok", "label": "Input tokens per task", "type": "number", "default": 6000 },
      { "name": "taskN", "label": "Tasks per month", "type": "number", "default": 5000 },
      { "name": "cmpx", "label": "Task complexity (1 simple to 10 complex agent)", "type": "range", "min": 1, "max": 10, "default": 5 },
      { "name": "retry", "label": "Sonnet failure / retry rate (percent)", "type": "range", "min": 0, "max": 10, "default": 3 } ],
    "outputs": [
      { "name": "sonnetCost", "label": "Sonnet est. monthly cost (US$)", "formula": "inTok * 9.3 / 1000000 * (1 + retry / 100 * 2) * taskN" },
      { "name": "opusCost", "label": "Opus est. monthly cost (US$)", "formula": "(inTok * 5 + inTok * 0.42 * (1 - (cmpx - 1) / 9 * 0.55) * 25) / 1000000 * (1 + retry * max(0.2, 1 - cmpx / 10 * 0.8) / 100 * 2) * taskN" } ],
    "checks": [
      { "expr": "cmpx <= 10", "message": "Complexity must be between 1 and 10" },
      { "expr": "retry >= 0", "message": "Retry rate cannot be negative" } ],
    "chart": { "type": "bar", "series": ["sonnetCost","opusCost"] } }
  

Routing by workload

Rather than pick one model for everything, route each kind of work to the tier that fits it. These are our defaults, framed at the tier level so they stay useful as specific model versions change.

Where each model tends to win

^[2]You will find plenty of benchmark tables online that put precise scores on Opus versus Sonnet across a dozen evaluations. We are choosing not to reprint specific figures, because the ones circulating are hard to verify and move with every release. What is durable is the shape of the tradeoff: which tier tends to win at which kind of work. For exact, current numbers, go to the model cards Anthropic publishes rather than any secondhand table, including this one.

A decision framework

Put it together as two lists. Default to Sonnet, and escalate to the Opus tier on measurable triggers rather than on a hunch.

Route to the Opus tier when:

• The task is a complex cross-file refactor, migration, or architecture decision.
• An autonomous agent makes many tool calls per task or runs for a long horizon.
• Sonnet shows a measurable failure or retry rate above a couple of percent on the task.
• The work needs deep, abstract, or specialist reasoning where quality is critical.
• It is a large asynchronous batch job that can run at the Batch API half-rate.

Route to Sonnet when:

• You are generating documents, reports, or structured long-form output.
• You are doing research synthesis, RAG, or large-scale question answering.
• It is everyday coding: features, debugging, tests, pull requests.
• The task is classification, routing, extraction, or content moderation.
• It is cost-sensitive work where the quality difference is not measurable. This is most of production.

Sources

Pricing, the effort setting, the Batch API half-rate, and the tokenizer guidance in this article are drawn from Anthropic primary documentation, captured as a July 2026 snapshot. Figures move; verify against the live pages before you budget. Benchmark comparisons are kept directional by design.

1. Anthropic — Pricing. anthropic.com/pricing
2. Anthropic — Models overview and model cards (documentation). platform.claude.com/docs/en/about-claude/models/overview
3. Anthropic — Introducing Claude Opus 4.5 (pricing and efficiency context, November 2025). anthropic.com/news/claude-opus-4-5
4. Anthropic — Effort and adaptive thinking (documentation). platform.claude.com/docs/en/build-with-claude/effort
5. Anthropic — Batch processing, billed at half the standard rate (documentation). platform.claude.com/docs/en/build-with-claude/batch-processing
6. Anthropic — Model migration guide, including tokenizer change notes for the Opus 4.7 generation. platform.claude.com/docs/en/about-claude/models/migration-guide

文章