Claude Opus API Pricing: How Anthropic Bills Its Most Capable Model

The first thing most teams notice about Claude Opus API pricing is the gap between the headline rate and the actual invoice. Anthropic publishes clear per-million-token rates, but the final bill depends on a stack of mechanics that sit below the price table: output multiples, prompt caching, batch discounts, extended thinking, and the way tool use multiplies both input and output. This guide works through those mechanics in the order they affect your budget.

Every rate in this article is sourced from Anthropic's published documentation and pricing page as of the date shown above. We do not round, because rounding is how estimates drift. If you want to run the numbers on your own traffic while you read, keep the Claude Cost Calculator and the pricing database open in a second tab.

How Anthropic bills a Claude API request

Anthropic meters every request in tokens, not in characters, words, or API calls. A token is roughly three quarters of an English word, so a 1,000 word document is about 1,300 tokens. The Messages API splits every request into two meters that run at different rates:

• Input tokens include everything you send: the system prompt, conversation history, retrieved context, tool schemas, and the current user message.
• Output tokens include everything the model generates, including text shown to the user and any reasoning tokens produced during extended thinking.

That split matters because the output rate is significantly higher than the input rate. On Claude Opus, output is typically priced at five times input. A workload that generates long responses will spend most of its budget on output, even when the input is modest. A workload that only classifies or extracts short labels will spend mostly on input. The shape of your traffic matters more than the provider you choose.

Current Claude Opus API pricing per million tokens

The table below shows Anthropic's list pricing for text generation on the current generation of Claude models. Prices are in USD per one million tokens. Vision and other modalities are priced per token equivalent and are usually close to the text rate for the same model class.

Two patterns are worth reading carefully. First, the output multiple is five on Opus, five on Sonnet, and five on Haiku. Anthropic keeps the same ratio across the family, so the cost curve of a long-answer workload scales with the absolute output rate. Second, the step from Haiku to Sonnet is roughly four times on input and output; the step from Sonnet to Opus is five times. That gap is why most production workloads should not default to Opus.

These are list rates. The sections below explain how prompt caching, batch processing, and extended thinking modify them. The headline price is almost never the final price, and that is a good thing for teams that learn the modifiers.

Prompt caching: the largest single discount on Claude

Prompt caching lets Anthropic reuse computation for a prefix it has already processed. The mechanic is straightforward: if you send the same long system prompt, tool definitions, or reference documents on many requests, Anthropic stores the resulting prefix and bills later reuse at a steep discount. The effect is large enough that some workloads cost ten times less with caching than without it.

Anthropic splits prompt caching into two meters:

• Cache write happens when you send a prefix that Anthropic has not seen recently. The write is billed at a twenty-five percent premium on top of the standard input rate.
• Cache read happens when Anthropic matches a prefix it already has. Cache reads are billed at roughly ten percent of the standard input rate, a ninety percent discount.

The trade-off is that the first request with a new prefix costs more, while every repeat request costs far less. A support assistant with a 4,000 token system prompt and 50,000 repeat requests a month will spend more on the first call, but the saving on the other 49,999 calls is typically the largest single line-item reduction in the budget. The catch is that the prefix must stay identical. A single changed character near the top invalidates the cache and resets the prefix to full price.

To make caching work, put stable content at the top of the prompt and volatile content at the bottom. System instructions, policy text, tool schemas, few-shot examples, and reference documents should come first. User messages, timestamps, session IDs, and retrieved chunks should come last. The Claude Cost Calculator lets you toggle cache hit rate and see the impact on the monthly total.

Batch processing: half price for latency-tolerant work

Batch processing is the simplest discount Anthropic offers. If your workload does not need an immediate response, you can submit requests as a batch and receive results within a guaranteed window, typically twenty-four hours. In exchange, Anthropic bills input and output at fifty percent of the standard rate.

The use cases are obvious once you look for them: overnight report generation, back-office document processing, data enrichment, evaluation runs, and training-set generation. Any task that can wait a few hours is a candidate for batch pricing. The discount is so large that it often changes the model choice. A batched Opus request can cost less than a real-time Sonnet request for the same tokens.

The practical caveat is that batch jobs are not a good fit for user-facing paths. If a customer is waiting, pay the full rate. If a cron job or a data pipeline is waiting, batch the work and cut the cost in half.

Extended thinking and tool use: why Opus scales non-linearly

Claude Opus supports extended thinking, which lets the model produce an internal reasoning chain before answering. Those reasoning tokens are billed as output, even though the user never sees them. A short visible answer can carry several thousand billed output tokens behind it. For tasks that require deep reasoning, this is a feature worth paying for. For routine tasks, it is an expensive default.

Tool use amplifies the same dynamic. When you give Claude a tool set, the model decides how many tool calls to make. Each call resends the conversation, so input grows with each step while output grows with each reasoning and response step. A five-step agent does not cost five times a single call. In practice it often costs ten to twenty times, depending on how much of the prefix stays cached and how many reasoning tokens each step uses.

• Cap the number of steps. Set a hard limit on tool calls and reasoning budget per task.
• Keep tool schemas short. Unused tool definitions are billed as input on every request.
• Cache stable schemas and few-shot examples. This is the same rule as before, but it matters more when the same prefix is resent many times.
• Route by difficulty. Use Haiku or Sonnet for the steps that do not need frontier reasoning.

Three worked Claude Opus cost examples

Abstract rates are hard to reason about. Here are three workloads modelled end to end on Claude Opus 4.5 list pricing. Each assumes a 30-day month, no volume discount, and no batch processing.

Legal document review, 3,000 documents a month

Assume an average document of 15,000 tokens and a 500 token structured summary. Input is 45 million tokens at $15.00 per million: $675. Output is 1.5 million tokens at $75.00 per million: $112.50. Monthly total: roughly $787.50. If the same workload is batched, the bill drops to roughly $393.75. If the summaries are routed to Sonnet instead, the monthly cost falls to roughly $157.50 before batching.

Premium support assistant, 25,000 conversations a month

Assume a 3,000 token system prompt, 1,000 tokens of conversation history, 200 tokens of user input, and a 400 token response. Input is 105 million tokens at $15.00 per million: $1,575. Output is 10 million tokens at $75.00 per million: $750. Monthly total on Opus: roughly $2,325. If the system prompt is cached and the cache hit rate is ninety percent, the input cost drops to about $600, taking the total to roughly $1,350. The same workload on Sonnet, with the same cache hit rate, costs roughly $270.

Research agent, 1,000 tasks a month

Assume six steps per task, a 5,000 token tool schema, 2,000 tokens of accumulated context per step, and 600 output tokens per step including reasoning. Input per task is roughly 72,000 tokens, or 72 million a month, at $15.00 per million: $1,080. Output is 3.6 million tokens at $75.00 per million: $270. Monthly total: roughly $1,350. Cache the tool schema and the input drops to about $440, taking the total to roughly $710. This is why agent cost discipline is mostly cache discipline.

How Claude Opus compares with Sonnet and Haiku

Opus is not the right default for every task. Anthropic positions the three tiers as a capability ladder. Haiku is for speed and low cost on simple tasks. Sonnet is the workhorse for most coding, reasoning, and agent work. Opus is for the hardest problems where accuracy and depth matter more than cost.

The cost ladder is steep. A Haiku response costs roughly one fiftieth of an Opus response for the same token count. A Sonnet response costs roughly one fifth. The practical rule is to route traffic by task difficulty. Classification, extraction, routing, and simple Q&A should usually go to Haiku or Sonnet. Frontier coding, complex analysis, and high-stakes reasoning should go to Opus. Most teams that default everything to Opus are paying five to twenty times more than they need to.

The model comparison tool runs this arithmetic side by side. It is the fastest way to see what you gain or lose by moving a workload from Opus to Sonnet or Haiku.

A practical checklist for reducing Claude Opus spend

In order of typical return, from largest to smallest:

1. 01Route by task difficulty. Move simple work to Haiku or Sonnet before you optimize anything else.
2. 02Structure prompts for cache hits. Put stable content first, volatile content last, and never edit earlier messages mid-conversation.
3. 03Use batch processing for anything that can wait. A fifty percent discount is hard to beat with prompt engineering.
4. 04Cap output length deliberately. Output is the expensive meter, and most applications ask for more words than they need.
5. 05Trim tool schemas and few-shot examples. Every unused definition is billed input on every step.
6. 06Measure cost per successful outcome, not cost per call. A cheaper model that fails and triggers retries is not cheaper.

What to monitor after launch

Cost control is an operational discipline, not a procurement decision. Four metrics catch nearly every regression we see in production systems:

• Cost per request as a distribution. The mean hides the expensive tail, and the tail is what breaks budgets.
• Cache hit rate. A silent drop after a deployment usually means someone added a timestamp or a session ID near the top of the prompt.
• Share of traffic routed to Opus. This should be the smallest share of your total requests, not the largest.
• Extended thinking and reasoning token share. A parameter change that increases thinking length raises cost without changing a single visible word.

Log token counts from the usage object on every response and store them alongside your application metrics. Anthropic's dashboard tells you what you spent. Your own logs tell you which feature, which customer, and which prompt version spent it, and only the second view lets you act.

What the numbers mean for your budget

Claude Opus is priced at a premium because it is built for the hardest reasoning tasks. The mistake is not using Opus for those tasks. The mistake is using Opus for every task. Anthropic gives you three tiers, a caching layer, a batch path, and a clear output multiple so you can match cost to capability. Teams that use those controls run Opus where it matters and keep the rest of the workload on cheaper tiers.

Rates change, and model names move. Verify the current Anthropic pricing page before you commit a budget, and re-check the model strings you depend on when aliases or versions shift. Every figure on this page is dated, sourced, and updated when the underlying documentation changes. For the latest live rates across every provider, use the pricing database.