Claude Opus 5 API Pricing vs Self-Hosted LLMs (2026)

Anthropic set Claude Opus 5 API pricing at $5 per million input tokens and $25 per million output tokens when the model launched July 24, 2026, the exact same headline rate Opus 4.8 has carried since May (Anthropic). If you were expecting a price hike, there isn't one. What actually changed is more consequential for your bill: thinking now runs by default on every request, and the two effort tiers Anthropic recommends for serious coding and agentic work, xhigh and max, won't let you turn it off. Our Opus 4.8 pricing breakdown covered the version where thinking was opt-in. This one covers what happens to your real per-request cost now that it isn't, and where that resets the self-hosting math.

Claude Opus 5 API Pricing: What Changed From Opus 4.8 in Price, Context, and Effort Settings

Direct answer: the token rate is identical, but three behavioral defaults moved: thinking is on unless you explicitly turn it off (and only up to high effort), the effort ladder gained real teeth at xhigh/max, and the minimum cacheable prompt dropped to 512 tokens. Context window, max output, Fast Mode, and Batch pricing are all unchanged from 4.8.

Same $5/$25 Headline Rate, But Thinking Is Now On by Default

Anthropic's own migration note is blunt about this: "On Claude Opus 4.8, requests run without thinking unless you set thinking: {"type": "adaptive"}. On Claude Opus 5, the same requests run with thinking on" (Anthropic). The wire value hasn't changed, thinking: {"type": "adaptive"} still works and is now just redundant with the default, but a codebase that never touched the thinking parameter gets a materially different model behavior after the swap.

That matters for cost because max_tokens is a hard ceiling on thinking tokens plus response text combined, and thinking tokens bill as output at $25/M. A request that used to spend its entire output budget on the answer now spends part of it on reasoning first. Anthropic's own guidance: "revisit [max_tokens] for workloads that ran without thinking on Claude Opus 4.8." If you migrate the model string and nothing else, you risk truncated responses (stop_reason: "max_tokens") on requests that used to finish cleanly.

The New Effort Ladder: low, medium, high, xhigh, max (and Why xhigh/max Can't Disable Thinking)

Opus 5 ships the full ladder: low, medium, high, xhigh, and max, with high as the default on the API and in Claude Code (Anthropic). That's not new on its own, Opus 4.7 introduced xhigh. What's new is the hard coupling between effort and thinking: on Opus 5, thinking: {"type": "disabled"} is only accepted at high effort or below. Set it alongside xhigh or max and the API returns a 400.

This is a real breaking change, not a formality. On Opus 4.8, disabling thinking was independent of effort level; you could run max effort with thinking off if you wanted. On Opus 5, the two highest tiers force reasoning tokens into every response. Anthropic's guidance for teams that must keep thinking off for latency or format reasons is to stay at high or below and accept the quality tradeoff, or keep thinking on and use lower effort to manage token spend instead of trying to disable it outright.

The upside Anthropic is selling here is real: "Efficiency at lower effort levels, with low and medium effort producing strong quality at a fraction of the tokens and latency of higher settings" is one of the launch's stated capability gains. In practice this means the effort dial, not the thinking toggle, is now your primary cost lever. Sweep low/medium/high on your own eval set before assuming you need xhigh.

1M Context Window, 128k Max Output, Fast Mode and Batch Rates Unchanged

Everything else on the spec sheet held steady. Opus 5 has a 1M-token context window that is both the default and the ceiling (there's no smaller context variant), 128k max output tokens, and a reliable knowledge cutoff of May 2026, four months later than Opus 4.8's January 2026 cutoff (Anthropic).

Fast Mode, still a research preview and still Claude API only (not Bedrock, Google Cloud, or Microsoft Foundry), runs $10/M input and $50/M output, exactly double the standard rate, same as it was for Opus 4.8 (Anthropic). Batch API pricing is a flat 50% off both directions: $2.50/M input, $12.50/M output. Prompt caching keeps the same multipliers, 1.25x base input for a 5-minute write, 2x for a 1-hour write, and 0.1x for a cache-hit read, which works out to $6.25/M, $10/M, and $0.50/M respectively on Opus 5's $5 base rate. The one caching change: the minimum cacheable prompt dropped from 1,024 tokens on Opus 4.8 to 512 tokens on Opus 5, so shorter system prompts that couldn't cache before now can, with no code changes required.

Tool-use overhead moved a few tokens in the right direction too: a request with tool_choice: "auto" carries 286 tokens of system-prompt overhead on Opus 5 versus 290 on Opus 4.8, and forced tool choice runs 406 versus 410 (Anthropic). Small, but it's a saving, not a cost, at scale.

If you need US-only inference, inference_geo: "us" still applies a flat 1.1x multiplier across every token category on Opus 5, same as 4.6 and later. Global routing, the default, uses standard pricing.

Claude API Pricing at Scale: Opus 5 vs a Rented H200 Running an Open-Weight Model

The blended math against self-hosting starts identically to Opus 4.8's, because the per-token rate didn't move. Where it diverges is in what a "typical" Opus 5 request costs once thinking is running by default, which is the variable that actually decides whether your real-world blended rate lands near the $9/M sticker math or well above it.

Blended Cost Per Million Tokens (80/20 and 60/40 Splits)

Most production traffic sends more input than output. At an 80/20 split:

Blended Opus 5 rate = (0.8 x $5) + (0.2 x $25) = $4.00 + $5.00 = $9.00/M tokens

At a more output-heavy 60/40 split:

Blended Opus 5 rate = (0.6 x $5) + (0.4 x $25) = $3.00 + $10.00 = $13.00/M tokens

Both of these are uncached, and both assume the output-token count you'd have measured on Opus 4.8 with thinking off. If your workload now runs thinking on by default (the new baseline) and you haven't tuned effort down, your real output-token share of that split is higher than it used to be for the identical task, which pushes your effective blend closer to the 60/40 number even if your prompts didn't change.

Anthropic's own worked example, for a one-hour Managed Agents coding session with 50,000 input and 15,000 output tokens, comes out to $0.705 uncached (including the $0.08/hour session runtime charge specific to Managed Agents), dropping to $0.525 when 40,000 of those input tokens are cache reads (Anthropic). On the plain Messages API without that runtime line item, the same 50k/15k split is $0.625 uncached and $0.445 with the same caching. Either way, caching cuts the bill by roughly a third on a session this size, before you touch effort level at all.

Why Effort Level Changes Your Real Cost More Than the Sticker Price Does

This is the part that resets the breakeven math without a single digit changing on the pricing page. Two teams running the same prompts against Opus 5 can land on meaningfully different bills depending on one setting: output_config.effort.

At low or medium, Anthropic states Opus 5 produces "strong quality at a fraction of the tokens and latency" of the higher tiers, which for a cost model means fewer thinking tokens and fewer output tokens per task. At xhigh or max, the two tiers Anthropic recommends for the hardest coding and agentic work, thinking cannot be disabled at all, and Anthropic explicitly advises setting a large max_tokens "so the model has room to think and act across subagents and tool calls." That's a direct instruction to budget for materially more output tokens at the top of the ladder than at the bottom, on the same nominal task.

Anthropic doesn't publish an exact multiplier for tokens-per-task across effort levels, and neither will we; it depends on your workload. What you can do is what the docs recommend: measure. Run count_tokens and a real request at low, medium, and high before assuming you need xhigh, and treat the effort setting as the primary cost lever now that the thinking toggle is mostly gone from that role. A workload that used to run cheaply on Opus 4.8 with thinking off can get noticeably more expensive on Opus 5 if you migrate the model string and leave effort at the API default of high without checking.

Self-Hostable Alternatives That Now Clear the Opus-Class Bar

Two open-weight MoE models are realistic Opus-class substitutes for high-volume production inference, and a third is worth watching if your workload leans on extended reasoning specifically.

GLM-5.2 is a 744B-parameter MoE model (about 40B active per forward pass) with a 1M-token context window, released under MIT license. Z.ai's own claim is that it beats GPT-5.5 on coding at roughly a sixth of the API cost, worth validating against your own eval set rather than taking at face value. DeepSeek V4-Flash is the lighter option: 284B total parameters with 13B active, also a 1M-token context, purpose-built for cheap agentic inference where the model makes many small calls rather than a few large ones. Both need their full parameter count resident in VRAM regardless of active-parameter count, since the router can send any token to any expert.

For reasoning-heavy workloads specifically, where Opus 5's xhigh/max tiers would otherwise be your only lever, Arcee Trinity-Large-Thinking is worth a look. It's a 400B-parameter Apache 2.0 model explicitly positioned to rival Claude Opus's extended-reasoning quality at self-hosted cost, and unlike a closed API, there's no effort-tier lock-in: you control the reasoning depth and the hardware directly.

GPU Cluster Cost Per Day: Spot vs On-Demand H200

Neither GLM-5.2 nor DeepSeek V4-Flash fits on a single GPU, so the real comparison is against a multi-GPU cluster, not a single card. Live H200 GPU pricing on Spheron, fetched 11 Aug 2026:

4x H200 (564 GB VRAM) is the floor for DeepSeek V4-Flash's recommended FP8 configuration with full 1M-token context, and for GLM-5.2 at AWQ INT4 with a shorter context budget. 8x H200 (1,128 GB) is what GLM-5.2 needs for FP8 serving at its full 1M-token context window. Both cluster costs are fixed once provisioned; what varies is how much daily volume they can absorb before you need a second one, which depends on your model's throughput per GPU-hour, not the numbers above.

Pricing fluctuates based on GPU availability. The prices above are based on 11 Aug 2026 and may have changed. Check current GPU pricing → for live rates.

Daily Token Volume Crossover Table

Using the $9.00/M blended Opus 5 rate (80/20, uncached, no thinking-tax adjustment):

†Cluster cost is flat only up to that cluster's throughput ceiling; sustained volume well above the crossover may need a second cluster. Benchmark your actual throughput before committing capacity at this scale.

At an 80/20 split, the 4x H200 spot cluster breaks even around 35M tokens/day, and the 8x H200 on-demand production cluster around 102M tokens/day, both close to what we calculated for Opus 4.8, because the sticker rate is identical. The gap that actually moved is upstream of this table: if your effective output-token share climbed because thinking now runs by default, your real blended rate sits above $9.00/M even before you hit any of these volumes, and the crossover arrives sooner than the table suggests. Run the same table with your own measured blend, not the 80/20 assumption, before deciding.

When Self-Hosting Still Wins: Data Residency, Fine-Tuning, and Fixed-Cost Workloads

Cost crossover is only half the decision. Opus 5's launch claims are aimed squarely at agentic and long-horizon capability, Anthropic's compliance coverage has specific, well-documented gaps, and self-hosting solves the "data never leaves our infrastructure" requirement more directly than any API contract can.

SWE-bench Pro Gap: Is the Coding Lead Worth Paying For

Anthropic frames Opus 5 as "a step-change improvement over Claude Opus 4.8, with the largest gains in deep reasoning, agentic and long-horizon tasks, and test-time compute scaling" (Anthropic), and describes it as "a thoughtful and proactive model that comes close to the frontier intelligence of Claude Fable 5 at half the price" (Anthropic). The launch's own benchmark claims back that up on a handful of named evals: on Frontier-Bench v0.1, Opus 5 "more than doubles Opus 4.8's performance at a lower cost per task." On OSWorld 2.0, it outperforms every competitor at comparable cost, "surpassing Fable 5's best result at just over a third of the cost." On CursorBench 3.2, at maximum effort, it lands "within 0.5% of Fable 5's peak score, but at half the cost per task."

Anthropic's launch materials don't cite a SWE-bench Pro or SWE-bench Verified number for Opus 5 specifically, so we won't invent one here; if you're tracking that benchmark for a coding-heavy deployment decision, check a third-party leaderboard directly rather than assuming the Frontier-Bench gains translate 1:1. What is documented is the capability shift itself: Anthropic lists "code review and bug-finding, surfacing real bugs at a high rate per pass with few false positives, and staying accurate at lower effort levels" as one of the model's stated improvements over 4.8. For teams running long agentic coding sessions where a single wrong patch cascades into a broken build, that's the kind of gap that's often worth paying for regardless of what the per-token math says. It matters far less for classification, summarization, or RAG-style workloads where the quality bar between Opus and a well-tuned MoE model is already narrow.

BAA Coverage, Zero Data Retention, and What's Still Excluded

Direct answer: Anthropic's BAA for the Claude API covers the Messages API (prompt caching, structured outputs, memory, web search, bash/text-editor tools) plus Token Counting, Models, Org Management, and Compliance APIs. It excludes the Batch API, Files API, Skills API, Code Execution, Computer Use, and Web Fetch, and coverage is account-wide rather than tied to any one model, so everything here applies to Opus 5 exactly as it applied to 4.8 (Anthropic).

That exclusion list bites in practice if your architecture leans on Batch for cost savings on PHI-adjacent workloads: that traffic isn't BAA-covered, full stop, and would need to route through the standard Messages API instead. HIPAA coverage also isn't on by default. An org administrator has to sign the BAA and then contact Anthropic sales to get the account configured as HIPAA-ready with the required retention settings.

On retention, Claude auto-deletes API inputs and outputs within 30 days of receipt or generation by default. If a request is flagged for a Usage Policy violation, Anthropic retains inputs and outputs for up to 2 years and trust-and-safety classification scores for up to 7 years (Anthropic). Zero Data Retention is available on approved accounts, where Anthropic doesn't store inputs or outputs beyond what's needed for legal compliance or misuse response.

Self-hosting sidesteps the retention conversation for the data itself, prompts and completions never leave your infrastructure, but it doesn't sidestep everything. You still own patching, access control, and audit logging on whatever GPU instances you run, and "self-hosted" only means something for compliance if the underlying infrastructure is actually isolated. On Spheron, instances run with SSH root access, no shared GPU tenancy, and no prompt or completion logging on the provider side, which is the baseline worth checking before treating self-hosting as an automatic compliance win.

Decision Framework: API vs Self-Hosted

For the same framework applied to other closed APIs, see GPT-6 vs self-hosted LLMs and the wider LLM API pricing comparison across GPT, Claude, Gemini, and DeepSeek for how Opus 5's $5/$25 rate sits against the rest of the market. The GPU cost-per-token benchmarks have the underlying cross-model, cross-GPU throughput data behind the cluster math above. If you're standing up the self-hosted side of this comparison for the first time, Spheron's docs cover instance provisioning and SSH setup.

If your Opus 5 traffic is clearing tens of millions of tokens a day and tuning effort down isn't bringing the bill in line, it's worth benchmarking GLM-5.2 or DeepSeek V4-Flash against your own eval set on a rented H200 cluster.

Spheron H200 → | Spheron H100 → | Check current GPU pricing →