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

Anthropic's Claude Opus 4.8 API is priced at $5 per million input tokens and $25 per million output tokens, the same headline rate Opus has carried since 4.5. What's changed is everything around that number: a new Fast Mode tier, a tokenizer that quietly inflates your token count, and a widening field of self-hostable MoE models like DeepSeek V4 that make the "just use the API" default worth re-checking. This post works through the actual pricing mechanics, the daily-volume crossover where renting a GPU cluster beats Claude's API cost, and the specific cases where Claude still wins regardless of the math.

Claude Opus 4.8 API Pricing: Input, Output, Cache, and Batch Rates

Claude Opus 4.8 launched May 28, 2026, available through the Claude API, Amazon Bedrock, Google Cloud Vertex AI, and Microsoft Foundry (llm-stats.com). Standard API pricing is $5/MTok input and $25/MTok output, identical to Opus 4.7, 4.6, and 4.5 (Anthropic pricing docs). That 1:5 input-to-output ratio matters: any workload with meaningfully more output than input gets expensive fast.

Standard vs Fast Mode Pricing

Fast Mode, in research preview for Opus 4.8 and 4.7, trades a price premium for materially faster output, and it applies across the full context window, including requests over 200k input tokens. For Opus 4.8, Fast Mode runs $10/MTok input and $50/MTok output, exactly double the standard rate. It stacks with prompt caching and data residency multipliers on top, and it isn't available with the Batch API at all (Anthropic pricing docs).

If you're on Opus 4.7 for Fast Mode, note that its Fast Mode pricing ($30/M input, $150/M output) is being deprecated on July 24, 2026, and Opus 4.6 no longer supports Fast Mode at all: speed: "fast" requests to claude-opus-4-6 now just run at standard speed and standard billing.

Prompt Caching: Why the Blended Rate Is Rarely $5/$25

Prompt caching is the single biggest lever for cutting real-world Claude costs, and it's also why almost nobody actually pays $5/$25 blended. The mechanics: a 5-minute cache write costs 1.25x the base input price, a 1-hour cache write costs 2x, and a cache read (hit) costs 0.1x base input, which for Opus 4.8 works out to $0.50/MTok versus the $5 standard rate (Anthropic pricing docs).

Run the math on a typical agentic session: a 50,000-token system prompt and tool schema, reused across 20 turns. Without caching, that's 50,000 x 20 x $5/M = $5.00 just on repeated input. With a 5-minute cache (one write at 1.25x, then 19 reads at 0.1x): 50,000 x $6.25/M (write) + 50,000 x 19 x $0.50/M (reads) = $0.31 + $0.475 = about $0.79. That's a 6.3x reduction on the input side alone, and it's why any serious cost comparison against self-hosting has to account for caching, not just headline rates.

Batch API: 50% Off for Async Workloads

The Batch API gives a flat 50% discount on both input and output for asynchronous jobs: $2.50/MTok input and $12.50/MTok output for Opus 4.8 (Anthropic pricing docs). It's not available with Fast Mode, and it's excluded from Anthropic's BAA coverage (more on that below), but for offline classification, bulk summarization, or nightly enrichment jobs where you don't need a synchronous response, it's a straightforward win. Combining Batch discounts with prompt caching on the same workload can cut the input-token portion of your bill by up to 95% versus standard uncached, non-batch pricing (a 0.1x cache-read rate on top of the 0.5x batch discount), though output tokens only get the flat 50% batch discount, so your overall blended savings will land lower than 95%.

The Tokenizer Catch: Opus 4.7+ Produces ~30% More Tokens for the Same Text

This is the detail that trips up anyone comparing per-token rates across model generations. Opus 4.7 and later Opus models, along with Fable 5, Mythos 5, and Sonnet 5, use a newer tokenizer that produces roughly 30% more tokens for the same input text than Sonnet 4.6 and earlier models (Anthropic pricing docs). The per-token rate looks unchanged from Opus 4.5, but if the same document now tokenizes to 30% more tokens, your effective cost-per-word went up by roughly the same amount. Budget off actual token counts from your workload, not a per-word estimate carried over from an older model.

One thing that hasn't changed for the worse: Opus 4.8, Opus 4.7, Opus 4.6, Sonnet 5, and Sonnet 4.6 all include the full 1M-token context window at standard per-token pricing. A 900k-token request costs the same rate per token as a 9k-token one. There's no long-context surcharge tier the way some competing APIs structure it.

And if you need US-only data residency, setting inference_geo: "us" on Opus 4.6 and later applies a flat 1.1x multiplier across every token category (input, output, cache writes, cache reads). Global routing, the default, uses standard pricing.

The Breakeven Math: Daily Token Volume Where Self-Hosting Wins

The short version: at an 80/20 input/output split, Claude Opus 4.8 blends to roughly $9.00/M tokens uncached. None of DeepSeek V4, GLM-5.2, or Qwen3-235B-A22B run on a single GPU: each is a large MoE model that needs its full parameter count resident in VRAM, so the real comparison is against a 4-to-8-GPU cluster, not a single card. On budget INT4 quantization with spot pricing, that clears breakeven around 31-36M tokens/day. On a production FP8 cluster at on-demand pricing, the crossover moves out to roughly 105-108M tokens/day. Below these volumes, or with aggressive prompt caching, the API usually wins on total cost of ownership once you factor in engineering time.

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

Most production workloads send more input than output. At an 80/20 split:

Blended Opus 4.8 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, the blend climbs to:

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

Both of these ignore caching. If a meaningful share of your input is a repeated system prompt or reused context and you're hitting cache reads at $0.50/M instead of $5/M, your real blended rate drops well below $9.00/M, sometimes by more than half. Run your own numbers before treating $9.00/M as gospel; it's a ceiling for uncached traffic, not a floor.

Self-Hostable Alternatives: DeepSeek V4, GLM-5.2, Qwen3-235B-A22B

Three MoE models are realistic Opus-class alternatives for high-volume production inference:

DeepSeek V4-Pro (1.6T total, 49B active, 1M context, open weights) is worth a look if you need the larger variant; see the DeepSeek V4-Pro deployment guide for the multi-node setup. For the standard V4, the DeepSeek V4 deployment guide covers expert-parallel vLLM configuration on the 4-to-8-GPU clusters it actually needs. GLM-5.2 has its own deployment walkthrough with FP8 sizing on H200/B200, and Z.ai claims it beats GPT-5.5 on coding at roughly a sixth of the cost, worth validating against your own eval set rather than taking at face value. Qwen3-235B-A22B doesn't have a dedicated deployment guide for that exact variant yet; the general Qwen 3 deployment guide covers the 8B-235B range and the same vLLM setup pattern applies.

All three are MoE architectures, which is a common source of confusion worth clearing up: only the active parameter count is used per forward pass, but the router can send any token to any expert, so the entire set of expert weights has to sit resident in VRAM regardless of how few are active on a given token. That's a real distinction from a dense model of the same active size, but it does not mean these models fit on a single GPU. DeepSeek V4's 1T total parameters need roughly 500GB of VRAM at FP8, meaning a minimum of 4x H200 SXM5 or 8x H100 SXM5 (DeepSeek V4 deployment guide). Qwen3-235B-A22B's 235B total parameters need at least 4x H100 at INT4 or 8x H100 at FP8, "do not plan hardware based on the 22B active figure," as the Qwen 3 guide puts it. GLM-5.2's 744B total parameters need 4x H200 at AWQ INT4 as a floor, or a full 8x H200 (or 8x B200) cluster in FP8 for its 1M-token context window (GLM-5.2 deployment guide). The active-parameter count changes compute cost and throughput per GPU, not the GPU count you need to hold the weights.

GPU Cost Per Token: Cluster Cost, Not Single-GPU Cost

Self-hosted cost per million tokens comes down to cluster price per hour divided by throughput, and the cluster is the whole unit of cost since none of these models runs on fewer than 4 GPUs. Live Spheron GPU pricing, fetched 6 Jul 2026:

Multiplying those per-GPU rates by the minimum cluster size each model actually needs gives the real daily infrastructure cost:

That cluster cost is fixed once provisioned, so throughput per dollar still matters for how much daily volume a given cluster can actually absorb before you need a second one. Active-parameter count affects that throughput (a 22B-active model processes more tokens per GPU-hour than a 40-49B-active model of similar total size), but it does not change the GPU count in the table above. See the GPU cost-per-token benchmarks for the underlying cross-model, cross-GPU throughput data, and GPU memory requirements for LLMs if you need to size VRAM for a specific quantization.

Daily Cost Crossover Table

Cluster cost is fixed regardless of volume processed, so the API gets relatively more expensive as daily token volume climbs, and the crossover point depends heavily on which quantization tier and pricing mode you pick. Using the $9.00/M blended Opus 4.8 rate (80/20, uncached):

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

Two crossovers matter here, not one. On a budget INT4 cluster running on spot pricing, Qwen3-235B-A22B and DeepSeek V4 break even around 31M tokens/day, and GLM-5.2's 4x H200 AWQ configuration breaks even around 36M tokens/day. On a production FP8 cluster running on-demand for reliability, Qwen3-235B-A22B and DeepSeek V4 break even around 108M tokens/day, and GLM-5.2's 8x H200 FP8 cluster (the configuration its 1M-token context window actually requires) breaks even around 106M tokens/day. That's a wide range, and where you land in it depends on whether you're willing to run spot instances (which can be preempted) and how aggressively you quantize.

For comparison, we calculated a 16-22M tokens/day crossover for GPT-6 against open-weight alternatives on a single GPU. Opus 4.8's crossover point is higher for two compounding reasons: its blended rate ($9.00/M) runs above GPT-6's ($4.40/M at the same split), and the specific self-hosted models in this comparison need a real multi-GPU cluster rather than one GPU. The self-hosting case for Claude Opus 4.8 only holds at genuinely high sustained volume, tens of millions of tokens a day at minimum.

Two caveats apply on top of all this. First, the table ignores prompt caching entirely; if a large share of your traffic hits cached context, your real blended Claude rate drops well below $9.00/M and the crossover point moves out further still. Second, tokenizers differ: Claude's newer tokenizer produces about 30% more tokens per unit of text than older Anthropic models, and open-weight tokenizers (SentencePiece/BPE variants) count differently still. Run a pilot with your actual prompts before committing to a number.

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

When Claude Still Wins: Latency, Compliance, and Model Quality Tradeoffs

Cost crossover math is only half the decision. Opus 4.8 leads on coding benchmarks by a real margin, Anthropic's compliance coverage has specific gaps worth knowing before you commit, and self-hosting doesn't automatically solve every privacy requirement it's assumed to solve.

Coding and Agentic Benchmarks: SWE-bench Pro Gap

Opus 4.8 scores 69.2% on SWE-bench Pro, up from 64.3% for Opus 4.7, a 4.9-point gain on one of the harder software-engineering benchmarks in use (llm-stats.com). Independent testing backs the direction: TrueFoundry ran both models through their own gateway and found Opus 4.8 returned patch-shaped output (a syntactically valid diff, not necessarily a correct fix) on 50 of 50 test cases versus 47 of 50 for Opus 4.7 (TrueFoundry). On SWE-bench Verified, Opus 4.8 hits 88.6%, up from 87.6% for 4.7, a smaller gain since that benchmark is closer to saturated.

None of the open-weight alternatives in this post have comparable third-party SWE-bench Pro numbers published as of this writing. For teams running long agentic coding sessions where a single wrong patch cascades into a broken build or a bad merge, that gap is often worth paying for regardless of what the per-token math says. The calculus is different for classification, summarization, or RAG-style workloads where the quality bar between Opus and a well-tuned MoE model is much narrower.

HIPAA, BAA Coverage, and What's Excluded

Direct answer: Anthropic's BAA for the Claude API covers the Messages API (including prompt caching, structured outputs, memory, web search, and the bash/text-editor tools), plus the Token Counting, Models, Org Management, and Compliance APIs. It explicitly excludes the Batch API, Files API, Skills API, Code Execution, Computer Use, and Web Fetch (privacy.claude.com).

That exclusion list matters in practice. If your architecture leans on the Batch API for cost savings on PHI-adjacent workloads, that traffic isn't BAA-covered, full stop; you'd need to route it through the standard Messages API instead. HIPAA coverage also isn't turned on by default: an organization administrator has to sign the BAA, then contact Anthropic sales to have the org set up as HIPAA-Ready with the required data retention settings (privacy.claude.com). If you're already assuming BAA coverage extends to every API surface, check this list before you architect around it.

Zero Data Retention vs Self-Hosted Data Control

By default, Claude auto-deletes API inputs and outputs within 30 days of receipt or generation. If a chat 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 (privacy.claude.com). For customers who need tighter guarantees, Zero Data Retention (ZDR) is available on approved Claude Platform and Claude Code for Enterprise accounts: Anthropic doesn't store inputs or outputs except as needed for legal compliance or misuse response. Even under ZDR, User Safety classifier results are still retained (privacy.claude.com).

Self-hosting sidesteps this conversation entirely for the data itself, since prompts and completions never leave your infrastructure. 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 are SSH root access with no shared GPU tenancy and no prompt/completion logging on the provider side, which is the baseline you want before treating self-hosting as a compliance shortcut. For a fuller EU-specific treatment of data residency and model governance obligations, see the EU AI Act compliance guide for GPU cloud.

Decision Framework

For a similar closed-API-vs-self-hosted breakdown at a different price point, see GPT-6 vs self-hosted LLMs and Gemini 3.1 Flash-Lite vs self-hosted open models. For the broader cost-lifecycle view beyond a single breakeven table, AI Inference Cost Economics 2026 covers the FinOps side in more depth, and Batch LLM Inference on GPU Cloud is the self-hosted equivalent to Claude's Batch API discount for async workloads. 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 Claude Opus 4.8 traffic is clearing tens of millions of tokens a day and caching isn't bringing the blended cost down enough, it's worth benchmarking DeepSeek V4 or GLM-5.2 against your own eval set on a rented H100 or H200 cluster.

On-demand H100 pricing → | H200 GPU rental → | Check current GPU pricing →