Frontier Inference Margins — interactive cost model

An interactive cost model for one token of a frontier LLM, and the serving margin it implies — of each dollar of modeled token billings, how much is left after the modeled direct cost of serving them; every number is a modeled reading from public sources and labeled assumptions, not any provider's ledger.

Methods, assumptions and limitations — what this calculator does and deliberately does not model; read before quoting numbers

The metric. Serving margin = 1 − serving cost ÷ effective price, for the selected traffic mix. Its full technical name, said here once, is unit direct-serving contribution margin. Effective price is the list price after the selected cache-read price, batch share and negotiated discount — a modeled figure, not observed provider revenue. With batch share and discount at 0% it is simply list price; the provider cards' replays are computed that way and the public-data scenario is not. Serving cost counts accelerator time — rented or owned, at the selected cost basis — the serving software's throughput, and paid idle capacity, which is charged to the tokens served by dividing by utilization. It does not separately model support, research and development, sales, revenue shares, free traffic, or unbilled retries and storage. It is neither a company's cost of revenue (COGS) nor a company gross margin.
How the page's numbers relate, for Claude Opus. The calculator opens on the GPT-5.6 Pro estimate's own settings unless you choose another default: its author states 83.1% at list price, and the calculator reads about 82% at the same settings today — its card explains the gap. This page's public-data scenario — planning rents, 50% utilization, the Reference mix, no assumed efficiency lead — reads about 58% at effective price: a model result under public-data assumptions, not a guaranteed minimum for actual margins, and not an estimate of them. The same settings with the page's adopted 3-month algorithmic lead read about 68%. A second estimate, Fable 5's, reads ≈77% at effective price. The 90–95% figure repeated in the discourse needs assumptions beyond this page's public-data scenario. Every number here is a modeled reading from public sources and labeled assumptions; nothing is any provider's actual ledger.
Data dates and how each accelerator's speed was set. The newest material on this page is dated October 1, 2026 (the GPT-6.1 Sol estimate), and five token prices were corrected to what their vendors charge on September 20, 2026 (changelog); a price or input that shows no effective date of its own is as of July 15, 2026. Each accelerator's speed was set its own way and says so on its row (its calibration class): TPU v7 is an analyst-set bridge from the same platform; Trainium 2/3 carry a joint coefficient fitted across other hardware families, with no matched serving measurement of their own; Rubin is a projection from its announced shape only. Where the model does not fit an accelerator's memory at the assumed batch, the row shows a smaller batch or no number. Every slider documents its sources.
Which kind of price you assume moves the answer by tens of points. It is not the widest lever on this page: on the xAI card below, sweeping utilization across the range this page offers moves the same reading further still — 99 points against the valuation choice's 72. It is simply the lever most often left unstated when a margin figure is quoted. On the same Grok 4.5 fleet and the same workload, the calculator reads ~91% if the accelerator-hour is valued at short-run cash cost, ~63% at full-cycle owned cost, and ~19% at what a customer pays for that hour. Those are three answers to three different questions, not a disagreement — which is why a figure from one cost basis cannot be set beside a figure from another.
Each accelerator's speed was set its own way, and no one number transfers between them. Fitted rows reproduce their declared calibration points; H100/H200 use an explicit H800-family transfer; TPU v7 is an analyst-set same-platform bridge; Trainium uses an out-of-family joint coefficient without a matched serving anchor; GB300 is analyst-set at an assumed operating point; Rubin is projection-only. The live roofline then resolves compute, high-bandwidth memory (HBM) and interconnect terms at the selected operating point. A single cross-platform scalar previously failed (mean error 47% across three measured platforms), and the physically informed follow-up also failed its whole-platform gate (methods note).
Three kinds of price, and where electricity is counted. Every price on this page is typed to one of exactly three cost bases — on-demand rent (published rate cards; the China public-cloud preset), planning rent (the registered low- and committed-term rates this page plans on, and its default), and owned cost, also called total cost of ownership (TCO), built from purchase price, power, the datacenter and operations. The page never silently substitutes one basis for another inside one number, and the suite fails the build if it does; a fleet declared with some legs rented and some owned is allowed, and says so on the leg. The three valuation replays on the xAI card (cash cost, owned cost, opportunity cost) are a separate axis layered on a rent basis, not a fourth basis. Electricity dollars are explicit only under owned cost; under rent bases they are embedded in the rent — decomposing rent without TCO assumptions would be fabrication, so rent lenses show only the implied physical energy (info-only). Serving energy (Wh per M tokens) is computed for every leg and every lens as operating power × power usage effectiveness (PUE) ÷ achieved throughput at the engine's own operating point. Three declared conventions: (1) operating power is the thermal design power (TDP) proxy — no per-accelerator operating-power measurement is public (a typed boardPowerW override hook exists, currently null everywhere); (2) no utilization divisor — the dollar path allocates paid idle to served tokens, while the Wh figure deliberately does not: it is the physical intensity at the operating point, so it diverges from the electricity-$ path, which does divide by utilization. Idle boards do draw power; this page does not model that draw, so the Wh figure is an operating-point intensity and not a fleet-average one; (3) cache reads are charged the same analyst-set 5%-of-prefill fraction the cost side uses, as a proxy. Scope is accelerator × PUE only: the one full-stack telemetry anchor in this corpus (accelerators ≈58% of per-prompt energy, a 1.72× stack overhead) implies a full-stack figure ≈1.4× above this page's number at the default PUE 1.25.
Cache writes: billable write premiums (OpenAI 1.25×; Anthropic 1.25×/2× by TTL) are modeled revenue-side via the cache-write sliders, default off; the serving-cost side is unchanged because prefill produces the keys and values (KV) regardless. Cache storage, transfer, retention, replication and reads-per-write are unmodeled and may be material.
Context length is now modeled, not free-form: the traffic-mix profile's fixed input/output lengths feed the decode and prefill roofline directly (KV footprint, fabric traffic, HBM/compute binding terms, feasibility capping) — it is not a slider you set independently, but it is no longer ignored. Still not modeled: time-to-first-token and time-per-output-token (TTFT/TPOT) latency targets, KV-cache lifecycle and storage billing, speculative-decoding acceptance, unbilled retries/safety reruns (a served-vs-billed overhead you can approximate with the stack-efficiency slider), and free traffic.
Traffic-mix axis (v2.1.2): the Traffic mix selector owns the I/O ratio and cache-hit share only — profiles carry provenance-honest names (a disclosure, a named deployment, a stated convention; no generic "chat/coding" archetypes). SLA/interactivity, service class and cache lifecycle remain modeled elsewhere; the full workload ontology is future work. The serving-side reuse share and the billable cached-input share are DIFFERENT observables; by default the calculator assumes them equal (a labeled assumption you can now break with the "Billable cached-input share" slider). The assumption is material: on the Opus flagship scenario at the public-evidence reference (algorithmic lead 0 months), billable cached share 0% / =serving / 95% spans 75.3% / 58.4% / 31.0% margin — a billing sensitivity starting from the public-data scenario's settings, so these are hypothetical calculator readings, not observed margins; the lead-adjusted baseline carries the adopted 3-month algorithmic lead, so its levels sit higher while the spread stays the same shape. Replay presets lock their traffic (it is part of the published operating point); the hero's scenario-preset span holds the selected traffic fixed and therefore excludes traffic-mix uncertainty.
Most of the modeled cost is on the input side, and it rides on one borrowed number. (1) a cache-read serving cost of 5% of fresh prefill — analyst-set, unobserved, and distinct from the published 10% cache-read price. It is load-bearing: at the reference 15:1 mix and 60% cache hits the executed cost identity is C = C_out + 15 × (0.40 + 0.60 × 0.05) × C_in = C_out + 6.45 × C_in, putting 72.42% of modeled direct cost on the input side at the public-data scenario's settings — not measured production telemetry or the share in every estimate's fleet — all of it riding on a single universal H800 prefill transfer (an executed ±50% input-cost sensitivity starting from the public-data scenario's settings moves the calculated margin by ±15.1 points — hypothetical sensitivity outputs, not observed margins; the lead-adjusted baseline gives a smaller move). The whole chain is reconstructed in one place, component by component with each source and label, together with the cache-work boundary the fresh-prefill anchor assumes and why that boundary is worth 6.4%: where the input-side cost comes from. (2) a peak KV/recurrent-state charge of ≈0.562 GB per live sequence at the reference terminal context length (16,000 tokens) — computed from the architecture registry and the traffic profile, not hand-set, and distinct from the 15,500-token representative decode position. Both were recovered by adversarial review of the cost arithmetic; stating and enforcing them is the fix.
Which cells are scenario-only: the Trainium2/Trainium3 throughput coefficients (no matched serving anchor exists for either part), the Trainium3 rent (no public rate), the GB300 batch and η (an assumed operating point — the row is analyst-set, not fitted), the H100/H200 topology carry, the fleet weights, the 2.5 T/300 B geometry, the prefill costs, the 50% utilization floor, the 15:1 / 60% / 15% / 5% commercial mix, the loaded-byte overhead, ancillary cost, and MTP acceptance. Each is a declared choice this page can defend as a scenario and cannot defend as a measurement; each names what disclosure would upgrade it.
Rental class: the same chip spans up to 10× between internet-data-centre (IDC) annual leases and hyperscaler on-demand (H20: ¥5–72/card-hr). China rows default to annual-commit rates; the cost multiplier is the dial.
Algorithmic lead — a labeled scenario prior, not a measurement. the "Algorithmic lead" slider asks how many months a lab's private serving stack is ahead of published open practice, in residual, non-hardware, accelerator-portable efficiency this page does not otherwise model. It converts through E = rate^(months/12) at a ratified 3×/yr (applying that cross-model progress rate to RESIDUAL SERVING efficiency at fixed model geometry is an additional, unvalidated modeling assumption, separate from any uncertainty about the number of months; halving ≈7.57 months — Gundlach et al., arXiv:2511.23455, MIT FutureTech, with Epoch AI data), and modeled cost-out divides by E in every serving phase. The per-lab defaults are an adopted scenario prior: Anthropic / OpenAI / Google +3 months, DeepSeek +1, the other frontier Chinese labs 0, and any lab with no adopted prior 0 and labeled unassessed. Validity conditions: only residual gains belong here — hardware, quantization, batching and caching are modeled by their own controls, and representing them here as well counts them twice. Axes never conflate: capability lag (~4 months, Epoch-measured) is a different axis and is never this slider; on the efficiency axis the open Chinese labs define the published-practice zero, which is why their prior is 0 rather than negative. Refused rates: the published token-price series (9×–900×/yr — Epoch's price index, a16z's 10×, the AI Index's 280×) measure published prices, not serving efficiency; this slider never uses them. Under a published-operating-point replay the slider is inert and locked at 0 — the lab's actual efficiency is already inside the replay, so months on top would double-count.
Family multipliers — a broad stress lever, sourced by nothing. one ±% efficiency multiplier per hardware family (NVIDIA / TPU / Trainium / Ascend) multiplies achieved throughput for every card in that family, in every serving phase, in any fleet. It answers "suppose this family's real serving efficiency is N% off our calibration" and is a declared stress, never a measurement. It does not change declared batch, precision tuples, capacity or feasibility. A custom-fleet leg rides its donor's family; a renamed leg tagged unclassified is exempt and says so on the leg.
The interlock, and why the stack multiplier was redefined. the family multipliers and the algorithmic-lead prior are both broad, unspecified efficiency assumptions, so composing them silently would count the same improvement twice. Editing either group locks the other with the reason stated inline; because the ratified lead defaults start nonzero, the first family edit replaces the prior — the lead is set to 0 and locked, loudly, so every headline move stays attributable. Unlocking is always available, always deliberate, and leaves a persistent stacking banner. Explicitly-modeled levers — serving precision, serving regime, the cache controls — are never locked by this machinery; where they overlap the prior you get a non-blocking warning instead. In the same spirit, serving-stack efficiency is now defined as measured stack composition relative to published open practice: its 1.0 tick names the same referent as the lead slider's zero, and the old "frontier lab (assumed)" label is retired, because a frontier assumption is precisely what the lead slider now represents defensibly (1.25× ≈ +2.4 months at 3×/yr). Setting both above their baselines fires an overlap warning; the §10 dive replays keep their anchored stack values unchanged.
Speculative-decode credit. A scenario lever, off by default, that multiplies modelled decode throughput only — prefill has no autoregression to speculate on. It models no acceptance rate, draft cost or verification overhead: it is a credit you declare, not a mechanism this page runs. It is available only from the "no MTP/disagg" stack setting (0.7). 0.7 is the only point on this scale whose MTP-free meaning is portable to any scenario. Other settings carry no portable claim either way — a published replay may document its own stack in detail, but that documents that operating point, not the scale. Crediting speculative decoding from any other setting could therefore count part of the same improvement twice, and this page refuses rather than guess. The stack setting is not what proves a leg speculation-free, and an MTP-free setting would not prove it — speculative decoding does not require MTP. That work is done per leg: every leg carries a typed baseline status, and only legs whose own baseline is documented to exclude speculative uplift are creditable at all. The setting gates the scale; the per-leg status gates the leg. What that costs you: the 0.7 setting also removes disaggregation, so this page cannot express "disaggregation without speculative decoding" — those fleets are under-credited here rather than risk double-counting, which is the direction this page prefers to be wrong in. Energy follows the throughput multiplier by construction of this model — speculative decoding also burns draft-and-verify energy this page does not measure. Legs whose deployed efficiency absorbs speculation, and legs whose status this page cannot establish, are exempt and say so.
Implementation & regression consistency — not empirical validation: every §10 card's headline regenerates from the "§10 dive replay" perspective, and a deterministic release suite (several hundred assertions, published at /tests/ together with the roofline diagnostic) gates every deploy. These tests prove the code is stable and reproduces its own authored targets — they do not validate the economic inputs: out-of-sample flagship validations, calibrated coverage tests, and per-provider production-telemetry matches are all zero, and the single cross-platform transfer test that was run failed (§3).

· expand for this scenario's reasoning, its source, evidence label, and what would falsify it

Serving margin

—

Not a company gross margin. Serving margin only — see the methods box.

If ALL sections were owned (TCO basis)

—

Serving margin — not a company gross margin.

Two independent estimates of Claude Opus 4.x serving margin — and the stress test under them

Estimate by

GPT-5.6 Pro

83.1%

68 – 92%

Billed at undiscounted list price · its author's stated range

Scenario, not observed economics · assumes ~300B active · unvalidated flagship throughput transfer · cache-read serving cost 5% of fresh prefill (assumed).

Billing: undiscounted list price · Assumed algorithmic lead: 2 months · Cost basis: low/committed planning rent.

Included fleet (normalized token weights): H100 5%, H200 10%, GB200 25%, GB300 20%, TPU v7 40%.

Explain this estimate

The face carries the round-3 self-authored revision — 83.1% at the undiscounted list price, span 68–92%, with a lead-only diagnostic of 78.89–85.37% across 0–4 months. Its author states it at list only, which is why this face's basis differs from the card beside it; the effective price is this page's illustrative mix (15% Batch share, 5% discount) on the $5/$25 list price, cache reads at 10%.

Sources: its declared settings are itemized in the adopted grounding ledger; its July consult is published as a verbatim original with an adopted-findings summary.

Reach this operating point in the calculator: Load this estimate's assumptions ↑ (round-3 self-authored, on Opus — the page's opening scenario)

Estimand: Claude Opus 4.x serving margin — accelerator capacity, paid idle capacity charged through the utilization divisor, direct host/network/control-plane burden and production serving overhead, at the Reference traffic mix (15:1 input:output, 60% cache), mid-2026. Not a company gross margin (§7).

Its settings. Algorithmic lead a range of 0 / 2 / 4 months, midpoint 2 (its reasons are in the scenario's note); 65% utilization (band 50–80, its own judgment); list-only billing; per-leg procurement with every family multiplier at 1.0 — NVIDIA ×0.95, TPU ×0.50, Trainium ×0.85 at zero weight; no speculative-decoding credit. On this engine today those settings compute 82.33% at list (78.78–85.29% across the 0–4 month lead), against the 83.1% its author states; the page does not tune the settings to close that gap — its author declined target tuning in its own words (the scenario's note quotes it).

Against the Fable 5 estimate: utilization 65 against 60, a more strategic fleet synthesis, and a lead dial carrying a residual prior where Fable's carries its serving-stack credit. At lead 0 the two read 78.78% and 77.16% at list. The page does not choose between them.

Estimate by

Fable 5

≈77%

65 – 82%

Billed at the effective price · its author's stated range

Quoted at the effective price: Scenario, not observed economics · assumes ~300B active · unvalidated flagship throughput transfer · cache-read serving cost 5% of fresh prefill (assumed).

Billing: modeled effective price (Batch share 15% · negotiated discount 5%) · Assumed algorithmic lead: 1 month (serving-stack credit carried on the lead dial) · Cost basis: low/committed planning rent.

Included fleet (normalized token weights): H100 10.67%, H200 14.67%, GB200 25.33%, GB300 16%, TPU v7 33.33%.

Explain this estimate

The face carries the round-3 self-authored reading — ≈77% at the effective price, span 65–82%, ≈80% at list. Same two denominators as the card beside it.

Sources: its declared settings are itemized in the adopted grounding ledger.

Reach this operating point in the calculator: Load this estimate's assumptions ↑ (round-3 self-authored, on Opus)

Estimand: the same provider, traffic mix and direct-cost perimeter as the card beside it — Opus 4.x serving margin, mid-2026 — quoted at the effective price where the other quotes list. Compared at list, the engine reads 82.33% for the other card's settings and 79.16% for these.

Its settings. The serving-stack credit is carried in the calculator, on the lead dial: 0 / 1 / 2 months, midpoint 1 — the credit (0.92 months at the ratified 3×/yr, rounded to one) — and at the top the OpenAI-anchored bound (−20% end-to-end serving cost = 2.44 months, rounded to two) instead of the credit, never on top of it. 60% utilization (band 50–70); per-leg procurement — TPU ×0.30, Trainium ×0.70, NVIDIA undiscounted; 2.5T total / ~300B active; stack multiplier 1.0 and speculative decoding off, so the mechanism is counted once. On this engine today those settings compute 76.28% at the effective price and 79.16% at list, against the ≈77% its author states.

Against the GPT-5.6 Pro estimate: utilization 60 against 65 — and it holds 65 exactly as unmeasured as its own 60 — plus the rate treatment above and the credit in place of a lead prior. It was derived from this page's own numbers without sight of the other estimate.

Different billing assumptions; not a like-for-like comparison. One estimate is quoted at list price, the other at the effective price; the Fable 5 card's explanation also gives its reading at list, for comparison. Stated ranges across regimes and structural uncertainty — not statistical confidence intervals. Both estimators say so in their own words.

Matched RENTED vs OWNED RENTED ≈58% · OWNED ≈88% · OWNED − RENTED +29.9 points Opus public-data scenario — fixed reference, independent of the calculator selection. Both readings are policy-labeled serving margins, not a company gross margin: a model result under public-data assumptions, not a guaranteed minimum or an estimate.

Same revenue and workload. Modeled effective price $3.268/M tokens, after 15% batch share and 5% discount, with 60% cache reuse and billed cache reads at 10% of input list price. Reference traffic: 15:1, 15,000 input / 1,000 output tokens per request. Both bases use the same model, registry sections, accelerator weights and serving assumptions, with no algorithmic lead. Serving costs per M tokens: RENTED $1.359 and OWNED $0.382; each margin is 1 − its cost ÷ the same effective price.

Cost perimeter and horizon. RENTED uses registered low/committed planning rents; OWNED uses modeled electricity, PUE, accelerator capex, facility capex and opex. Both charge paid idle capacity by dividing serving cost by 50% utilization once. Support, R&D, sales, revenue shares, free traffic, unbilled retries and storage are not separately modeled; bundled rents may include some of these. This is a mid-2026 modeled snapshot, with accelerator life 5 years, facility life 15 years and capital recovery off, not an investment-return forecast. The signed difference is conditional on those costs, not an observed lessor margin, and does not identify an analyst's unstated accounting basis.

Reach this operating point in the calculator: Load the public-data scenario ↑ (on Opus)

Explain this scenario

The public-data scenario sets every judgment dial at its unmoved value: the registered heterogeneous low/committed planning-rate vector at 1.0×, 50% utilization, open-source-level serving stack, balanced latency, no algorithmic-lead prior. It reads about 58% on this page's 15% Batch / 5% discount mix and about 63% at the undiscounted list price.

It is a public-data scenario, not an estimate. It rests on public data and this page's explicitly stated assumptions — planning rents, 50% utilization, an open-source-level serving stack, no efficiency lead of the lab's own — and every judgment dial sits at its unmoved value. So this reading is a public-data scenario: a model result under those assumptions, not a guaranteed minimum for real inference margins, and nothing like a best estimate of them. The calculator can still produce lower readings under other assumptions or model forms; those are hypothetical sensitivities of the model, not observed margins. Every assumption in it is stated, so a reader can rebuild it; three of its planning rents (GB200, GB300, Trainium3) are provisional declared judgments rather than published rate-card prices. The full reasoning behind it, including where it is fragile, is the section body below.

Public-data scenario

—

The full reading — scope, bases, bands and spans

Why not the higher numbers?

What would have to be true to reach the higher readings

Read the rationale and evidence chain →

What would have to be true for a ~90% margin? Or ~45%?

These are “what would it take?” questions — not this page's estimate. Each range below is a hypothesis to stress-test: pick one to see the assumptions it would require. The page's own modeled result is shown only in the calculator below, and never takes its value from this explorer.

Pick a margin range you've heard claimed and see the assumptions it would take to land there. Each range with a claimed position behind it carries a page-authored route — what would have to be true of procurement, occupancy and serving efficiency — that you can load into the calculator as an explicit counterfactual. The calculator's headline (computed from the scenario and the Model / Traffic-mix selections the calculator currently holds — on page open, the GPT-5.6 Pro estimate's own settings unless you have chosen another default) never takes its value from this explorer.

Saved scenarios

Scenarios saved in this browser. Selecting one loads it as a modified state — the saved numbers, never the currently-selected lens. Save new ones from “Save scenario” at the end of the adjustment sections below.

Evidence catalog — sourced claims per range, badged by relation (verbatim where archived; reported figures labeled as such), plus every page-authored route

This grouping of claims into ranges is this page's organization, not the claimants'. A claim renders under a range only with its typed relation badged — asserts, locates-within, conditional transition, unnamed subject, different metric, disclosure anchor — and a floor claim never renders as interval membership: it is compatible with its range and every higher one. Company-GM and reported figures are different objects from this calculator's unit metric (§7). Routes are ordered by fewest changed registry fields from the central configuration (stable-id tie-break) — an edit count, not a measure of which route is right.

Blended cost

—

per 1M tokens served (traffic mix)

Effective price

—

per 1M tokens billed (after cache mix)

Cost per 1M output

—

input: —

Serving feasibility

—

Save scenario

Scenario name

Saved to this browser only; it reloads as a modified state (never inheriting a lens). Load, rename or delete under “Saved scenarios” in the range explorer above.

Shared links and saved scenarios are stamped with a defaults epoch (currently v22) and the headline margin at share time. Links or presets minted before v2.2 (2026-08-06) no longer resolve — they show a deprecation notice rather than a silently wrong number.

Margin if served entirely on each accelerator

Modeled ownership-cost breakdown, with the rental cost when shown click any bar to open that accelerator's cost control · owned/strategic-TCO decomposition per 1M blended tokens, by accelerator — a counterfactual build-up under rent lenses (see chip) show rent (lessor's cut, implied)

Margin sensitivity — active parameters holding everything else at current settings

Cost per 1M output tokens across hardware generations current model settings; margin at current price labeled on each bar. Rubin is shown as an unpriced placeholder (no public rack rate, benchmark or purchase price) — it is not plotted on the $ scale.

Subscription economics is the $200 plan underwater? Depends whether you price usage at list or at marginal cost.

Full report: how fat are frontier inference margins?

Methodology v3.0; dated revisions are in the changelog. Checked by separately run model-based adversarial reviews (archived) — independent executions, not independent human validation · Maintained by Ashita Orbis · Analysis by Claude (Fable 5) with independent GPT-5.6 Pro research runs · X evidence via Grok 4.5 sweep · web evidence via Exa + Parallel deep research. Load-bearing claims are labeled by source class — first-party disclosure, regulatory filing, reputable reporting, reproducible benchmark, market quote, community estimate, or modeling assumption — and linked where a public source exists; a handful of reported figures carry no archived public link and are labeled as such (see §7).

Scope note: this is first and foremost an investigation of Anthropic's serving margins — that is where the strongest 90–95%-range claims cluster (as conditional and floor claims, not an unconditional "Anthropic = 90–95%" statement — see the §1 source audit), where the public evidence concentrates, and where the two independent research runs went deep. The other providers in the calculator are included for comparison at materially lower evidence density; their presets are best-effort estimates (marked * where speculative). Each non-Anthropic provider has since received its own independent GPT-5.6 Pro deep dive — §10 audits what is actually known about each one, with judgmental margin ranges and the reasons for their width, and links the full public research reports.

The claim and the claimants
The evidence base, source by source
The cost model and its calibration
Chip efficiency: H100 → GB300 → Rubin
The two independent estimates
GPT-5.6 Pro's analysis and verdict
Reported gross margins are lower, and the perimeter is the first thing to check
The subscription-token investigations
The most comprehensive public analyses
The other providers: knowns, unknowns, confidence

1 · The claim and the claimants

Expand this sectionCollapse this section

The framing under examination: that Anthropic's marginal cost of serving a Claude token sits so far below its API list price that what the discourse calls "serving gross margins" reach the 90–95% range — the loudest figure the discourse repeats. In this page's terms that is a claim about the serving margin — one token, on a warm accelerator, at scale, in the claimants' framing — not about Anthropic's income statement (see §7 for why those diverge). Note this page's own metric is stricter than the warm-GPU framing: it allocates paid idle capacity through the utilization divisor (methods box). Read what follows as an audit of that range: as this section documents, the cited corpus carries the 90–95% zone as conditional and floor claims, not as an unconditional "Anthropic = 90–95%" statement.

The loudest and most quantitative proponent is @teortaxesTex:

His cited record, summarized (verbatim posts in the annex sweep): an Anthropic-specific serving-cost claim — DeepSeek-style math prices serving Opus at at most $4/Mtok (token class unspecified), implying very high unit margins even on subscriptions except at full utilization (Jun 28, 2026) — and a CONDITIONAL claim, made in a western-provider context:

"No, they'll just increase the batch size, have the same speed, and drive margins from 90% to 95%. You're welcome" — Jun 27, 2026

Earlier and more conservative from the same account: "if we exclude R&D and look at inference alone, Anthropic and OpenAI are making like 80% margins" (Mar 2025). The cited corpus does not contain an unconditional claim that Anthropic's margin is exactly 90–95%.

@zephyr_z9 (Zephyr) makes a related pricing allegation from the semis side: a Jul 8, 2026 post says xAI is not "juicing up the gross margins to 90%-95%" — but it names no comparison lab and does not define the metric as a serving margin (both are this page's readings). Separately, a Jun 24 post explicitly places Anthropic at ~70% company-level gross margin with a 15–20% free-cash-flow (FCF) margin. The two figures coexist in one account's posts. Corrected 2026-08-23: a Jun 24, 2026 post does name the labs — "adopt Anthropic/OAI tactics and serve tokens at 5x the current price (95% GM)" — so the allegation is lab-specific in his own words; what the posts never state is the basis (rented or owned accelerator-hours), so this page shows that claim under both bases (which margin each analyst means).

One reported-margin objection: @fleetingbits — "we know approximately what frontier lab inference margins are; it's like 40-50%; it's been reported a bunch of times. anthropic labels cloud provider commissions as a sales and marketing expense; so the gross margins are mostly inference compute costs." And in the middle, a Jul 1, 2026 PodcastAlphaX clip-account post featuring Dylan Patel of SemiAnalysis quotes him putting Anthropic's margin on an Opus API token "north of 80%" — corroborated 2026-08-23 by the Sequoia podcast transcript (Jun 30, 2026), where he specifies the object ("for the API price", on an Opus token) in a rented-capacity framing ("every GPU I rent…"); the exact worksheet is unpublished, so the basis is a source estimate, not a stated one (analyst-divergence page).

2 · The evidence base, source by source

Expand this sectionCollapse this section

2a · DeepSeek's serving disclosure — the one primary source in the field

On March 1, 2025 (Open Source Week "Day 6"), DeepSeek published actual production serving statistics for V3/R1 on H800 clusters: 73.7k input / 14.8k output tokens per second per 8-GPU H800 node, 56.3% input cache-hit rate, ~$87,072/day GPU cost (at $2/H800-hr) against $562,027/day theoretical revenue at R1 list prices — the famous "545% cost-profit ratio," which is a markup; as a margin it is 84.5% (a distinction TeorTaxes himself insisted on). Caveats DeepSeek listed: much traffic was free web/app users and off-peak V3 pricing, so realized revenue was materially lower than the theoretical figure.

Why it matters for Anthropic: DeepSeek's disclosure implies an 84.5% theoretical margin had all observed traffic been billed at R1 list prices — DeepSeek itself stated actual realized revenue was materially lower — on export-restricted hardware, in early 2025, at prices far below Anthropic's on a like-for-like token-class basis: 3.6× cheaper for cache reads, 9.1× for fresh input, 11.4× for output. The hardware and serving-software inputs to that calculation have since improved (§4), though prices, fleet constraints and latency targets can move the other way. The a-fortiori argument — if DeepSeek could get to ~85% theoretical at $2.19/Mtok output on H800s, what does $25/Mtok output on GB300s and TPUv7 imply? — is the strongest single piece of evidence in the bull case. It is an anchor for what optimized serving can cost, not proof of what Anthropic's margin is.

2026-07-15 update — a 2026 sequel to the same argument. The Information reported (Jul 14–15, 2026, via @jukan05/@jingyanghk relays) that DeepSeek's annualized revenue is nearing ~$500M, with a ~¥50B (~$7.4B) raise at a ~¥500B (~$74B) valuation and STAR Market IPO prep — and, in a follow-up, that V4 API gross margin is 70–80% (up from an earlier ">50%" figure). This is a reported, realized figure at V4's much lower list prices, and it corroborates the direction of the argument above even though it is a different object: "gross margin" here carries no disclosed accounting definition or company confirmation, so it is not directly comparable to the disclosed 545%/84.5% unit-serving arithmetic — the metric distinction matters as much now as it did then. This page's own model already puts V4 Pro below 90% at list on any fleet (§10), so a reported 70–80% company-side figure sits inside, not above, what the unit math would suggest.

2b · The Musk size leak — total vs active, a distinction that matters

The leak is widely retold as "Musk revealed Opus is much smaller than expected" — but on total parameters it says the opposite. What Musk actually posted (Apr 9, 2026): "0.5T total. Current Grok is half the size of Sonnet and 1/10th the size of Opus. Very strong model for its size." The community deduction (e.g.): Sonnet ≈ 1T, Opus ≈ 5T total parameters — Opus is big.

The "smaller than expected" intuition belongs to active parameters: TeorTaxes, observing Fable served at ~90 tok/s, concluded it had "shockingly FEW active parameters for what it was", and Zephyr puts OpenAI's frontier at "~100B active range" with Opus/Fable "the highest active parameters" among peers. For serving cost, active parameters are the dominant modeled driver (compute scales with active-parameter FLOPs/token, Φ ≈ 2 × active plus a context-length-dependent attention term); the activated roofline separately resolves compute, HBM/KV-traffic and fabric/communication-bound terms as functions of context length, batch and sharding topology rather than collapsing them into one scalar. Total size mostly sets the memory footprint and the feasible sharding topology. The current default is a 2.5T-total/~300B-active MoE; the 5T Musk-relative reading is preserved as a separate legacy scenario — and the active number is the single most uncertain, most consequential slider on this page. Even the total is contested: the "incompressible knowledge probes" estimation method (arXiv:2604.24827) carries a ~threefold prediction interval (per the paper's v2 revision of Jul 5, 2026: median fold-error 1.48×, with 86% of models within 3×), and a methodological re-analysis lands nearer 1.1T total for Opus 4.7. GPT Pro's sanity check cuts the other way: a dense 5T Opus would cost more than its own $25/Mtok list price to serve — so if Musk's number is right, heavy sparsity isn't optional, it's implied.

2c · GLM 5.2 on GB300 — the ncode/Noumena deployment by @_xjdr

The researcher is @_xjdr; the product is ncode on the Noumena platform (code.noumena.com), served on GB300 NVL72 racks from Prime Intellect. His free-week postmortem (Jun 30, 2026) is the best public look at frontier-style serving on Blackwell Ultra:

"final GLM 5.2 served stats: ~12000 unique api keys served ~300B tokens total 232 tok/s/gpu output average 431 tok/s/gpu output max sustained 2.1 sec TTFT overage [sic] (1M ctx) 61 sec p95 TTFT (1M ctx) 81k tok average input size 41% cache hit rate 0 chat logs kept (dont be evil)"

Configuration: 60× B300 ("15 trays"), bf16 attention with fp8 experts/KV ("virtually 0 measurable quality difference"), no MTP, no Eagle — a custom Rust stack. A third-party estimate on his thread put the implied cost at ~$0.35/Mtok in, ~$1.50/Mtok out at $6/GPU-hr. Note his 232 tok/s/GPU average is output-only bookkeeping, and the same post reports 81k-token average inputs at a 1M context limit — but it does not report average output length, request rate, phase-level GPU allocation, or an input:output split, so it does not establish how GPU time divided between prefill and decode; it is not comparable to SGLang's 12k tok/s/GPU throughput records (different model, batch regime, and MTP). The original labels the 2.1-second TTFT statistic "overage"; that field remains uninterpreted. (Erratum: an earlier revision of this page silently normalized "overage" to "average"; the token is now preserved verbatim as "overage [sic]" and left uninterpreted — see the changelog.) The separately reported 61-second p95 TTFT at 1M context documents a long tail, but the corpus does not identify its cause.

Adjacent results worth separating from the ncode story (GPT Pro's browsing initially merged them, §6): GLM-5.2's architecture is public via Baseten's serving writeup — 744B total / 40B active, NVFP4-clean, 280+ tok/s/user on Blackwell (a per-user speed record, not aggregate throughput). And the headline GB300 aggregate number belongs to SGLang + NVIDIA serving DeepSeek-V4: 2,200 → 11,200 tok/s/GPU from April to June 2026 on the same racks — five-fold, from software alone.

2d · What the plans actually hand out

Covered in §8 — the short version: heavy Claude Max users have documented API-equivalent usage far above the subscription price. That is consistent with low marginal serving cost, but it does not identify the subscriber distribution or exclude breakage, throttling, routing or cross-subsidy; §8 treats it as tail evidence only.

3 · The cost model and its calibration

Expand this sectionCollapse this section

The calculator prices a token with one identity. The cost of a million output tokens is the price of an accelerator-hour, divided by how many tokens that accelerator produces in an hour, divided again by utilization so that paid idle time lands on the tokens actually served:

output $ per million tokens = ($ per accelerator-hour ÷ 3,600 ÷ tokens per second per accelerator) × 10⁶ ÷ utilization

The tokens-per-second figure is where the modeling is. For decode it is the roofline: the slowest of the accelerator's compute, its memory bandwidth (high-bandwidth memory, HBM) and its interconnect sets the ceiling, and an efficiency factor (η) set per accelerator says how much of that ceiling is reached. The selected serving regime fixes each leg's batch; if the model and its working memory do not fit the accelerator at that batch, the batch is capped or the leg is marked infeasible. The traffic mix fixes the output length and therefore the context length; the precision setting fixes, per leg, the FLOPS rate and the byte widths the roofline is computed from. Two settings are fixed on every rendered path — one token position per step (q = 1) and one accepted token per step (a = 1); the roofline note defines them. Prefill has its own compute-and-interconnect roofline, with one reviewed prefill calibration applied to every accelerator. A cache read costs a selected fraction of a fresh prefill. The traffic mix blends those costs, and the same mix prices revenue at list minus the cache, batch and negotiated discounts.

These are calibration points, not a validated predictive model. Each leg's η carries a calibration class that says how it was set, and only a coefficient that reproduces a matched observation is labeled fitted. Five legs are borrowed, each in its own way: the H100 and H200 are explicit transfers within the H800 family; TPU v7 is an analyst-set bridge from the same platform in aggregate form; Trainium2 and Trainium3 carry an out-of-family joint coefficient, with no matched serving measurement of their own. The GB300 is analyst-set at an assumed operating point. Rubin is a projection only. The H20 and Ascend observations informed the frozen joint calibration, but their live per-leg coefficients are separate source-informed neutral choices that do not reproduce those observations, so they are not fitted either.

Two cautions apply to all of it. Reproducing a calibration point is an identity, not a validation. And every decode-calibration observation is a model of at most about 50B active parameters, while the flagship scenarios assume 105–300B active. The wider evidence catalog includes larger dense-model benchmarks (Llama 3.3 70B, Llama 3.1 405B), but none is a matched validation of those flagship scenarios. The obvious test was run and published: the previous single-scalar transfer test failed (mean error 47% across the three measured platforms, worst 59%), and the physically informed follow-up still failed the whole-platform gate (worst −40%). See the cross-platform transfer test note. The live engine therefore exposes each row's operating-point basis and feasibility state rather than implying one scalar transfers everywhere:

Anchor (published)	Published	Live engine at listed point	Deployed default
DeepSeek disclosure, H800 decode (37B active, FP8, production average)	1,850 tok/s/GPU	1,873 at b=96, L=4,989	fitted per-row decode calibration
DeepSeek disclosure, H800 input flow — includes the 56.3% disk-cache-hit share, so it is not a fresh-prefill benchmark	9,212 tok/s/GPU aggregate	not used directly	fresh-prefill reconstruction calibrates the universal prefill transfer
vLLM GB200, R1 decode (source precision basis not fully pinned — possibly NVFP4; figure inherited, primary source not yet recovered)	~10,100 tok/s/GPU	10,114 at b=128, L=3,000 on the registered FP4 tuple	fitted per-row calibration; within 0.1% of the ~10,108 anchor
SGLang GB300 record, V4 Pro 1.6T FP4 + MTP (49B active, disclosed)	>12,000 tok/s/GPU	7,460 at declared b=128, L=2,740	analyst-set scenario-only row; measured value is null and the source batch/MTP basis is not reconstructable, so this is not a fit
Ant Group/SGLang production, H20 decode (R1, relaxed <70 ms tier; full weight-precision path not disclosed)	714 tok/s/GPU (675 at <50 ms; 423 at <30 ms)	680 at the source-published b=48, L=4,096 MTP point	source-informed neutral adjustment; does not reproduce the observation and earns no fitted-cluster credit
CloudMatrix-Infer, Ascend 910C decode (R1, INT8; vendor-measured, optimized 384-NPU supernode)	1,943 tok/s/NPU (538 at the separate b=8 / 14.9 ms fit input)	1,422.7 at the source-published b=96, L=4,096, MTP-70% point	source-informed neutral adjustment on the registered INT8 tuple; does not reproduce the observation and earns no fitted-cluster credit

Decode is often memory- or interconnect-bound; this is why "inference is memory" and why bigger NVLink domains and HBM can beat raw FLOPS. The live roofline path makes that binding term explicit at each rendered operating point. Domain of validity: the registered traffic lengths and declared serving regimes; the selector does not promise a TTFT/TPOT target, and KV-cache lifecycle outside the stated memory term remains unmodeled.

Registry/engine identity — reconciled (schema rev 2.2, reviewed 2026-07-27). The table above describes what the live engine actually computes with (per-row decode/prefill roofline η at each listed basis). The internal evidence registry separates source observations from deployed analyst identities and binds every deployed identity by test equality to the engine's calibration registry. Its closed classes are fitted, fitted-inherited, family-transfer, platform-native aggregate bridge, joint-fit, source-informed neutral, analyst-set assumed operating point, and projection. Retired scalar decode/prefill efficiency fields (effDec/effPre) remain archived as historical metadata, not a second live identity. The H20/Ascend relabel does not change their per-row throughput math; it does remove them from the typed throughput-eligible fleet set, so the named anchored-only counterfactual now contains only GB200 and H800.

4 · Chip efficiency: H100 → GB300 → Rubin

Expand this sectionCollapse this section

Platform	Dense FP8 (PF)	Dense FP4 (PF)	HBM	BW	TDP	Rental (Jul 2026)
H100 SXM (2022)	1.98	—	80 GB	3.35 TB/s	700 W	$1.99–3.90/hr, spot ≈ $2.40
H200 (2024)	1.98	—	141 GB	4.8 TB/s	700 W	$2.45–4.50/hr
B200 HGX, per GPU (2024)	4.5	9	180 GB	8 TB/s	1.0 kW	$6.69/hr on-demand (Lambda)
GB200 NVL72, per GPU (2024-25)	5.0	10	186 GB	8 TB/s	1.2 kW	$3.50–6.00/hr; rack ≈ $3–3.5M; AWS Capacity Block rack rate $761.904/hr ($10.582/GPU-hr) — cleanest full-rack market datum
GB300 NVL72 "Blackwell Ultra" (2025-26)	5.0	15	288 GB	8 TB/s	1.4 kW	No numeric rack rate public on any major provider (Jul 2026); B300 node anchor: Nebius $7.85/GPU-hr ⇒ $0.289/M output (§4)
TPU v7 Ironwood (GA Mar 2026)	4.61	—	192 GB	7.37 TB/s	~1 kW	$12/chip-hr on-demand, $5.40 3-yr (Jul 2026); Anthropic deal: up to 1M chips; rental-floor anchor: $6.42/M output tok on-demand (§10) — a vendor saturation run at infinite offered load; no achieved TTFT/TPOT published
Trainium2 (GA Dec 2024) / Trainium3 (GA Dec 2025)	1.3 / 2.51	—	96 / 144 GB	2.9 / 4.9 TB/s	~0.5–0.8 kW	Trn2 Capacity Block ≈$2.235/chip-hr (Jul 2026), engineering anchor $68.90–98.65/M output tok; Rainier launched with ~500k Trainium2 confirmed running Claude inference (Nov 2025), Anthropic reported >1M in use by Apr 2026, zero Trn3/Rainier economics disclosed
H800 — China export SKU (2023)	1.98	—	80 GB	3.35 TB/s	700 W	IDC annual-commit $1.47–2.06/hr (mid-2026, +30% post-Spring-Festival); DeepSeek's disclosure assumed $2
H20 — China-legal SKU (2024)	0.296	—	96 GB	4.0 TB/s	400 W	~$10–12k chip / ~$20k installed; rental class spans ~$0.76 (IDC annual) to $7+ (cloud on-demand)
Huawei Ascend 910C (2024–25)	1.50 (INT8; no FP8)	—	128 GB	3.2 TB/s	~0.6 kW	~$23k/chip installed; Huatai procurement $1.71–2.25/hr; CloudMatrix 384 ≈ RMB 60M ($8.2M); CM384 throughput anchored (§4), cost unanchored; 910B (older chip) cost proxy ≈$2.09/M output
Vera Rubin NVL72, per GPU (preliminary 2026 specs)	17.5 (dense FP8/FP6)	50 sparse NVFP4 inference (35 dense-class training)	288 GB HBM4	22 TB/s	~1.8 kW	production power and cost TBD — at the 2026-07-15 dive there was neither an MLPerf nor an InferenceX result and no public price, only a relative Kimi-K2-Thinking claim vs GB200 (10× tok/s/MW, ~1/10 cost); InferenceX has since posted preview Rubin results (seen 2026-10-04), not yet used here

Measured, not marketing: SemiAnalysis InferenceX (the successor to InferenceMAX, the field's independent benchmark) finds the most-optimized GB300 NVL72 delivers ~17× the best H100 config in FP8 and ~32× in FP4 on DeepSeek R1 (Jun 27, 2026) — and, critically, that software alone was a 14× gain on the same silicon (baseline FP8 ~1k → wideEP+disagg ~8k → +MTP ~14k tok/s/GPU). SGLang's reproducible benchmark runs agree: ~11–12k tok/s/GPU on V4 Pro 1.6T (an InferenceX/SGLang benchmark, not production telemetry), 6.5× over B200 with Dynamo disaggregation. At rack level: an H100 rack two years ago did ~8.8k tok/s; a GB300 NVL72 does ~370k — 42× in two years (8× of it HBM growth).

2026-07-15 — GB300 is now audited-throughput-anchored, but its rack price is still not public. A round-2 dive found MLPerf Inference v6.0 (Apr 1, 2026) contains valid, reproducible single-rack GB300 NVL72 results on DeepSeek-R1 FP4 — refuting any "GB300 has no public serving benchmark" framing: NVIDIA Interactive 250,634 / Server 400,437 / Offline 647,076 generated tok/s; Nebius submitted the strongest one-rack results, Server 575,580 / Offline 673,936. These are generated-output tokens (LoadGen sums completed-output-token counts), not input+output totals, and NVIDIA's headline 2.49M tok/s Offline figure is four racks (288 GPUs), not one. What remains missing: no numeric GB300 rack rental rate is public on AWS, CoreWeave, Nebius, GCP, Azure, OCI or Crusoe's pricing pages as of Jul 15, 2026 — so the honest model is GB300 $/M-output as a function of rack-hour price, not a point estimate (SemiAnalysis's own $190.94/rack-hr GB300 figure is explicitly labeled a temporary 1.2×-GB200 placeholder in its source code, not an observed rate). Note on the live calculator: that "function of price" framing describes the honest representation of the newly-documented bridge anchor — the $6/GPU-hr figure carried for GB300 is an analyst-estimated scenario input with no observed market rate behind it, and GB300 is 12% of the activated NA-blend default fleet by declared weight — 16% of the included, renormalized weight since the two Trainium legs (8 and 17 of 100) were withdrawn. Until 2026-09-10 it was not a registered accelerator-hour price at all, and the engine renormalized that leg out of the blended cost entirely rather than pricing it. The page has since ADOPTED $6.00 as GB300's planning rent (see the coverage note in §5), so this figure is now an input to the published readings — as a registered provisional row, not as an observed market rate. Nothing about the evidence changed: no GB300 NVL72 rack rental is published by any provider the arms checked, and the registry row says exactly that. The cleanest present Blackwell-Ultra anchor instead comes from the same-provider B300 node: Nebius's 8-GPU MLPerf Server result (60,413 gen tok/s) paired with its own public $7.85/GPU-hr rate gives $0.289/M generated output tokens — an accelerator-rental floor, before non-GPU serving overhead and utilization reserve (B200 comparably: $0.307/M — B300 is only ~6% cheaper despite ~17% more throughput, because its hourly price is higher). A GB200 rack bridge exists via AWS's Capacity Block rate ($761.904/rack-hr, the cleanest explicit full-rack market datum — though a reserved/upfront Capacity Block price, not ordinary on-demand): $0.881/$0.630/$0.435 per M output at Interactive/Server/Offline. Rubin remains absolute-economics-unanchored on this page — at the 2026-07-15 dive there was neither an MLPerf submission nor an InferenceX result (InferenceX listed Rubin as "Coming Soon"), and no public rental or purchase price for Rubin or Rubin Ultra. InferenceX has since published preview Vera Rubin NVL72 results (DeepSeek V4 Pro on its AgentX benchmark, marked as an official preview whose results may change; seen 2026-10-04); this page has not yet used them, so the Rubin row is still a projection. At the dive, NVIDIA's only public claim was relative (Kimi-K2-Thinking, 32K-in/8K-out): up to 10× tok/s/MW and ~1/10 cost per M tokens vs GB200 NVL72 — not an absolute anchor, and not to be confused with the different NVL144/Rubin CPX/R100/VR200 configurations. None of this changes the deployed GB200/GB300/Rubin roofline parameters above — it upgrades the evidence quality behind GB300 and documents, rather than fits, the new bridge anchors. (Full NVIDIA forward inference-economics dive →)

The China stack is its own cost universe. Under export controls the Chinese labs serve on three tiers: hoarded pre-ban H800s (H100 compute, capped NVLink — where DeepSeek's disclosure happened), the deliberately compute-starved but bandwidth-rich H20 (the main legal SKU since mid-2025; decode-friendly because decode is bandwidth-bound — Ant Group's production SGLang deployment is the best public anchor), and Huawei's Ascend 910C (Huawei's CloudMatrix-Infer paper reports 1,943 tok/s/NPU decode on R1, while DeepSeek's internal evaluation put the chip at ~60% of H100 — vendor and customer numbers disagree, so the calculator's Ascend row carries wide error bars). H200s were license-cleared for ten named Chinese firms in early 2026 but essentially none had shipped as of May; Beijing reportedly moved to allow those purchases this week (Jul 7–8). Chip scarcity also cuts the other way on price: Chinese H-series lease rates rose 20–30% over early 2026 on a >1,000× surge in national token volume (TrendForce) — Chinese margins are being squeezed from the cost side at exactly the moment Western $/token falls. One more trap: "the China rental rate" is a category error — the same H20 spans roughly ¥5–72 per card-hour (>10×) between annual IDC bare-metal leases and hyperscaler on-demand instances. The calculator's China rows use annual-commit rates; the GPU-hour cost multiplier is the dial for other rental classes.

2026-07-15 — CloudMatrix 384 gets a real generated-throughput anchor; production cost stays unmatched. A round-2 dive found the strongest public CM384 result to date: FlexNPU (arXiv:2606.04415, Jun 3, 2026) served DeepSeek-R1 W8A8 on a full 384-card 910C system at ≈633,000 generated tok/s system-wide (≈1,646/card) under stated TTFT ≤1s / TPOT ≤50ms constraints — end-to-end, SLO-constrained, and a different (full-system) measurement from the isolated-decode figure already in the row above. No public CM384 hourly rental price accompanies it, so throughput is anchored but cost is not. This dive also nails down a total-vs-generated conflation in the widely-repeated CloudMatrix numbers: the "6,688 tok/s/NPU" figure is PREFILL/INPUT throughput and an idealized perfect-expert-balancing projection (the directly measured default is 5,655 prefill tok/s/NPU), while the "1,943 tok/s/NPU" figure already cited above is DECODE at batch 96 (49.4 ms TPOT) — only ≈20 generated tok/s per active sequence, not an interactive per-user rate; these two figures must never be blended as simultaneous end-to-end throughput. A cross-source proxy exists for the older 910B chip: JD's xLLM paper (709 generated tok/s/card on 16 cards) paired with China Telecom CTyun's public RMB 38.45/hr 910B instance rate gives ≈$2.09/M generated output tokens (public-evidence range $1.61–2.80/M) — a cross-source reconstruction, not audited provider COGS, and not the 910C row above. Ascend 920 has no official product page, benchmark, deployment, cloud SKU or price — Huawei's own Sept-2025 roadmap goes 910C → 950PR (Q1'26) → 950DT (Q4'26) → 960 (Q4'27) → 970 (Q4'28), with no 920 — so any "920" cost figure would be fabricated from rumor and stays excluded from this model. None of this changes the deployed Ascend 910C roofline parameters above: the 1,943 and 538 isolated-decode observations remain historical inputs to the frozen joint calibration, while the live row is the separate source-informed neutral η=0.299324 identity and does not reproduce either observation. The FlexNPU full-system result remains an evidence annotation, not a pending automatic refit. (Full Ascend inference-economics dive →)

But cost per token falls slower than throughput rises, because rental prices track capability: $2.40/hr H100 → $6/hr GB300 eats ~2.5× of the 17×. Net hardware-economics gain per generation in $/Mtok: H100→H200 ~1.2×, H200→GB200 ~2–3×, GB200→GB300 ~1.1–1.5× (GB300's edge is HBM capacity for reasoning/long-context, not FLOPS), Rubin ~2–3× again. Cumulative 2024→2027: roughly 5–16× cheaper per token at the hardware level (the product of the per-generation ranges just listed; the commissioned fixed-model projection lands in the same band — ~4.5–10× by the 2027 Rubin ramp, ~7–17× by mature Rubin), before model-side efficiency (sparser MoEs, MTP, quantization) which historically contributed as much again. This is why margins at constant list prices would, on these hardware-cost assumptions alone, trend toward 95%+ — a mechanical consequence of the cost model under a fixed-price counterfactual, not a prediction, and one the market visibly pre-empts, which is why in practice prices fall instead (Opus's 2025-11 cut to $5/$25 was 3×; fast mode — $10/$50 on Opus 4.8, down from 4.7's $30/$150 tier retiring July 24 — shows the latency premium being monetized separately, and itself falling).

5 · The two independent estimates

The two estimate cards and the stress test under them are at the top of this page, beside the answer tile. The reasoning that stood in this position is in the expander below.

Expand this sectionCollapse this section

The conclusion: conditional, not blanket. A 90–95% serving margin at list price needs assumptions beyond this page's public-data scenario.

On the public-data scenario — the page-adopted 2.5T Opus, planning rents, algorithmic lead 0 months, family multipliers 1.0× — the modeled serving margin is about 58% at effective price: a model result under public-data assumptions, not a guaranteed minimum for actual margins and not an estimate. The calculator can still produce lower readings under other assumptions or model forms; those are hypothetical sensitivities of the model, not observed margins. Across the page's compatible price presets the scenario's settings span about 58% to 83%. The calculator's lead-adjusted baseline adds the adopted 3-month algorithmic lead — a labeled assumption, not a measurement — and reads about 68% (about 68–87% across the same presets). Every calculator figure in this section is at the public-data scenario's settings unless it says otherwise; 90–95% is the external claim under examination, not a reading of this page.

Two unresolved issues affect the calculator's reconstruction of this scenario. First, the fleet is assumed, and three different coverages have to be kept apart. All 7 of 7 declared legs are memory-feasible under the page's planning convention. Since 2026-09-10 all 7 of 7 also carry a planning accelerator-hour price. GB200, GB300 and Trainium3 still have no published rate of the low/committed planning class, and the three registry rows that price them are registered provisional and say so in their own source lines; before that adoption those three legs were excluded and this reading was computed over about 52% of declared fleet weight, which moved the reading from about 51% to about 58%. Since 2026-09-20 the reading above is computed over 5 of the 7, not all seven: the two Trainium legs are withdrawn from the default on evidence grounds — their operating point declares batch replica-global while this engine consumes it per chip, an open unit question worth about 15×, and this page's own hardware ledger already said that coefficient cannot support a central Trainium margin. Their declared 8% and 17% renormalize over the remaining five, and that renormalization is stated wherever the number is. Nothing is deleted: both rows keep their price, their dossiers and their scenarios, and the declared seven-leg topology is still selectable beside this one. One sourced coefficient that pins the batch/replica/accelerator identity puts them back. And which accelerators actually serve Opus, in what shares — the serving deployment — remains unverified. Second, and more serious, the model's own form is unresolved: on the public-data scenario's settings, holding each leg's efficiency factor (η) fixed while re-expressing the older traffic assumption produces a 47.54–61.28% span — a model-form sensitivity, not a range of observed margins, and an open calibration debt of 13.74 points — and the Trainium batch interpretation, which may make those legs ~15× wrong, is the reason they are now withdrawn from the default rather than carried inside it under a caveat.

So whether the claim is true depends on the invoice (what the lab pays per accelerator-hour), the operating point (how hard each accelerator is run), and that unresolved form. And it sits atop a stack of margins that shrinks at every step toward the income statement — §7 walks down that stack.

My planning scenarios for mid-2026 — balanced latency, 50% fleet utilization, low/committed planning rates, the deployed billing defaults (15% batch share, 5% discount; a pure list-price run lands ~5.0 points higher than the ~58% public-data scenario):

Opus-class (assume ~2.5T total / ~300B active): at the public-evidence reference the calculator produces an output-token cost of ≈$5.99/Mtok against $25 list (≈76% output-token margin at that list denominator; ≈73% against the effective output price of $21.97 after the 15% batch share and 5% discount); blended across the calculator's Reference mix (15:1 input:output, 60% cache hits; not a measured operating point), the selected scenario-preset alternatives span ~58–83% and the policy-labeled scenario is ~58% — both on the public-data scenario's settings; the lead-adjusted baseline reads ~68%. The cited "$4/1Mt" ceiling is not a validation target because the post does not identify input, output or blended tokens.
Sonnet-class (~1T total / ~120B active): at Sonnet 5's $2/$10 standing list price (made permanent 2026-08-10; the September 2026 step to $3/$15 was cancelled) the public-data scenario lands at ~54% blended at the public-evidence reference (algorithmic lead 0 months); as a counterfactual sensitivity only, pricing the same scenario at $3/$15 lands at ~69% on that same reference — that rate was the scheduled September increase and it was cancelled on 2026-08-10 and never took effect. On the lead-adjusted baseline the two readings are ~65% and ~77%. All seven declared legs are memory-feasible under the policy and all seven carry a registered price (three of them — GB200, GB300, Trainium3 — provisional, adopted 2026-09-10), but since 2026-09-20 only five of the seven are in the default reading: the two Trainium legs are withdrawn from it on evidence grounds, their declared shares renormalized over the rest, and the serving deployment remains unverified. The earlier 90–95% zone is therefore not reproduced by this activated operating point. (Sonnet 5's tokenizer also emits ~30% more tokens per text than 4.6 — per-token and per-text economics diverge across generations.)
If active params are lower than my assumption (TeorTaxes's reading of Fable's serving speed), Opus margins move up 5–10 points. The claim's truth is nearly monotonic in one number nobody outside Anthropic knows — but only locally, at fixed fleet membership: this holds within a feasibility boundary, not across one. A total-parameter change that crosses a boundary changes which legs are renderable and can move the displayed margin discontinuously, non-monotonically — but that is a different axis from the one below: the calculator's own sensitivity chart sweeps active parameters only, at a fixed total, so it does not cross or display this total-parameter boundary (at the opening scenario, all 121 swept points share one fleet membership).

Three things the bull case gets right: (1) the DeepSeek a-fortiori argument is the strongest first-party-grounded argument identified in this research (an anchor for what optimized serving can cost, not proof of any provider's margin — §2); (2) caching can be a margin machine under favorable billing and reuse conditions — cache reads bill at 10% of input price but are assumed here to cost ~1–5% of prefill to serve — an analyst-set, unobserved figure, as the methods box says — so agentic traffic stays high-margin even at deep effective discounts (assuming reuse is billed at the cache-read price; the billable-cached-share caveat in the methods box spans 75.3%→31.0% at the public-evidence reference on that assumption, and cache storage/retention/replication are unmodeled); (3) each hardware generation adds margin at constant prices, and Anthropic sits on three platforms (GB-class NVIDIA, up to 1M TPU v7, >1M Trainium2) with pricing leverage none of its open-weight competitors have.

2026-07-15 — a separate blinded model-generated cross-check lands in a broad adjacent band. A GPT-5.6 Pro dive rebuilt this page's own metric — serving margin, defined precisely, not company gross margin — bottom-up from public anchors only, under an explicit instruction not to consult this site or its repository; it disclosed at the end that neither ever appeared in its search results and neither was opened. For an equal-dollar basket of GPT-5.5 / Gemini 3.1 Pro / DeepSeek V4 Pro on a 4M-in/1M-out workload it landed on a central 73.3% (cross-model median 71.8%), with a modeled scenario range of 47–89% (not a statistical interval). This page's public-data scenario of ~58% (algorithmic lead 0 months) and its lead-adjusted baseline of ~68% BOTH sit below that central figure and inside the range. This is a robustness comparison, not an independent empirical measurement or a matched-estimand validation: it is the same model family operating over the same public source universe, estimating a different model basket, workload and hardware-cost path — and a 47–89% band is wide enough that containing the ~58% public-data scenario is weak corroboration. Blinding reduces direct copying; it does not create independent evidence. Its top sensitivity driver matches this page's own: delivered tokens/sec/chip at the actual workload (halving it moves the basket to 46.6%; doubling it, to 86.7%). (Full blinded cross-check dive →)

Three things it elides: (1) utilization — fleets are provisioned for peak; in a utilization sensitivity starting from the public-data scenario's settings, changing only utilization from 50% to 35% moves the calculator's Opus reading from 58.41% to 40.59% at the public-evidence reference, a 17.82-point drop in a hypothetical output (from the lead-adjusted baseline the same change moves 68.40% to 54.86%, a 13.54-point drop — the lever is real on either basis); (2) the latency premium is not free — interactive serving at user-acceptable speed costs ~1.4–3× throughput-optimal serving (fast mode's price premium exists for a reason — 2× on Opus 4.8, and it launched at 6×); (3) subscriptions and whales — documented tail users extract 15–40× their subscription in list-value tokens (§8); how much of the subscriber base is underwater is unknowable without a usage distribution nobody publishes, but the leakage direction is real and the API numbers never show it.

Forward hardware sensitivity scenario (not a forecast): the GB300→Rubin cost path would imply 92–96% Opus-class output margins by 2027 only if list prices and every non-hardware assumption held fixed (they will not) — a conditional sensitivity output of the cost model, not a prediction, with no probability assigned to future list prices, price cuts, token volume, or realized margins. The open question the scenario sharpens: how long can list prices sit this far above a falling cost floor while open-weight models (DeepSeek V4, GLM 5.2, Kimi) sell adequate quality at 10–20× less?

6 · GPT-5.6 Pro's analysis and verdict

Expand this sectionCollapse this section

Independent 54-minute research run on GPT-5.6 Pro (2026-07-09), given the same brief and no access to this page's model. The complete verbatim response and an adopted-findings summary are in the annex; divergences from §5 are tabulated below, preserved rather than harmonized.

Reach this operating point in the calculator: Load the strategic-partner fleet ↑ (GPT-5.6 Pro lens on Opus)

Model-generated scenario analysis; the spans below are uncalibrated sensitivity ranges, not confidence intervals.

GPT-5.6 Pro's verdict: "Standard-list-price marginal serving margin: approximately 92–94% for Opus and 94–96% for Sonnet on a mature 2026 fleet." And: "Is 95% an upper bound? No." — Sonnet at normal $3/$15 exceeds it, Opus on strategic TPU contracts exceeds it (97.2%) — but 95% is "not conservative for every token": at public cloud rates the same math yields only 55–85%.

Where its 93% and this page's public-data scenario actually differ — assumption by assumption, not a single "disagreement". Put on the same price basis — 93% for GPT-5.6 Pro against about 63% for the public-data scenario, both at list price (the scenario reads about 58% at this page's effective price) — the distance is 63-vs-93. Matching the price basis does not make the two figures the same measurement: as the first row below says, §5 blends a contribution margin across the traffic mix and §6 quotes input and output legs separately with no cache blending in its headline. The rows are where the difference actually lives, and no single gap number substitutes for reading them.

Assumption	§5 (this page's policy-labeled scenario)	§6 (GPT-5.6 Pro)	Why it matters
Estimand / metric	Serving margin blended across the traffic mix — quoted at effective price in §5, and at list price where it is set beside §6 above	"Economic marginal cost" margin; input and output legs quoted separately, no cache blending in the headline	Different metrics can differ by points before any input differs
Traffic mix	Reference 15:1 / 60% cache	Per-leg costs (cache economics treated separately)	Cache-heavy mixes raise blended margin at Anthropic's 10% cache-read price
Procurement	Registered low/committed planning rates (1.0×; a scenario vector, not one observed invoice)	Anthropic-scale strategic contracts (SemiAnalysis's Nov 2025 estimate for the 600,000 GCP-rented TPU v7: ≈$1.60/TPU-hr inclusive of Google's margin — an estimate, not a disclosed contract price)	The largest single assumption difference between the two, alongside differing fleet, architecture and metric assumptions; the page does not decompose the 63-vs-93 distance into contributions
Utilization	50%	75%	Linear divisor on all costs
Architecture	Opus ≈ 2.5T total / 300B active; Φ ≈ 2 × active + L-dependent attention (compute/HBM/fabric roofline, not a flat scalar)	Historical 5T total / 300B active; 2.3 × active	The active count agrees, but total size does not; total geometry changes residency, feasible width and fleet membership
Fleet	Mixed default blend of 7 declared legs (Hopper/Blackwell/TPU/Trainium), 5 included since 2026-09-20 (both Trainium legs withdrawn); all 7 memory-feasible, all 7 priced (3 provisional), serving deployment unverified	40% TPU v7 · 25% GB300 · 15% GB200 · 15% Trn2 · 5% H200	TPU-heavy blends are cheaper under strategic rates
Overhead	Stack factor 1.0, composed outside both the per-row decode calibration and universal prefill calibration; cluster overhead modeled in TCO mode	+10% CPU/network/reliability; explicitly not electricity-only, not full COGS	Small beside procurement

Its dominant sensitivity is the same as this page's: active parameters (Opus at 150B active → 95–97%; at 600B → 81–87%). The activated GPT-5.6 Pro scenario preset lands at ~83%, with all 5 of 5 declared fleet legs numerically renderable; that remains a page-authored scenario, not convergence with the external 93% analysis. The honest summary is therefore conditional on procurement, unverified placement and the open calibration debt — while architecture, traffic mix, latency targets and utilization remain first-order unknowns in their own right. Its other unique contributions are placed where they belong: the PitchBook/Morningstar 44% gross-margin estimate (§7), the GB300 5×-from-software-alone progression (§2c), and its own 93.5%→44% bridge allocation (verbatim annex).

Attribution divergence, preserved: GPT Pro's browsing never located the ncode/Noumena deployment and instead attributed the GB300 GLM-5.2 story to a merger of the SGLang/NVIDIA DeepSeek-V4 result with Baseten's GLM-5.2 work. The Grok X sweep, however, found the actual account — @_xjdr's ncode/Noumena, with primary post URLs (§2c). Where the two engines' account attributions conflicted we kept only what primary post URLs confirm; the direct post links in §1–2 are the ground truth we could verify.

A rare piece of direct evidence on the invoice question surfaced in the xAI dive (§10): the SpaceXAI prospectus discloses that Anthropic pays xAI $1.25B per month for ~325,000 GPUs plus supporting CPUs, storage and networking — about $5.27 per bundled GPU-hour, a real, dated, arm's-length price for capacity Anthropic actually buys. Caveats: it is a bundled service price, not a bare chip-hour, and contracted reserve capacity need not price the marginal fleet. But it brackets one tranche of the debate from above: a disclosed, dated, arm's-length price for capacity Anthropic actually buys. One bundled contract need not bound the blended invoice across all partners; it can be compared with, but does not validate, either this page's registered low/committed planning-rate vector or its strategic-partner scenarios.

2026-07-15 — Trainium gets a narrow public $/token candidate; Project Rainier itself still discloses none. A dedicated dive found AWS publishes two reproducible named-model Neuron benchmarks on a full trn2.48xlarge (16 Trainium2 chips) which, paired with the current Ohio Capacity Block rate (≈$2.235/chip-hr), give infrastructure-only anchors: Llama 3.3 70B (speculative decoding) $68.90/M output tokens; Llama 3.1 405B (FP8-rescaled target weights in a BF16 execution setting, plus speculative decoding) $98.65/M — engineering reference points (batch=1, concurrency=1, 10K-token prompt), not production TCO; the dive warns that calling the 405B run simply "FP8 inference" would overstate the disclosure. The negatives are the more load-bearing finding: no public Trainium3 anchor exists (GA'd with a GPT-OSS-120B recipe but no published throughput and no public instance/UltraServer price — neither side of $/token is public); Project Rainier is confirmed running Claude inference on ~500,000 Trainium2 chips (AWS, Nov 2025) but discloses no inference/training allocation, utilization, token volume, precision or internal rate — production-validation evidence, not a serving-economics anchor; there is no Trainium MLPerf submission through v6.0; and AWS's 30–40% price-performance claim over P5e/P5en remains unreproducible from any public matched benchmark. None of this changes the fleet-blend assumptions in the table above. (Full Trainium inference-economics dive →)

7 · Reported gross margins are lower, and the perimeter is the first thing to check

Expand this sectionCollapse this section

Reported and leaked figures for Anthropic's company gross margin paint a different picture from the unit math. They are five different objects, not five readings of one — so the table below gives each its period, its definition and its evidence status, and they must not be read as a progression.

Figure	Period	What it is	Evidence status
−94%	2024	Inference gross margin — a business-line cut, not a whole-company perimeter — as SemiAnalysis's own estimate and its own label	Analyst estimate (post)
40% (≈38% including free-tier chatbot inference)	2025	A lowered internal projection, down 10 points from an earlier 50% plan, because inference costs on Google and Amazon servers ran 23% higher than anticipated	Reported from people with knowledge of the financials (The Information, Jan 2026)
≈44%	reported Jun 2026	Gross margin tied to projected compute spend — $0.71 per revenue dollar in Q1 2026, projected $0.56 in Q2. Projected compute spend is not necessarily accounting cost of revenue	Third-party estimate (PitchBook/Morningstar, Jun 2026)
~70%, with a 15–20% free-cash-flow margin	mid-2026	Company gross margin	Zephyr's mid-2026 read, a social-media claim (post)
Quarterly gross profit −$55M → ~$453M, inference cost per token down ~40× since early 2024	posted Jul 2026	A claimed profit trajectory, not a margin	Social-media thread (@IvanaSpear)

Differences among them can reflect perimeter, method and forecast status as much as operating improvement. For scale beside them, from the same Jan 2026 reporting: 2025 revenue ≈ $4.5B, roughly 12× 2024's $381M, 86% of it API. A related forward-looking read from the lease-economics side has Anthropic converting roughly $5B of compute spend into an expected $15B of annual recurring revenue (May 2026) — a spend-to-revenue multiple, not a margin. And The Information ran a follow-up on why the labs kept missing their own gross-margin forecasts.

Inverting any of these reported margins back through this calculator does not yield a unique cost story: many combinations of hyperscaler markup, utilization, discounting and free-traffic share rationalize a 40–44% book margin equally well. That is why the reported-margin camp appears here as a diagnostic rather than as a claimed parameter set.

2026-07-26 update — a claimed realized-profit data point. At the RAISE Summit (Paris, recorded Jul 9, published Jul 16), SemiAnalysis's Dylan Patel said on stage that Anthropic turned its first gross profit in Q2 (June 2026) and will book slightly over $1B of operating profit in Q3 — figures he described as coming from the financials Anthropic is preparing to disclose in its IPO. Corrected 2026-08-23, amended 2026-10-04: the "first gross profit" phrase is Patel's own on the recording (about 1:14–1:27 of the session video, in this project's machine transcript; the 2026-08-23 check had only a published summary of the session), but it conflicts with SemiAnalysis's own written record (an inference gross margin of 38% in 2025 and "mid 60s" by May 2026; operating-income-profitable in Q2 after adjusting for stock-based compensation) and with Patel on the Sequoia podcast ("net income profitable excluding stock-based compensation") — treat it as an unverified claim (analyst-divergence page). This is Patel's own characterization of pre-IPO financials he says he has reviewed, not a company disclosure or filing, and it stays unverified until Anthropic's actual IPO/S-1-equivalent materials surface. If accurate, it would be the first realized-profit claim in this section — every other figure above is a projection (the 40% 2025 GM plan), a modeled estimate (PitchBook/Morningstar's 44%) or a social-media analyst read (Zephyr's ~70%), none of which asserts an actual profit was booked.

Sensitivity and perimeter map — not an accounting reconciliation. The rows below identify one-at-a-time sensitivities and items outside the calculator, roughly in order of size. Several are already embedded in the selected unit result; the ranges must not be added or subtracted from the headline, and they do not reconcile unit contribution margin to company gross margin:

Item	Mechanism	Rough magnitude	Already in the calculator?
Compute procurement markup	Anthropic buys most compute from AWS/GCP, who take their own margin; partner-committed economics can also sit well below public cloud rental. DeepSeek/High-Flyer appear to control substantial compute (the $2/hr figure was a costing assumption; the current owned/rented mix is undisclosed).	−10 to −20 pts	Yes — the price preset / rent multiplier
Marketplace / channel revenue share	Some channel revenue shares 30–40% with the clouds (Bedrock/Vertex economics) — a revenue-side item, distinct from procurement cost.	−3 to −10 pts	No — outside the calculator
Utilization & peak provisioning	Capacity sized for Monday-morning peak. 35% vs 70% utilization is a 2× on cost.	−5 to −15 pts	Yes — the utilization divisor (the default already allocates 50% slack)
Subscription over-consumption	Flat-fee plans where the tail extracts 15–40× the fee (§8); weekly caps (Aug 2025) exist to clamp exactly this.	−5 to −10 pts	No — API-billing perimeter only
Free tier & internal inference	claude.ai free traffic, evals, RL/synthetic-data generation all burn serving compute against zero revenue (some booked as R&D, treatment varies).	−5 to −10 pts	No — billed traffic only
Discounts & mix	Enterprise/committed-use discounts, 50%-off batch tier, and cache-heavy traffic. SemiAnalysis estimated ~$0.99/Mtok for its Opus 4.7 agentic workload at ~300:1 input:output and >90% cache hits — a workload-specific blended billed price, not Anthropic-wide realized revenue per token.	−3 to −8 pts	Partly — batch/discount sliders and cache-read prices
Unreconciled accounting perimeter	What lands in COGS vs S&M vs R&D differs by lab — fleetingbits' point that Anthropic books cloud commissions under sales & marketing cuts the other way, flattering GM.	±	No — accounting policy, not unit economics

Dollars make the map legible in a way percentage points hide: on the Opus policy-labeled scenario (Reference 15:1/60% traffic, 15% batch share, 5% average discount), 1M blended tokens bill $3.71875 before discounting and $3.26785 as the modeled effective price; modeled direct-serving cost is $1.35908 at the public-evidence reference (algorithmic lead 0 months) and $1.03268 under the lead-adjusted baseline (+3 months for the closed labs — a labeled assumption, not a measurement) (placement remains unverified). At that fixed denominator one percentage point ≈ $0.03268/Mtok, so a notional 10–20-point cost increase is $0.32679–$0.65357 per million tokens — about 24.0–48.1% of that modeled direct-serving cost. Both dollar figures are five-of-seven-leg results since 2026-09-20, when the two Trainium legs were withdrawn from the default on evidence grounds and their declared weight renormalized over the rest. Separately, until the 2026-09-10 rent adoption, three declared legs — GB200, GB300 and Trainium3 — carried no registered accelerator-hour price, so the engine renormalized them out and computed the cost over the remaining 51.96% of declared fleet weight — which excluded GB200, the one leg whose decode coefficient is fitted to a matched measurement rather than transferred or analyst-set. The page now adopts a provisional planning rent for each of the three, so all seven are priced — pricing and default membership are different questions, and the two Trainium legs are priced and still withdrawn. That is a different thing again from memory feasibility, which all seven legs pass, and from serving deployment, which remains unverified. A missing price was never a zero cost, and an adopted provisional price is not an observed one. These are scenario conversions at the engine's current defaults, not an accounting reconciliation.

Training compute — the industry's historically heavy cash burn — sits below gross margin in R&D under the accounting policies reported for these providers; the classification is the filer's and varies — it explains why the company loses money overall (training reportedly falling from 400%+ of revenue toward ~36% by end-2026 per the IvanaSpear thread), not why gross margin is below the unit margin.

8 · The subscription-token investigations

Expand this sectionCollapse this section

Selection rule for this section: multi-month, tool-tracked (ccusage-class) longitudinal records only — single-session anomalies and one-off screenshots are excluded as tail-of-the-tail. The two that qualify: ksred's Claude Code pricing guide — ~10B tokens over 8 months: ~$15,000 at API list prices against ~$800 of Max subscription fees (~19×) — and btcbigd's 60-day record — 8.6B tokens / ~$8.5k at list (~21×). Shorter-window corroborators (the widely-shared melvynx $3,200-capacity calculation, olofj's 2.5-month track, and others) point the same direction and are archived in the annex sweep; the subscription card below defaults to the melvynx capacity figure.

What these investigations do and do not establish: heavy subscribers demonstrably extract API-list-value equivalents many times their fee — $3,200 of sticker sold for $200 in the melvynx case, which at this page's modeled direct serving cost is perhaps $300–900 to actually serve depending on mix. They characterize the tail, not the median — no representative usage distribution, mean or median is public, so nothing here identifies whether the typical subscriber is profitable. What the plans' generosity is consistent with is low marginal serving cost; it does not independently prove it — breakage, throttling, workload routing, acquisition subsidy and cross-subsidy can all contribute. The weekly limits (Aug 2025) and repeated 5-hour-window retuning (May 2026 doubling) show the tail is real enough to clamp. The subscription card in the calculator computes break-even for whatever usage level you set — it says nothing about the distribution.

Dated 2026-10-05 — SemiAnalysis's subscription estimates. In the public portion of a Tokenomics Model piece (its tables are paywalled), SemiAnalysis estimates that Anthropic's subscriptions are about 10% of its revenue but can take over 40% of its inference compute, lowering blended revenue per MW by about $36M (the piece does not say over what period). The plan figures that follow assume agentic usage, with token types in SemiAnalysis's own September ratios; the piece notes that a plan's value depends on the model and the workload. Assuming 92% API gross margins, it puts the gross margin of a plan maxed out on Opus 5.5 at −369%, and on Fable 5.1 at 1%, at 100% utilization; at an assumed 20% average utilization the two rise to 6% and 80%. Its measured plan limits put Anthropic's plans at about 5× the API-equivalent value of OpenAI's for the mid-tier models; OpenAI had halved the API-equivalent value of its $200 plan the week before (plans bought before the cut keep the old limits until 29 October), and Anthropic's ~20% (Max) and ~50% (Pro) increases in Opus limits after the Opus 5.5 price cut (−20% on input and output, −60% on cache reads) did not fully offset that cut. These are one analyst's model outputs at the subscription layer, not company disclosures and not this page's unit serving metric, and like the records above they turn on utilization: the 100% case is the maxed-out tail, and 20% is SemiAnalysis's assumption, not a measured median.

9 · The most comprehensive public analyses

Expand this sectionCollapse this section

DeepSeek — V3/R1 Inference System Overview (Open Source Week Day 6, Mar 2025). The clearest and most complete first-party production serving-economics disclosure identified in this research. Start here.
Epoch AI — "Inference economics of language models" (Ege Erdil, Jun 2025; arXiv:2506.04645, reproducible notebook). The rigorous version of what this page approximates: Pareto frontiers of cost-per-token vs serving speed from arithmetic, memory-bandwidth, network and latency constraints — the academic anchor for why latency, not FLOPs, binds.
SemiAnalysis — InferenceX (née InferenceMAX). Continuous, vendor-neutral tokens/s and $/Mtok benchmarking across GB300/GB200/B200/H100/MI355X on real MoEs; the source for the per-generation efficiency numbers here.
SemiAnalysis — Vera Rubin deep-dive (Feb 2026) and Trainium3 deep-dive — the forward cost-curve.
ksred — Claude Code pricing guide — the most rigorous plan-tokenomics investigation.
LMSYS/SGLang engineering blog — "Serving DeepSeek-V4 on GB300: 5× higher throughput at the same interactivity" (Jun 2026) — what optimized open-source serving actually achieves, with methodology.
SemiAnalysis — "AI Value Capture: The Shift to Model Labs" — the best public treatment of realized blended prices, cache-heavy agentic workloads, and model-lab inference margins (GPT Pro's top pick for the pricing side).
MLCommons — MLPerf Inference: Datacenter — the standardized cross-generation benchmark corpus (v6.0 added DeepSeek-R1 latency-constrained + speculative-decoding scenarios).
The DeepSeek disclosure thread + TeorTaxes's running commentary — the live debate this page quantifies.
This page's research annex — the full public GPT-5.6 Pro deep dives (one per provider), hardware sweeps, and X-post hunts behind every section here, with their own citations. A documented public-release hygiene pass condensed provenance headers, removed conversation IDs and raw interface citation markers, and archived the pre-edit copies — conclusions unchanged (see the changelog). This is a selected set of public artifacts, lightly edited for release: each file states its own provenance class (verbatim original, adopted-findings summary, reconstruction, or partial/timeout result) — not every file is a complete verbatim transcript, and some original working files (e.g. an expired grounding pack, later reconstructed) are unavailable.

10 · The other providers: what's known, what isn't

Expand this sectionCollapse this section

One independent GPT-5.6 Pro deep dive per provider (2026-07-09), cross-checked against dedicated hardware sweeps. Full public reports — with their own citations — in the research annex (provenance headers condensed for public release; conclusions unchanged).

The Anthropic verdict above rests on an unusual density of evidence: a primary serving disclosure from a direct competitor, a parameter leak from a rival CEO, leaked business financials, and a live X-sphere argument between named analysts. None of the other providers has all of that, and some have almost none of it. Read the July 2026 dossier cards below as provider-native case studies, not a like-for-like ranking: each dossier's numeric headline reports the activated shared-roofline replay — OpenAI, Google, xAI, DeepSeek and Zhipu are workload-specific blended list-price serving margins, while Moonshot is an output-token margin only — and the traffic mixes, service tiers and scenario presets differ materially across cards, so rank order would encode the analyst's assumptions as much as the providers' economics. All current card fleets produce numeric outputs, but that is implementation feasibility, not empirical validation or verified placement. The displayed ranges are analyst-elicited scenario ranges spanning selected downside and upside cases; no statistical probability is attached to them. The badge grades public observability of the evidence base, not numeric reliability, and each card carries a five-dimension evidence profile inside. A deterministic test suite cross-checks every card headline and membership statement against the activated engine. These replays translate each dive into one shared roofline; they do not reproduce each dive's own component model.

Each provider below except DeepSeek now opens with its current model's estimate from the Astra Pro category (the same number as that model's dot in the chart), then the inputs the two estimates set differently, then the July 2026 dive as a dated dossier; no current estimate covers DeepSeek's Pro tier, so its section opens with a note saying so. The paragraph above describes those July dossiers: Moonshot's current estimate is a blended margin, while its July dossier below stays an output-token margin.

OpenAI — current estimate for the selected model, GPT-6.1 Sol: serving margin ~84% at list price (GPT-6 Astra Pro's central inputs worked through this calculator; one research run, 2026-10-01; its low- and high-margin scenarios ~42%–~91%). The selected model's margin, not a provider-wide margin.

Reach this estimate's operating point in the calculator: Reproduce this estimate ↑ (Astra Pro's central inputs) · its card in Astra Pro estimates ↓ · its GPT-6 Astra Pro review →

What differs from the July dive. These are the inputs the two estimates set differently; the two numbers are not a like-for-like comparison.

model size: July 105B active / 5000B total, fp8 · now 100B active / 5000B total, fp8
list price: July $4/$20 per million tokens, cached input 10% · now $2/$10 per million tokens, cached input 5%
fleet and hour cost: July H100 SXM 20% at $2.04/h · H200 25% at $3.13/h · GB200 NVL72 45% at $3.82/h · GB300 NVL72 10% at $5.10/h · now H200 30% at $3.50/h · GB200 NVL72 50% at $4.50/h · GB300 NVL72 20% at $6.00/h
utilization: July 73% · now 70%
serving-stack efficiency: July 0.75× · now 1.0×
traffic: July 9:1 input:output, 78% cache hits · now 12:1 input:output, 80% cache hits

July 2026 dossier — GPT-5.6 Sol, one GPT-5.6 Pro deep dive (2026-07-09). The dive's own reading: 94% (86–97%). The card below shows this calculator's replay of that dive today; its evidence profile describes the July model.

OpenAI — GPT-5.6 Sol serving margin ~90% (this page's replay of the dive, at list price; the dive's own stated central is ~94% with an 86–97% span, uncalibrated; all 4 of 4 declared fleet legs fit their declared serving setup) evidence: medium

Evidence profile — architecture: medium · pricing: high · fleet & TCO: medium · production throughput: low · financial perimeter: medium

Metric: blended serving margin at list price · lens: partner-fleet economics (dive: 0.85× rental, 73% utilization) · traffic: OpenAI dive mix 9:1 / 78% cache. Provider-native case — not cross-provider comparable.

The closest analogue to the Anthropic case: a partner-hosted fleet (OpenAI discloses 3 GW of dedicated inference capacity on Hopper/Blackwell across Microsoft, OCI and CoreWeave — contractually controlled but not owned), premium list prices (Sol $4/$20 short-context, corrected 2026-09-19 from the $5/$30 this page carried until then), and an active-parameter estimate (~100B) that is only a community figure — though one independently corroborated by Epoch's inference-economics work. The most interesting tension: the dive's own stated ~94% list-price serving margin — this page's replay of that vector reads ~90% — coexists with a reported 70% "compute margin for paying users" (The Information, Oct 2025) and a 33% company adjusted gross margin — the gap is take-or-pay reserved capacity, subscriptions and free traffic, i.e. the same margin-stack that separates Anthropic's unit math from its books (§7).

Known knowns (top 3 — full ledger in the grounding ledger and dive)

Sol/Terra/Luna list prices: $4/$20, $2/$12, $0.20/$1.20 (in/out, short-context; re-read from each model's own page 2026-09-19 — the $5/$30, $2.50/$15 and $1/$6 this list carried until then were superseded); batch/flex exactly −50%; cache reads −90% (disclosed)
3 GW dedicated inference capacity; Stargate Abilene runs GB200 via OCI; strategy explicitly "partner-centric" (disclosed)
70% compute margin on paying users (Oct 2025) and 33% adjusted gross margin for 2025, vs a 46% forecast (The Information)

Known unknowns (top 3)

Parameters and routing: ~100B active is an estimate; effective-capacity methods allow 3–29T total
The Azure/Stargate transfer price ($2.2–4.8/GPU-hr modeled band) and Microsoft's revenue-share percentage
Utilization and aggregate tok/s/GPU — the dominant driver: a >4× cost span on its own

2026-07-26 update — a later, differently-cut margin trajectory (analyst characterization, not company disclosure). At the RAISE Summit (Paris, recorded Jul 9, published Jul 16), SemiAnalysis's Dylan Patel said OpenAI's company-wide gross margin went from ~30% late last year to ~55% today, and — stripping away free users — from ~50% to ~65%. Corrected 2026-10-04: a correction of 2026-08-23 withdrew the ~30% and ~50% starting points because two research arms found them in no source; they had only the published session summary, which gives the endpoints alone. The starting points are in the recording itself, in the same breath as the endpoints (about 1:32–1:43 of the session video, in this project's machine transcript of it), so they are restored. The Information's 33% is still a different, "adjusted" cut and cannot stand in for Patel's ~30% (analyst-divergence page). This is a differently-cut, more recent figure than the 33%/39% adjusted-GM figures above (The Information/Reuters, FY2025/Q1-2026): Patel's cut explicitly separates paying-user economics from the free-tier drag, the same distinction this page's own unit-vs-accounting-margin framing needs (§7). The figure carries the same caveat as the Anthropic remark from the same appearance (§7): Patel's own characterization of financials he says he has seen, not an OpenAI disclosure.

Why the scenario range is 86–97%: throughput assumptions alone span >4× in cost; reserved take-or-pay capacity can make slack-period allocated cost several times the engineering marginal cost; and the true transfer price is bracketed only by market comparables and Oracle-offtake arithmetic. Would update on: a production tok/s/GPU datapoint, a Stargate/Azure transfer-price disclosure, or a credible parameter leak.

Reach this operating point in the calculator: Reproduce this card ↑ (§10 dive replay)

Full GPT-5.6 Pro report →

Google — current estimate for the selected model, Gemini 3.1 Pro: serving margin ~92% at list price (GPT-6 Astra Pro's central inputs worked through this calculator; one research run, 2026-09-25; its low- and high-margin scenarios ~84%–~94%). The selected model's margin, not a provider-wide margin.

Reach this estimate's operating point in the calculator: Reproduce this estimate ↑ (Astra Pro's central inputs) · its card in Astra Pro estimates ↓ · its GPT-6 Astra Pro review →

What differs from the July dive. These are the inputs the two estimates set differently; the two numbers are not a like-for-like comparison.

model size: July 120B active / 3000B total, fp8 · now 100B active / 2000B total, fp8
fleet and hour cost: July TPU v7 Ironwood 100% at $1.62/h · now TPU v7 Ironwood 100% at $1.36/h
utilization: July 75% · now 70%
serving-stack efficiency: July 0.55× — no recorded source · now 1.0×
serving posture: July throughput · now balanced
traffic: July 15:1 input:output, 60% cache hits · now 8:1 input:output, 40% cache hits

July 2026 dossier — Gemini 3.1 Pro, one GPT-5.6 Pro deep dive (2026-07-09). The dive's own reading: 95.7% (89–98%). The card below shows this calculator's replay of that dive today; its evidence profile describes the July model. The dive's band is historical and is not an interval around either number.

Google — Gemini 3.1 Pro serving margin ~84% (activated replay; uncalibrated; all 1 of 1 declared fleet legs fit their declared serving setup) evidence: low (params)

Evidence profile — architecture: low · pricing: high · fleet & TCO: medium · production throughput: low · financial perimeter: medium

Metric: blended serving margin at list price · lens: internal-cost path (dive: derived ≈$1.62/Ironwood-hr — the registered $5.40 committed rate × the dive's 0.30 scalar, 75% utilization, throughput batching) · traffic: Reference 15:1 / 60% (no Google-native mix is public). Provider-native case — not cross-provider comparable.

The Gemini margin is not publicly identifiable; the activated calculator now produces a conditional ~84% replay. Its single TPU v7 leg is numerically renderable at the capacity-solved operating width, but the internal TPU price, the serving deployment and Gemini architecture are not public. Google still has the most direct internal-cost path on the page: it designs the TPU stack and serves Gemini on Google-operated infrastructure — though the serving deployment and the internal capacity charge are undisclosed, so the derived ≈$1.62/Ironwood-hour (the registered $5.40 committed rate × the dive's 0.30 scalar) remains an unanchored scenario input rather than an identified margin. It also carries the weakest architecture evidence of any provider: no credible leak of Gemini's total or active parameters exists at all, so the 120B-active/3T-total inputs are scenario midpoints, not estimates. The disclosed facts are all about scale and trajectory: serving unit costs down 78% during 2025, ~3.2 quadrillion tokens/month across surfaces, ~19B API tokens/minute.

Known knowns (top 3 — full ledger in the grounding ledger and dive)

List: $2/$12 with $0.20 cache reads ≤200K (higher tier above); no free API tier for 3.1 Pro (disclosed)
Serving unit cost −78% during 2025; a further >30% cut on Search AI responses after Gemini 3 (disclosed, earnings calls)
Full-stack energy telemetry: accelerators are only 58% of per-prompt energy — the 1.72× stack-overhead anchor (disclosed, paper)

Known unknowns (top 3)

Total and active parameters — the dominant driver; genuinely unknown outside Google; a 60–240B active bracket is a 4× cost swing
Internal transfer price for TPU time — no credible report exists
Production throughput at latency (decode MFU modeled at 4–15%)

2026-07-15 — TPU now has real cost-per-token anchors, but they still don't close on Gemini. A dedicated dive found public named-model, named-precision serving benchmarks now exist for every current TPU generation — the best is Qwen3-Coder-480B-A35B-Instruct-FP8 on four Ironwood chips, 518.86 output tokens/sec/chip at 1K-in/8K-out, which at current list ($12/chip-hr on-demand, $5.40 at 3-yr) derives $6.42/M output tokens on-demand, $2.89/M at 3-yr commitment; supporting anchors include v6e Llama 2 70B at ~$0.94/M and v5e Llama 2 70B at ~$1.77/M. This is real progress over "peak FLOPS only" — but it does not change this card's own dominant unknown. The load-bearing negative the dive was explicit about: there is still no public basis to compute Gemini's margin from TPU economics — the rental prices above are Google's external customer list prices, not its internal fleet cost, and Google has never published a mapping from a named Gemini API SKU to a TPU generation, topology, precision, throughput or utilization. The accelerator-rental anchors are a hardware-platform upgrade, not a Gemini-specific one.

Why the scenario range remains unquantified: the replay's ~84% is a page-authored point, while the two dominant unknowns (active parameters and effective decode efficiency) each span 3–4× in cost and no probability model is justified. Vertical integration would only put a floor under the answer if Google's internal TPU cost and Gemini's architecture were known, and neither is. Would update on: any credible Gemini parameter information, an internal TPU-rate datapoint, or a public Ironwood serving benchmark at stated latency.

Reach this operating point in the calculator: Reproduce this card ↑ (§10 dive replay)

Full GPT-5.6 Pro report → · TPU inference-economics dive →

xAI — current estimate for the selected model, Grok 4.6: serving margin ~81% at list price (GPT-6 Astra Pro's central inputs worked through this calculator; one research run, 2026-09-25; its low- and high-margin scenarios ~66%–~89%). The selected model's margin, not a provider-wide margin.

Reach this estimate's operating point in the calculator: Reproduce this estimate ↑ (Astra Pro's central inputs) · its card in Astra Pro estimates ↓ · its GPT-6 Astra Pro review →

What differs from the July dive. These are the inputs the two estimates set differently; the two numbers are not a like-for-like comparison.

list price: July $2/$6 per million tokens, cached input 15% · now $2/$6 per million tokens, cached input 25%
fleet and hour cost: July H100 SXM 45% at $1.49/h · H200 5% at $2.28/h · GB200 NVL72 25% at $2.79/h · GB300 NVL72 25% at $3.72/h · now GB200 NVL72 50% at $2.10/h · GB300 NVL72 50% at $2.50/h
utilization: July 48% · now 65%
serving posture: July throughput · now balanced
traffic: July 3:1 input:output, 0% cache hits · now 8:1 input:output, 60% cache hits

July 2026 dossier — Grok 4.5, one GPT-5.6 Pro deep dive (2026-07-09). The dive's own reading: 67% (10–85%), full-cycle TCO lens. The card below shows this calculator's replay of that dive today; its evidence profile describes the July model.

xAI — Grok 4.5 serving margin ~63% full-cycle-TCO lens (scenario range 10–85%; uncalibrated; all 4 of 4 declared fleet legs fit their declared serving setup) evidence: medium

Evidence profile — architecture: medium · pricing: high · fleet & TCO: high · production throughput: low · financial perimeter: high

Metric: blended serving margin at list price under the full-cycle-TCO lens (cash-marginal ≈91% and Anthropic-contract opportunity ≈19% are selectable as valuation replays in the calculator) · traffic: Uncached 3:1 / 0% (the dive convention). Provider-native case — not cross-provider comparable.

The one lab that operationally controls a purpose-built fleet — much of it finance-leased, so “owned” is not the relevant cost classification — and the widest judgmental range on the page, because "what does a GPU-hour cost xAI?" has three defensible answers. The SpaceXAI prospectus disclosed cluster counts that sum to >440k accelerators (200k+ H100/H200/GB200 at Colossus, 110k GB200 + 110k GB300 at Colossus II — the total is a derivation from those disclosed counts) — but $20.2B of it sits on finance leases, and AI capex ran $12.7B in 2025 alone. Grok 4.5 (launched Jul 8 at $2/$6) is disclosed at 1.5T total parameters; active count is anyone's guess (100–500B). The decisive fact: Anthropic pays xAI $1.25B/month for ~325k GPUs (≈$5.27/GPU-hr) — so, to the extent that capacity is fungible with the Anthropic contract, a GPU-hour spent serving Grok instead of billed to Anthropic forgoes a disclosed wholesale price more than twice xAI's estimated full-cycle cost. (This opportunity cost is bounded by the ~325k contracted GPUs; it does not apply uniformly to every GPU-hour across the whole >440k fleet.) In the activated replay, cash-marginal cost lands at ~91%, full-cycle TCO at ~63%, and the Anthropic-contract opportunity value at ~19%; all four declared fleet legs now render numerically, though H100 is batch-capped and placement remains unverified. Zephyr's "xAI isn't juicing margins" is true or false depending entirely on which lens you pick.

Known knowns (top 3 — full ledger in the grounding ledger and dive)

Grok 4.5 = 1.5T-total MoE ("V9 foundation model", Musk; MoE per Cursor); 80 tok/s user streams; $2/$0.30/$6 list (disclosed; cached input is 15% of $2 since the 2026-09-10 correction)
Fleet: >440k accelerators across Colossus I/II — but $20.2B sits on finance leases: "owned" ≠ paid-for (prospectus, disclosed)
Anthropic capacity contract: $1.25B/mo for ~325k GPUs ≈ $5.27/GPU-hr; Google (from Oct 2026): $920M/mo for ~110k ≈ $11.45/hr (disclosed/derived)

Known unknowns (top 3)

Saturated aggregate throughput — 80 tok/s is per stream; the dominant driver (~8× cost swing)
Active parameters and routing on the 1.5T MoE (100–500B — the Grok-2 lineage ran unusually dense at 42.7%)
How capacity is allocated among Grok, Anthropic, Google, Cursor, training, and idle

Why the scenario range is 10–85%: unknown batch throughput spans ~8× in cost, and the GPU-hour can be honestly valued anywhere from $0.60 (cash) through $2.40 (full-cycle) to $5.27 (contracted opportunity cost) — the margin question dissolves into the valuation question. Would update on: any saturated-throughput datapoint, new capacity-contract terms in SpaceXAI filings, or an active-parameter disclosure.

Reach these operating points in the calculator: Reproduce this card ↑ (full-cycle TCO) · Cash-marginal valuation ↑ (≈91%) · Anthropic-contract opportunity cost ↑ (≈19%)

Full GPT-5.6 Pro report →

DeepSeek — current estimate: No current-model estimate covers DeepSeek's Pro tier. The chart's DeepSeek dot is V4.1-Flash, a different, cheaper tier, so it is not this provider's headline.

July 2026 dossier — V4 Pro, one GPT-5.6 Pro deep dive (2026-07-09). The dive's own reading: 69% (45–83%), on the 2026-07-09 tariff ($0.435/$0.87). The card below shows this calculator's replay of that dive today; its evidence profile describes the July model. Since the 2026-09-19 tariff correction this replay reads ~86%, so the July text below describing it as one of the lower estimates no longer holds. The dive's band is historical and is not an interval around either number.

DeepSeek — V4 Pro serving margin ~86% (no current scenario range is supplied for this replay; uncalibrated; all 1 of 1 declared fleet legs fit their declared serving setup) evidence: mixed

Evidence profile — architecture: high · pricing: high · fleet & TCO: low · production throughput: low · financial perimeter: low

Metric: blended serving margin at list price · lens: dive central scenario (≈$1.50/H800-equivalent-hr, their own stack) · traffic: DeepSeek disclosure 4:1 / 56% cache. Provider-native case — not cross-provider comparable.

The inversion of the Anthropic story. DeepSeek has unusually strong public evidence — disclosed architecture (1.6T total / 49B active, selective FP4), disclosed pricing, and the clearest production serving disclosure identified in this research — yet one of the lower provider-native estimates (the cards are not directly rankable), because it chose to convert its efficiency into price: a permanent 75% cut took V4 Pro to $0.435/$0.87 in July 2026 — a tariff DeepSeek has since replaced, so this row now carries the $0.66/$1.98 off-peak list read from DeepSeek's own pricing page on 2026-09-19 ($1.32/$3.96 peak), roughly 10% below R1's old output price. The activated ~86% replay is still only a sensitivity surrogate: the row computes on a whole-model FP4 precision tuple and does not model V4's component-selective FP4/indexer/KV precisions (its KV stays BF16/FP8), so the open checkpoint does not make this particular number exact. Repricing the old disclosed workload (342B cached-input, 266B uncached-input and 168B output tokens a day, against its assumed $87,072/day GPU cost) at the adopted 2026-09-19 off-peak tariffs gives about 83% for V4 Pro and about 39% for V4-Flash. That assumes the disclosed disk-cache hits bill at the cache-hit rate, and it is a price-only counterfactual, not an estimate of V4 operating economics. The ~67% once quoted here came from the retired $0.435/$0.87 tariff.

Known knowns (top 3 — full ledger in the grounding ledger and dive)

V4 Pro: 1.6T/49B; V4-Flash: 284B/13B; FP4 is selective (routed experts + indexer; KV stays BF16/FP8) (disclosed)
List (read 2026-09-19): $0.022 cache-hit / $0.66 miss / $1.98 out off-peak ($1.32/$3.96 peak); the Jul 9 $0.003625 / $0.435 / $0.87 tariff after a permanent 75% cut is historical, superseded (disclosed)
The 2025 H800 production trace: $2/hr assumption, 84.5% theoretical margin at R1 list (disclosed)

Known unknowns (top 3)

Current fleet mix (H800 vs H20 vs Ascend 950 vs internal) — the dominant driver
V4 production throughput — no V4 equivalent of the 2025 73.7k/14.8k tok/s disclosure
The 2026 owned/rented split and true chip-hour basis

2026-07-15 update. The Information reported (Jul 14–15, via @jukan05/@jingyanghk relays) DeepSeek's annualized revenue nearing ~$500M, a ~¥50B (~$7.4B) raise at a ~¥500B (~$74B) valuation with STAR Market IPO prep, and — in a follow-up — a 70–80% V4 API gross margin (up from an earlier ">50%" figure; The Information). This is the first press-reported (The Information, via relays) post-V4 API-margin datapoint identified in this research — not company-confirmed, and carrying no disclosed accounting definition — corroborating in direction, though not metric-identical to, the disclosure-era a-fortiori argument (§2a). TeorTaxes's fleet backsolves from the $500M figure bracket a wide range depending on utilization assumptions: at V4 list output prices and 100% utilization, ~$88.3K/GPU/yr implies ~5,662 GPUs; at more realistic bundle-cost utilization, $28K–$55.7K/GPU/yr implies ~9,000–18,000 GPUs — a useful independent check against this dive's own dominant unknown (current fleet mix), though TeorTaxes's own caveat applies: the math covers paid API only, not the consumer app.

2026-07-15 — a non-NVIDIA production data point, corrected. DigitalOcean and RadixArk publicly reported serving DeepSeek V4 Pro (FP4) on AMD Instinct at 3,500+ aggregate tok/s/GPU (crediting HIP graphs for a claimed ~10× gain over an undisclosed baseline), attributed to a June 2026 InferenceX result. A follow-up dive traced this to primary source: the actual InferenceX benchmark is MI355X-specific — MI350X is not an InferenceX-benchmarked SKU at all, so DigitalOcean's "MI350X/MI355X" phrasing is marketing shorthand, not a second distinct result. The underlying InferenceX article (ISL 8192/OSL 1024, single MI355X 8-GPU node) independently confirms the headline is genuinely reproducible progress — 2,256 aggregate tok/s/GPU at 9.4 generated tok/s/user on 2026-05-21, a 110.5× gain over the 2026-04-25 first-light point — and specifically describes extending the concurrency sweep to 1,024 as drawing out "the high-throughput, low-interactivity end of the frontier." That confirmed mechanism means DigitalOcean's later 3,500+ figure, from that same low-interactivity end of the curve, should not be read as an interactive per-user generation rate. A more granular generated-throughput/TTFT split and a derived TensorWave $/M-output cost proxy also appeared in the same dive, but they came from a GPT-5.6 Pro run that hit a 120-minute hard timeout and returned only a reasoning-summary with no pinned source URLs; those exact figures could not be independently verified against InferenceX's chart-rendered data, are shown nowhere on this page, and are excluded from the analysis pending source recovery. This remains a third-party deployment of the open-weight model, not DeepSeek's own production fleet, so it still does not close the "V4 production throughput" known-unknown above. (Full AMD inference-economics dive (partial) →)

Why no current scenario range is shown: a range for this replay has not been derived on the current $0.66/$1.98 tariff (the earlier one is in the changelog). The method scales the disclosed 2025 baseline by two unknown factors — hardware-hour cost (0.5–1.1× the old basis) and per-token work for the bigger-but-sparser V4 (1.05–1.5×) — which compound to a 3× cost span. Would update on: a V4-era serving disclosure (the 2025 one set the standard), realized peak-surcharge data after mid-July, or fleet-mix reporting.

Reach these operating points in the calculator: Reproduce this card ↑ (dive replay) · DeepSeek Feb-2025 disclosure replay ↑ (≈87%, on R1) · Ant-informed H20 scenario ↑ (live 649 tok/s/GPU on R1; no SLO enforcement) · China public-cloud on-demand lens ↑ (on R1)

Full GPT-5.6 Pro report →

Zhipu / Z.ai — current estimate for the selected model, GLM-5.3: serving margin ~74% at list price (GPT-6 Astra Pro's central inputs worked through this calculator; one research run, 2026-09-25; its low- and high-margin scenarios ~36%–~82%). The selected model's margin, not a provider-wide margin.

Reach this estimate's operating point in the calculator: Reproduce this estimate ↑ (Astra Pro's central inputs) · its card in Astra Pro estimates ↓ · its GPT-6 Astra Pro review →

What differs from the July dive. These are the inputs the two estimates set differently; the two numbers are not a like-for-like comparison.

model size: July 40B active / 744B total, fp8 · now 40B active / 753B total, fp8
list price: July $1.40/$4.40 per million tokens, cached input 19% · now $1.40/$4.40 per million tokens, cached input 18.6%
fleet and hour cost: July Ascend 910C 40% at $3.70/h · H800 (China) 40% at $3.32/h · H20 (China) 20% at $1.56/h · now Ascend 910C 100% at $2.20/h
utilization: July 75% · now 65%
serving-stack efficiency: July 0.60× — no recorded source · now 1.0×
traffic: July 15:1 input:output, 60% cache hits · now 10:1 input:output, 60% cache hits

July 2026 dossier — GLM 5.2, one GPT-5.6 Pro deep dive (2026-07-09). The dive's own reading: 60% (35–77%). The card below shows this calculator's replay of that dive today; its evidence profile describes the July model. The dive's band is historical and is not an interval around either number. Read with its dated correction: the card's sentence on the −153% it carried until 2026-09-20 names a tariff Zhipu had replaced, but the row's tariff did not change (corrected 2026-10-06); the move came from the traffic profile alone.

Zhipu / Z.ai — GLM 5.2 serving margin ~31% (activated dive replay; no current analyst range is supplied; all 3 of 3 declared fleet legs fit their declared serving setup; every leg batch-capped and policy-unclean) evidence: mixed

Evidence profile — architecture: high · pricing: high · fleet & TCO: low · production throughput: low · financial perimeter: high

Metric: blended serving margin at list price · lens: audit-implied procurement haircut (dive: 1.9× rent, 75% utilization, 0.60 stack) · traffic: Reference 15:1 I/O / 60% cache hits — the convention this replay actually computes on since the 2026-09-19 traffic-default change; the site-assumed 8:1 I/O + ncode-week 41% cache observation it opened on is historical. Provider-native case — not cross-provider comparable.

The rare provider with audited numbers: Zhipu's Hong Kong listing (Jan 2026) forces disclosure nobody else makes. Its cloud/API segment ran a −0.4% gross margin in H1 2025 (price-war casualty) recovering to 18.9% for FY2025. The activated dive replay does not reproduce the earlier mid-50s price-only counterfactual: it lands at ~31% blended at list price — the figure on this card's face — with all three fleet legs numerically renderable only after being capped to substantially smaller batches; the −153% this sentence carried until 2026-09-20 was computed on a tariff Zhipu had replaced and on an 81,000-token average-input traffic profile belonging to a different deployment, and both were corrected in that release; all three are policy-unclean, so the number is not a policy-clean result. Corrected 2026-10-06: the row's tariff ($1.40/$4.40, cached input 19%) did not change on 2026-09-19; the move came from the traffic profile alone. The architecture is fully disclosed (744B/40B, open weights), and third-party reseller prices give a conditional cost ceiling (valid only if the reseller serves at positive contribution margin — the same conditionality noted on the Kimi card): DeepInfra sells GLM-5.2 below Z.ai's own list.

Known knowns (top 3 — full ledger in the grounding ledger and dive)

GLM-5.2: 744B/40B, BF16+FP8 open checkpoints, 1M context (disclosed)
List: $1.40 / $0.26 cached / $4.40 out (disclosed)
Audited FY2025: cloud/API revenue RMB 190.4M at 18.9% GM (H1: −0.4%); company net loss RMB 4.7B (HKEX filings)

Known unknowns (top 3)

Traffic share by chip platform — nine named, zero percentages
The confidential compute-service rate — with decode throughput, the dominant drivers (public Chinese card-hour prices span >4×)
Coding Plan consumption distribution — claimed 15–30× (even "~100×") API-value leverage vs actual breakage

Why the historical dive used a 35–77% scenario range (not recalculated around the current ~31% shared-engine replay): decode throughput and the confidential compute price each move the answer ±10–20 points; the audited 18.9% segment-margin anchor and the conditional reseller price ceiling are what keep the interval from being wider still. Would update on: the H1 2026 interim filing (does cloud/API GM keep climbing from 18.9%?), any platform-share disclosure, or reseller-economics evidence.

Reach this operating point in the calculator: Reproduce this card ↑ (§10 dive replay)

Full GPT-5.6 Pro report →

Moonshot — current estimate for the selected model, Kimi K3: serving margin ~88% at list price (GPT-6 Astra Pro's central inputs worked through this calculator; one research run, 2026-09-25; its low- and high-margin scenarios ~77%–~92%). The selected model's margin, not a provider-wide margin.

From 2026-10-06 this section leads with a blended margin for Kimi K3. The July card keeps its output-token margin for Kimi K2.7 Code (~85%); on a blended basis, at its assumed 8:1 traffic with 40% cache hits, the same replay computes ~75%. Different metrics and different models — not a change in Moonshot's margin.

Reach this estimate's operating point in the calculator: Reproduce this estimate ↑ (Astra Pro's central inputs) · its card in Astra Pro estimates ↓ · its GPT-6 Astra Pro review →

What differs from the July dive. These are the inputs the two estimates set differently; the two numbers are not a like-for-like comparison.

model size: July 32B active / 1000B total, fp8 · now 104B active / 2800B total, fp4
list price: July $0.95/$4.00 per million tokens, cached input 20% · now $3/$15 per million tokens, cached input 10%
fleet and hour cost: July H800 (China) 70% at $1.75/h · H20 (China) 30% at $0.82/h · now H800 (China) 100% at $2.20/h
utilization: July 60% · now 65%
serving-stack efficiency: July 0.83× · now 1.0×
traffic: July 8:1 input:output, 40% cache hits · now 12:1 input:output, 70% cache hits

July 2026 dossier — Kimi K2.7 Code, one GPT-5.6 Pro deep dive (2026-07-09). The dive's own reading: 81% (55–91%), output-token. The card below shows this calculator's replay of that dive today; its evidence profile describes the July model.

Moonshot — Kimi K2.7 Code output-token margin ~85% OUTPUT-TOKEN margin (scenario range 55–91%; uncalibrated; all 2 of 2 declared fleet legs fit their declared serving setup) evidence: medium

Evidence profile — architecture: high · pricing: high · fleet & TCO: low · production throughput: medium · financial perimeter: low

Metric: output-token margin at list price, not blended (a blended margin needs Moonshot's undisclosed traffic mix) · lens: dive replica (H200-class decode floor, their stack) · traffic: n/a for the output metric; the calculator's blended headline uses the Kimi dive mix 8:1 / 40%. Provider-native case — not cross-provider comparable.

An output-token margin, not blended — so despite its large headline it cannot be ranked against DeepSeek’s and Zhipu’s blended figures. K2.7 kept a premium output price ($4.00/M — 2.02× DeepSeek V4 Pro's current $1.98 off-peak output price) on a 1T-total, 32B-active, selectively INT4 architecture. The activated calculator does not implement that component-level INT4 layout: its Kimi preset uses the global FP8 tuple as a sensitivity surrogate, so the ~85% headline on this card's face must not be read as an exact open-checkpoint reconstruction. A reproducible 128×H200 benchmark still supplies an external short-context decode-accelerator floor at ~$0.21/M output, while SemiAnalysis's same-lineage runs span $0.14–$1.00/M by hardware and speed.

Known knowns (top 3 — full ledger in the grounding ledger and dive)

K2.7 Code / K2.6: 1T total, 32B active, 384 experts, 256K context; selective weight-only INT4 (595GB); no native MTP (disclosed, open config)
List: $0.95 / $0.19 cached / $4.00 out; HighSpeed exactly 2× price for 5–6× user speed; batch = 60% of standard (disclosed)
Reproducible K2 decode floor ~$0.21/M output (128×H200); same-lineage cost curves $0.14–$1.00/M (LMSYS, SemiAnalysis)

Known unknowns (top 3)

Current accelerator mix — A800/H800 verified only historically; H20/Ascend production use unproven
Production throughput/batching at their latency target — the dominant driver (32→90 tok/s/user alone moves cost 2.4×)
Owned-vs-rented split and effective GPU-hour basis (China retail proxies $1.01–$2.01/hr)

Why the scenario range is 55–91%: the open weights pin the architecture but not the deployment — per-user speed targets and the actual fleet each move serving cost 2–3×; the $0.21 decode floor and the $3.50 reseller price bracket the answer from both sides. Note this is an output-token margin; a blended margin needs Moonshot's undisclosed traffic mix. Would update on: a K2.7-specific serving benchmark, any fleet disclosure, or revenue-mix updates against the >$300M ARR report.

Reach this operating point in the calculator: Reproduce this card ↑ (output-token dive replay)

Full GPT-5.6 Pro report →

Astra Pro estimates

One GPT-6 Astra Pro research run per model (September 2026), each given this calculator's input contract and asked to set every input — model size, price, traffic, fleet, accelerator-hour cost, utilization — from public evidence. Each run has its own review page, linked from its card. Claude Sonnet 5.5 (launched that day) and GPT-6 Sol (released six days earlier) were added on 2026-09-28: more of their inputs are carried over from a sibling model's estimate or assumed outright, their review pages say which, and their spans are wider for it. GPT-6.1 Sol, GPT-6 Sol's successor (released 2026-09-29), was added the same way on 2026-10-01, from a run made that day rather than in September, with the GPT-6 Sol estimate as its starting point.

These are estimates by an AI research run, worked through this calculator, in the same form as the two Opus 4.x estimates at the top of the report: a central reading at list price and its author's low and high scenarios. The number on each card is this calculator's result on the run's own inputs, recomputed from the recorded inputs, with the figure the run itself stated printed inside the card. They are modeled serving margins from public information — not provider disclosures and not company gross margins — and each rests on its own traffic mix, fleet and cost assumptions, stated in its card. The cards are grouped by provider in a fixed order; they are not a ranking.

One research run per model, worked through this calculator dot = this calculator on the run's central inputs · bar = the run's own low- and high-margin scenarios · grouped by provider, not ranked · each model on its own traffic, fleet and costs

Anthropic — Claude Fable 5.1 serving margin ~84% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 68%–90%)

Estimated by GPT-6 Astra Pro, one research run on 2026-09-25. Its own stated reading: 84.3% (68.4–90.3%).

What decides it, in its own words: The decisive assumption is 400B active parameters; Anthropic has not published that number.

Metric: blended serving margin at list price (claude-fable-5-1) · traffic: 50:1 input:output, 92% cache hits · fleet: GB200 NVL72 30% at $5.00/h · GB300 NVL72 20% at $6.50/h · TPU v7 Ironwood 50% at $1.50/h · utilization: 65% · model: 400B active / 8000B total, fp8. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~89%.

Carrier: the calculator's blank custom row on the dsr1 attention geometry (a declared approximation — this model's architecture is not published).

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

Anthropic — Claude Opus 5.5 serving margin ~78% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 68%–84%)

Estimated by GPT-6 Astra Pro, one research run on 2026-09-25. Its own stated reading: 78.5% (67.9–84.0%).

What decides it, in its own words: The estimate turns on an assumed 200B active parameters—not a disclosed Opus 5.5 size.

Metric: blended serving margin at list price (claude-opus-5-5) · traffic: 30:1 input:output, 85% cache hits · fleet: H200 10% at $3.50/h · GB200 NVL72 35% at $5.00/h · GB300 NVL72 20% at $6.00/h · TPU v7 Ironwood 35% at $2.70/h · utilization: 65% · model: 200B active / 2500B total, fp8. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~80%.

Carrier: the calculator's blank custom row on the dsr1 attention geometry (a declared approximation — this model's architecture is not published).

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

Anthropic — Claude Sonnet 5 serving margin ~84% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 74%–89%)

Estimated by GPT-6 Astra Pro, one research run on 2026-09-25. Its own stated reading: 83.5% (74.0–88.8%).

What decides it, in its own words: The deciding assumption is 100B active parameters, putting modeled serving cost near $0.23 per million mixed tokens.

Metric: blended serving margin at list price (claude-sonnet-5) · traffic: 12:1 input:output, 75% cache hits · fleet: H100 SXM 5% at $2.50/h · H200 15% at $3.80/h · GB200 NVL72 25% at $5.00/h · GB300 NVL72 5% at $6.50/h · TPU v7 Ironwood 50% at $2.70/h · utilization: 70% · model: 100B active / 1000B total, fp8. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~81%.

Carrier: the calculator's blank custom row on the dsr1 attention geometry (a declared approximation — this model's architecture is not published).

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

Anthropic — Claude Sonnet 5.5 serving margin ~84% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 62%–90%)

Estimated by GPT-6 Astra Pro, one research run on 2026-09-28. Its own stated reading: 83.9% (62.4–89.9%).

What decides it, in its own words: The deciding assumption is 100B active parameters, giving modeled serving cost of about $0.225 per million mixed tokens.

Metric: blended serving margin at list price (claude-sonnet-5-5) · traffic: 12:1 input:output, 75% cache hits · fleet: H100 SXM 5% at $2.50/h · H200 15% at $3.80/h · GB200 NVL72 25% at $5.00/h · GB300 NVL72 5% at $6.50/h · TPU v7 Ironwood 50% at $2.70/h · utilization: 65% · model: 100B active / 1000B total, fp8. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~81%.

Carrier: the calculator's blank custom row on the dsr1 attention geometry (a declared approximation — this model's architecture is not published).

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

Anthropic — Claude Haiku 4.5 serving margin ~73% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 54%–85%)

Estimated by GPT-6 Astra Pro, one research run on 2026-09-25. Its own stated reading: 73.4% (54.4–84.5%).

What decides it, in its own words: Latency-oriented serving (interact: "fast") limits batch amortization; balanced serving would add about 16 margin points.

Metric: blended serving margin at list price (claude-haiku-4-5-20251001) · traffic: 8:1 input:output, 50% cache hits · fleet: H200 40% at $3.25/h · GB200 NVL72 20% at $5.00/h · TPU v7 Ironwood 40% at $2.40/h · utilization: 65% · model: 20B active / 200B total, fp8. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~72%.

Carrier: the calculator's blank custom row on the dsr1 attention geometry (a declared approximation — this model's architecture is not published).

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

OpenAI — GPT-6 Astra serving margin ~95% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 89%–97%)

Estimated by GPT-6 Astra Pro, one research run on 2026-09-25. Its own stated reading: 94.6% (89.5–96.7%).

What decides it, in its own words: The deciding assumption is 200B active parameters, which puts modeled output serving cost near $1.85/M against the $50/M output tariff.

Metric: blended serving margin at list price (gpt-6-astra, current alias read 2026-09-25 UTC) · traffic: 12:1 input:output, 80% cache hits · fleet: H200 30% at $3.50/h · GB200 NVL72 50% at $4.50/h · GB300 NVL72 20% at $6.00/h · utilization: 70% · model: 200B active / 6000B total, fp8. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~93%.

Carrier: the calculator's blank custom row on the dsr1 attention geometry (a declared approximation — this model's architecture is not published).

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

OpenAI — GPT-6 Sol serving margin ~85% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 58%–92%)

Estimated by GPT-6 Astra Pro, one research run on 2026-09-28. Its own stated reading: 85.0% (57.8–91.6%).

What decides it, in its own words: The unmeasured 100B-active assumption puts modeled output cost near $1.08/M against the $10/M output tariff.

Metric: blended serving margin at list price (gpt-6-sol, current alias read 2026-09-28) · traffic: 12:1 input:output, 80% cache hits · fleet: H200 30% at $3.50/h · GB200 NVL72 50% at $4.50/h · GB300 NVL72 20% at $6.00/h · utilization: 70% · model: 100B active / 5000B total, fp8. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~82%.

Carrier: the calculator's blank custom row on the dsr1 attention geometry (a declared approximation — this model's architecture is not published).

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

OpenAI — GPT-6.1 Sol serving margin ~84% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 42%–91%)

Estimated by GPT-6 Astra Pro, one research run on 2026-10-01. Its own stated reading: 84.1% (41.9–91.1%).

What decides it, in its own words: The carried, unmeasured 100B-active assumption keeps modeled output cost near $1.08/M against the $10/M output tariff.

Metric: blended serving margin at list price (gpt-6.1-sol, current API alias as read 2026-10-01) · traffic: 12:1 input:output, 80% cache hits · fleet: H200 30% at $3.50/h · GB200 NVL72 50% at $4.50/h · GB300 NVL72 20% at $6.00/h · utilization: 70% · model: 100B active / 5000B total, fp8. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~81%.

Carrier: the calculator's blank custom row on the dsr1 attention geometry (a declared approximation — this model's architecture is not published).

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

OpenAI — GPT-5.6 Terra serving margin ~91% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 81%–94%)

Estimated by GPT-6 Astra Pro, one research run on 2026-09-25. Its own stated reading: 90.8% (80.6–94.5%).

What decides it, in its own words: The decisive assumption is 60B active parameters: a moderately sparse workhorse, not a price-derived fraction of Sol.

Metric: blended serving margin at list price (gpt-5.6-terra API alias as served 2026-09-25) · traffic: 8:1 input:output, 65% cache hits · fleet: H100 SXM 5% at $2.60/h · H200 25% at $3.40/h · GB200 NVL72 50% at $4.50/h · GB300 NVL72 20% at $6.00/h · utilization: 70% · model: 60B active / 1200B total, fp8. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~88%.

Carrier: the calculator's blank custom row on the dsr1 attention geometry (a declared approximation — this model's architecture is not published).

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

OpenAI — GPT-5.6 Luna serving margin ~66% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 36%–76%)

Estimated by GPT-6 Astra Pro, one research run on 2026-09-25. Its own stated reading: 65.7% (36.1–76.5%).

What decides it, in its own words: The assumed dsr1 attention/KV geometry sets a substantial decode-cost floor, even at 12B active parameters.

Metric: blended serving margin at list price (gpt-5.6-luna) · traffic: 8:1 input:output, 60% cache hits · fleet: H100 SXM 20% at $2.60/h · H200 30% at $3.25/h · GB200 NVL72 50% at $4.50/h · utilization: 70% · model: 12B active / 160B total, fp8. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~45%.

Carrier: the calculator's blank custom row on the dsr1 attention geometry (a declared approximation — this model's architecture is not published).

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

Google — Gemini 3.8 Flash serving margin ~92% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 72%–94%)

Estimated by GPT-6 Astra Pro, one research run on 2026-09-25. Its own stated reading: 92.2% (72.4–94.3%).

What decides it, in its own words: The decisive cost assumption is $1.20 per all-in owned-TPU-equivalent chip-hour, rather than Google Cloud’s retail rental rate.

Metric: blended serving margin at list price (gemini-3.8-flash) · traffic: 8:1 input:output, 50% cache hits · fleet: TPU v7 Ironwood 100% at $1.20/h · utilization: 70% · model: 30B active / 600B total, fp8. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~91%.

Carrier: the calculator's blank custom row on the qwen3c attention geometry (a declared approximation — this model's architecture is not published).

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

Google — Gemini 3.1 Pro serving margin ~92% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 84%–94%)

Estimated by GPT-6 Astra Pro, one research run on 2026-09-25. Its own stated reading: 91.6% (83.8–93.9%).

What decides it, in its own words: An inferred $1.36 all-in owned-TPU chip-hour—not Google Cloud’s $5.40 resale tariff—carries the result.

Metric: blended serving margin at list price (gemini-3.1-pro-preview) · traffic: 8:1 input:output, 40% cache hits · fleet: TPU v7 Ironwood 100% at $1.36/h · utilization: 70% · model: 100B active / 2000B total, fp8. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~91%.

Carrier: the calculator's blank custom row on the dsr1 attention geometry (a declared approximation — this model's architecture is not published).

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

xAI — Grok 4.6 serving margin ~81% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 66%–89%)

Estimated by GPT-6 Astra Pro, one research run on 2026-09-25. Its own stated reading: 80.9% (65.9–89.2%).

What decides it, in its own words: The decisive assumption is owned Blackwell capacity costing $2.10–$2.50 per accelerator-hour, all-in—not public-cloud rental prices.

Metric: blended serving margin at list price (grok-4.6) · traffic: 8:1 input:output, 60% cache hits · fleet: GB200 NVL72 50% at $2.10/h · GB300 NVL72 50% at $2.50/h · utilization: 65% · model: 200B active / 1500B total, fp8. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~80%.

Carrier: the calculator's blank custom row on the dsr1 attention geometry (a declared approximation — this model's architecture is not published).

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

DeepSeek — DeepSeek V4.1-Flash serving margin ~59% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 36%–67%)

Estimated by GPT-6 Astra Pro, one research run on 2026-09-25. Its own stated reading: 58.8% (35.6–66.5%).

What decides it, in its own words: The decisive input is $1.60 per all-in H800-equivalent hour, not a hyperscaler rental rate.

Metric: blended serving margin at list price (deepseek-flash -> DeepSeek-V4.1-Flash, released 2026-09-10) · traffic: 8:1 input:output, 60% cache hits · fleet: H800 (China) 100% at $1.60/h · utilization: 100% · model: 16B active / 763B total, fp4. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~45%.

Carrier: the calculator's blank custom row on the dsr1 attention geometry (a declared approximation — this model's architecture is published but matches no stated row).

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

Alibaba — Qwen3.8-Max serving margin ~79% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 72%–88%)

Estimated by GPT-6 Astra Pro, one research run on 2026-09-25. Its own stated reading: 79.2% (71.8–88.3%).

What decides it, in its own words: An assumed $3.26 all-in GB300-equivalent GPU-hour is the decisive input.

Metric: blended serving margin at list price (qwen3.8-max-0902 (alias qwen3.8-max-2026-09-02), released 2026-09-02) · traffic: 8:1 input:output, 60% cache hits · fleet: GB300 NVL72 100% at $3.26/h · utilization: 65% · model: 95B active / 2400B total, fp8. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~78%.

Carrier: the calculator's blank custom row on the qwen3c attention geometry (a declared approximation — this model's architecture is published but matches no stated row).

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

Moonshot AI — Kimi K3 serving margin ~88% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 77%–92%)

Estimated by GPT-6 Astra Pro, one research run on 2026-09-25. Its own stated reading: 87.8% (76.6–91.9%).

What decides it, in its own words: The decisive assumption is $2.20 per all-in H800-equivalent accelerator-hour, not a disclosed Moonshot procurement rate.

Metric: blended serving margin at list price (kimi-k3) · traffic: 12:1 input:output, 70% cache hits · fleet: H800 (China) 100% at $2.20/h · utilization: 65% · model: 104B active / 2800B total, fp4. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~85%.

Carrier: the calculator's blank custom row on the dsr1 attention geometry (a declared approximation — this model's architecture is published but matches no stated row).

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

Zhipu — GLM-5.3 serving margin ~74% (this calculator on Astra Pro's central inputs, at list price; its low- and high-margin scenarios: 36%–82%)

Estimated by GPT-6 Astra Pro, one research run on 2026-09-25. Its own stated reading: 74.5% (35.6–81.9%).

What decides it, in its own words: The deciding input is interact: "balanced": the calculator’s shared-batch throughput, rather than its low-batch fast posture, carries the headline.

Metric: blended serving margin at list price (glm-5.3, first-party metered text API, reasoning_effort=max) · traffic: 10:1 input:output, 60% cache hits · fleet: Ascend 910C 100% at $2.20/h · utilization: 65% · model: 40B active / 753B total, fp8. Its own operating point — not cross-model comparable. At the page's Reference traffic (15:1, 60% cache) and list price, the same inputs compute ~70%.

Carrier: the stated geometry of the site's glm row (GLM 5.2 (744B/40B)), with every magnitude, price, fleet and traffic input from this run.

Reach this operating point in the calculator: Reproduce this card ↑ (Astra Pro's central inputs)

Full GPT-6 Astra Pro review →

Method note: X posts located and quoted via a Grok 4.5 agent sweep (2026-07-09); hardware/TCO data via Parallel deep research + Exa across SemiAnalysis, MLCommons, NVIDIA/Google/AWS primary pages; cross-model verification via an independent GPT-5.6 Pro research run. The per-provider audits in §10 come from one dedicated GPT-5.6 Pro deep dive per provider plus two Chinese-accelerator hardware sweeps (all 2026-07-09, archived in the research annex; provenance headers condensed for public release, conclusions unchanged). Attributions (the direction of the Musk leak, the ncode/Noumena identification) were verified against primary posts; where the research engines disagreed, both readings are shown rather than harmonized. Model sizes for closed models remain estimates — the calculator exists so you can disagree with a slider instead of a screenshot.

Feedback

Feedback on this public research page — not a support channel; please don't submit sensitive personal data. Submissions are reviewed manually and periodically purged.