Claude Sonnet 4.6 Pricing Explained: Performance Approaching Opus at 60% of the Cost

Claude Sonnet 4.6's pricing strategy continues the Sonnet series' cost-effectiveness approach: $3 per million input tokens and $15 per million output tokens, exactly the same as the previous-generation Sonnet 4.5. But what's really worth noting is that it has already approached or even matched Opus-level performance across multiple benchmarks, while costing only 60% of Opus 4.5. For teams currently doing model selection, these numbers hide a billing logic that needs to be carefully unpacked.

Core Pricing: Standard, Caching, and Batch Processing

Standard API calls are billed at $3/MTok for input and $15/MTok for output. A typical request with 500 input tokens and 300 output tokens costs about $0.0060—indeed less than one cent.

But the real cost gap is driven by two levers: prompt caching and the Batch API.

Billing Tier	Input	Output
Standard	$3.00/MTok	$15.00/MTok
Batch API	$1.50/MTok	$7.50/MTok
Cache write (5 min)	$3.75/MTok	—
Cache write (1 hour)	$6.00/MTok	—
Cache read	$0.30/MTok	—
Long context >200K (standard)	$6.00/MTok	$22.50/MTok
Long context >200K (Batch)	$3.00/MTok	$11.25/MTok

Cache reads are priced at one-tenth of standard input, which means the cost of repeatedly calling static system prompts can be pushed extremely low. The original article gives an intuitive example: a 10,000-token system prompt processing 1,000 requests per day costs $30 per day without caching, but about $3.04 per day with caching—roughly a 90% reduction.

Prompt Caching: The Most Underestimated Cost Lever

The caching pricing structure deserves a separate breakdown. Writing to cache carries a premium—5-minute caching is 1.25x the base input price ($3.75/MTok), and 1-hour caching is 2x ($6.00/MTok). But reading costs only $0.30/MTok. The economic meaning of this design is clear: write costs are one-time, while read discounts are ongoing, so the higher the call frequency, the greater the value of caching.

Which cache duration to choose depends on the call pattern. High-frequency, bursty short sessions suit 5-minute caching; background processing pipelines, batch jobs with longer intervals, and agent loops are better suited to 1-hour caching. At the code level, after tagging static content with cache_control, you can read cache_creation_input_tokens and cache_read_input_tokens separately from the response's usage object to verify whether the cache was hit.

Here's an easily overlooked detail: both cache write and cache read tokens count toward the 200K long-context threshold judgment. That is, even if the main content goes through the cache, as long as total input tokens exceed 200K, the entire request is still billed at long-context rates.

Prompt Caching is a mechanism that lets the model reuse the same prefix content across multiple requests. It works like this: when a prefix in a request (such as a system prompt, few-shot examples, or a long document) is tagged with cache_control, the server persists the computed KV cache (the key-value states in the attention mechanism); if a subsequent request has an identical prefix, it can read the cache directly, skipping repeated prefill computation. This both saves the time of repeated computation (reducing latency) and greatly reduces costs billed on input tokens. Caches have a lifetime and must be rewritten after expiration, so the benefit is greatest for frequently reused static content.

Batch API is the asynchronous batch-processing interface provided by Anthropic, allowing large numbers of requests to be submitted in bulk and returning results within 24 hours (usually much faster) in exchange for a flat 50% discount. It suits latency-insensitive tasks such as offline classification, content moderation, and large-scale data enrichment. Because batch requests don't occupy real-time inference resources, the provider can schedule computation to idle periods and pass the savings on to users.

Batch API and Long Context: How the Two Discounts Stack

The Batch API offers a flat 50% discount at the cost of asynchronous processing—results are returned within 24 hours, usually far sooner. For latency-insensitive scenarios like content moderation, large-scale document classification, and overnight data enrichment, using the Batch API directly cuts costs in half. The original article's example: 1 million documents, each with 500 input tokens plus 100 output tokens, totals $1,500 in Batch mode, or about $0.0015 per document.

The long-context rules require one more layer of attention. After enabling the 1M context window via the context-1m-2025-08-07 beta header, requests with input exceeding 200K tokens are billed at $6/MTok for input and $22.50/MTok for output. The key point is that this 200K threshold looks at total input tokens, comprising the sum of standard input, cache writes, and cache reads. Once the line is crossed, all tokens in the entire request are billed at the higher rate.

The good news is that the Batch API's 50% discount stacks with long context: the combined long-context-plus-Batch price is $3/MTok for input and $11.25/MTok for output, exactly back to the standard tier. When batch-processing large documents, this is the key means of controlling costs.

Long Context refers to the size of the token window the model can process in a single request. Claude Sonnet 4.6 supports a 200K-token context by default, expandable to 1M tokens via the context-1m-2025-08-07 beta header. But the portion beyond 200K requires additional memory and compute resources, so billing uses tiered pricing: when total input tokens exceed 200K, the entire request (not just the excess portion) is billed at the higher long-context rate. Here, "total input tokens" includes the sum of standard input, cache writes, and cache reads—an easily overlooked billing detail.

Stacking Batch API with long context is the key combination for cost optimization. The Batch API's 50% discount applies to all requests, including long-context requests, so the combined long-context-plus-batch price can drop to $3/MTok for input and $11.25/MTok for output, exactly back to the standard tier. This means that when batch-processing large documents (such as contract analysis or long report summarization), you can enjoy both the asynchronous discount and long-context support without paying a premium.

Tool Calls Come with Extra Bills

Beyond token fees, some tools carry their own independent billing. Web search is charged at $10 per thousand calls, with each search invocation counted as one call regardless of how many results are returned, and search errors are not billed. The web fetch tool itself is free, with tokens billed only for content that enters the conversation. The code execution tool is free when bundled with web search or fetch; when used standalone, each organization gets 1,550 free hours per month, with overage at $0.05 per container-hour and a minimum billing unit of 5 minutes.

Computer use functionality brings fixed token overhead: the system prompt adds 466–499 tokens, and each tool definition adds 735 tokens. These numbers look small individually—735 tokens at $3/MTok is only $0.0022—but screenshot tokens are the big item, with each screenshot consuming roughly 2,000–5,000 tokens depending on resolution, accumulating quickly in multi-turn sessions.

Side-by-Side Comparison: Is Sonnet 4.6 Worth It?

Placing Sonnet 4.6 within the entire Claude product line makes its positioning clear. Its input and output prices are 60% of Opus 4.6's, yet its SWE-bench Verified score is 79.6%, less than 1.5 percentage points from Opus 4.6's roughly 80.8%; on the OSWorld computer-use test, the two score 72.5% and 72.7% respectively, virtually tied. In user preference comparisons, early testers preferred Sonnet 4.6 over Opus 4.5 in 59% of head-to-head matchups.

Model	Input	Output	Cache Read
Claude Sonnet 4.6	$3.00	$15.00	$0.30
Claude Haiku 4.5	$1.00	$5.00	$0.10
Claude Opus 4.6	$5.00	$25.00	$0.50
Claude Opus 4.1	$15.00	$75.00	$1.50

Opus 4.6's premium only makes sense in two cases: when you need the maximum 128K output tokens (Sonnet 4.6 is 64K), or when facing novel tasks that demand extreme reasoning capability. For the vast majority of coding, analysis, document processing, and agent workflows, Sonnet 4.6 can deliver near-Opus results at 60% of the price.

Its relationship with Haiku 4.5 is one of division of labor rather than replacement. Haiku 4.5 suits high-frequency, low-complexity tasks like routing, classification, and simple extraction; Sonnet 4.6 handles complex code generation, multi-step agents, and long reasoning chains. The original article notes that this hybrid routing pattern is typically 60–80% cheaper than using Sonnet 4.6 for everything.

SWE-bench Verified is the authoritative benchmark for evaluating large models' software engineering capabilities, containing 500 GitHub issues from real open-source projects and requiring the model to generate code patches that pass tests. It is stricter than the original SWE-bench, with human verification ensuring clear problem descriptions and reliable tests. A score of 79.6% means the model can independently solve nearly 80% of real code-fixing tasks—a key metric for measuring the practicality of coding agents.

OSWorld is the benchmark for evaluating computer-use capabilities, simulating real operating system environments (such as browsers and office software in a virtual machine) and requiring agents to complete multi-step tasks via screenshots and mouse-and-keyboard operations. A score of 72.5% reflects the model's operational accuracy in real GUI environments, virtually on par with Opus 4.6's 72.7%, indicating that Sonnet 4.6 already has near-flagship reliability in agent workflows.

Do the Math Before You Go Live

Understanding the pricing table doesn't mean your budget is accurate. Actual costs depend on the input-to-output token ratio, cache hit rate, and whether you use batch processing—things that can only be verified by running real requests. The original article recommends that before writing production code, you first make trial calls with the API debugging tools and read the four values input_tokens, cache_creation_input_tokens, cache_read_input_tokens, and output_tokens from the response body's usage object, multiplying each by its corresponding rate.

A practical example: a request with 523 input tokens, 5,000 cache write tokens, and 312 output tokens costs about $0.025 on the first call; after subsequent cache hits, it drops to about $0.006. Multiply these numbers by your estimated call volume to get a usable budget baseline, rather than a rough guess.

One-line Summary

Claude Sonnet 4.6 keeps $3/$15 pricing with performance approaching Opus, while caching and batch processing can cut costs by another 50-90%.

Paragraph Summary

Claude Sonnet 4.6 continues the Sonnet series' cost-effectiveness approach, with standard pricing of $3 per million input tokens and $15 per million output tokens—unchanged from the previous generation—while performance approaches Opus 4.6 at only 60% of its cost. The article breaks down the full billing system: prompt cache reads are as low as $0.30/MTok, cutting costs by about 90% in static-prompt scenarios; the Batch API offers a 50% discount that stacks with long-context rates, bringing the combined price back to the standard tier; the 200K long-context threshold is calculated on total input tokens (including cache reads and writes), and once crossed, the entire bill is charged at $6/$22.50. In addition, tool calls such as web search and code execution have independent billing that must be accounted for separately. The article recommends verifying token ratios and cache hit rates with real requests before going live to establish a reliable budget baseline.