One baseline. Everything else reconciles to it.

Methodology

How we build the numbers, where they come from, and how confident we are.

The AI Ledger tracks the AI industry through five interlocking ledgers. The Capital Ledger follows how much is being spent to build AI infrastructure — semiconductors, data centres, networking. The Revenue Ledger tracks what comes back — who earns what from selling AI products and services. The Compute Ledger follows who sells AI compute and what it earns. The Usage Ledger estimates actual consumption — tokens processed, models served, inference volume. The Power Ledger accounts for the electricity required to serve it all. Together they answer: how much is going in, how much is coming out, who provides the compute, how much is being used, and can the grid supply it?

Per-ledger methodology

Compute revenue — three-segment model and principal/agent gate

The Compute Ledger decomposes hyperscaler + neocloud AI revenue into three segments so the page can publish the right number for the right question. Headline aggregates are post-Copilot. Copilot-class revenue is per-seat productivity SaaS, scoped to a future Apps Ledger.

Three-segment model (naming locked 06/05/2026)

• Frontier lab compute. Money frontier model labs (OpenAI, Anthropic, Mistral, Cohere, smaller labs) pay external compute providers (hyperscalers, neoclouds) to train and serve their own foundation models. Estimated bottom-up from per-lab revenue × cloud-mix (e.g. OpenAI ~80% Azure, Anthropic ~60% AWS / ~30–40% GCP TPUs). Some hyperscalers also hold equity stakes in the model labs they bill, which is why this line is sized and surfaced separately rather than netted into a single Compute number. Strict definition: only external lab → hyperscaler flows count. Internal compute — e.g. Google running Gemini training on Google Cloud, or Meta running LLaMA on its own datacentres — contributes $0. ~$36B 2025.
• AI workload compute. AI-Native customers (running open or own models), enterprises (running internal AI workloads), model-serving infrastructure cos, and sovereign/regulated workloads buying raw cloud GPU/instance capacity. Residual after Frontier lab compute + Copilot deduction. ~$5B 2025.
• Hosted model APIs. Bedrock + Azure OpenAI Service + Vertex partner-served — packaged token APIs, the cloud-margin leg of frontier-model resale. Pass-through to model labs applies here only. ~$4.5B gross 2025; ~$1B pass-through.

Pass-through rule. Pass-through is the lab rev-share applied to Hosted model APIs, not to total AI revenue. An earlier version of this page applied the pass-through percentage to gross AI revenue and reported ~$11.5B for 2025. That overstated it by roughly 10×. Most hyperscaler AI revenue is direct compute spend (Frontier lab and AI workload) rather than token-API resale. Corrected pass-through is ~$1B for 2025, and corrected net ~$44.5B, on the sum-of-quarterlies post-Copilot basis with the segment sizing set out below.

Copilot scope-out rule. M365 Copilot, GitHub Copilot, Copilot Studio (MSFT); Gemini-in-Workspace SKUs (GOOGL); equivalent embedded-AI-feature productivity lines elsewhere. These are per-seat SaaS, not Compute. They are deducted from each provider's disclosed AI line, and the deduction is published alongside it. They flow to a future Apps Ledger when that is built; until then they are tracked but not published on the Compute page. AWS does not have a named productivity Copilot line; default deduction is 0 unless a specific embedded-AI line is identifiable in the 10-Q. Scope-out uses MS-declared values (not TAIL-derived) so the deduction matches what is in the reported AI run-rate.

Principal/agent verification gate. Before publication, the revenue recognition policy notes from the most recent 10-K are read for AWS, MSFT (Azure), GOOGL (Cloud), and ORCL (OCI). For each, principal (gross) vs. agent (net) treatment under ASC 606 is confirmed. All four reviewed entities use principal treatment for AI reseller arrangements (verified 06/05/2026, and recorded beside the published figures). Treatment is re-verified each cycle as 10-Ks are refiled.

Direct frontier-API revenue sits outside Compute. When Bedrock resells Claude, AWS keeps the cloud margin (Compute, Hosted model APIs net); Anthropic gets the rest (Model revenue). When a customer calls Anthropic directly, 100% is Model revenue with the underlying compute showing on AWS/GCP P&Ls as Frontier lab compute. This avoids ecosystem-level double-counting between Compute and Apps/Model Revenue.

Segment sizing (locked 06/05/2026)

Sizing was previously done with editorial AI-share weights — AWS AI taken as 15% of AWS revenue, and so on. Since 06/05/2026 each provider's AI line has been built bottom-up from its own segments instead. Approach by provider:

• Microsoft Azure AI ($28B 2025). Holds. Microsoft's self-disclosed run-rate basis is the tightest of the four ($37B Q1 2026 annualised, +123% YoY). Frontier lab compute $18B (OpenAI ~80% Azure-resident); Hosted model APIs $1.5B (Azure OpenAI Service to enterprise — bottom-up at realistic token volumes); AI workload compute $1.1B; Copilot $7.4B (MS-declared seat-math: 15M paid M365 Copilot seats × $30/mo × 12 + GitHub Copilot $1.65B + sundry).
• AWS AI ($10B 2025). Restated downward from $18B per Andy Jassy's 2026 shareholder letter disclosure of "$15B annualised AI run rate" Q1 2026 (Tier 1B CEO disclosure). Walking back to 2025 calendar via observed Anthropic growth shape: Q1 ~$1.5B, Q2 ~$2B, Q3 ~$2.75B, Q4 ~$3.5B. Frontier lab compute $7B (Anthropic on AWS infra ~$5–6B + minor labs $1–2B); Hosted model APIs $2.5B (Bedrock); AI workload compute $0.5B residual.
• Google Cloud AI ($7B 2025). Restated downward from $18B per bottom-up build (no discrete GCP AI revenue figure disclosed). Anchored on Q2 2025 commentary "13 product lines now exceed $1B run-rate" — if 4–5 are AI-driven (Vertex AI Platform, Gemini API, AI Hypercomputer, AI agent/search products, AI-driven analytics) at $1.0–1.5B mid-2025 each, calendar 2025 lands $6–8B central $7B. Frontier lab compute $3.5B (Anthropic on TPUs $1.5–2B + OpenAI on GCP $0.5–1B partial-year + Mistral/Cohere/AI21 ~$1B); Hosted model APIs $0.5B (Vertex partner-served); AI workload compute $1.5B; Copilot $1.5B (Gemini-in-Workspace external Apps revenue, MS-declared analogue).
• Oracle OCI AI ($3B 2025). Holds. Frontier lab compute $2B (OpenAI Stargate partial-year billings as DC capacity comes online); AI workload compute $1B; no Hosted model APIs; no Copilot.
• Neoclouds (CoreWeave + Nebius + Lambda + Crusoe = $6.45B 2025). Holds aggregate. CoreWeave $4.5B is ~85% Microsoft-sub-rent (much of which is OpenAI workload — captured separately under Microsoft's Frontier lab compute line as the same flow under different ASC 606 principal-treatment legs). Smaller neoclouds: Mistral, Cohere, smaller labs.

The Anthropic equity gain on Alphabet's Q1 2026 P&L ($36.9B) is investment income, not Cloud operating revenue (per Fortune, 30/04/2026), and does not inflate the GCP AI line. The CoreWeave figure includes ~$3.8B of Microsoft-sub-rented capacity that is also recognised as AWS / Azure compute revenue elsewhere; under each entity's revenue-recognition policy both legs are real revenue lines on each company's P&L, so the ecosystem total is gross of that overlap by definition. We surface it separately rather than try to net it out at the Compute layer.

Calendar basis: the sum of four reported quarters (locked 06/05/2026)

For each provider, the 2025 calendar AI line is published on a sum-of-quarterlies basis — the four reported (or derived) 2025 quarterly AI revenues summed. We chose this over the alternative annualised run-rate basis (year-end exit run-rate × 4), even where the run-rate number is the figure CEOs prefer to disclose. Why: in a year of accelerating growth, sum-of-Q is materially smaller than annualised. Microsoft's 2025 calendar AI is $25.25B sum-of-Q against $28B annualised exit, a gap of about 10%; Amazon and Google sum-of-Q ≈ annualised because their growth shape doesn't diverge as much. If the trajectory chart anchored Q1 2026 at $9.25B (= disclosed $37B run-rate ÷ 4) but forced the four 2025 quarters to sum to $28B, Q4 2025 would have to balloon above $9.25B, producing a visible quarter-on-quarter drop into Q1 2026 that contradicts the +123% year-on-year growth.

On this basis every major provider's quarterly trajectory rises into Q1 2026 without a false dip. The annualised run-rate figure is not lost. It is kept beside each provider as context. The layer stack and the trajectory chart both use the sum of the four quarters.

Cohort vs ecosystem Apps Revenue — Layer Stack basis

The Layer Stack visual on /compute publishes cohort Apps Revenue (the Revenue Ledger's total customer revenue, ~$17.36B as at 06/05/2026), not an editorially-extended ecosystem total. An earlier version used a Tier 2A 5× multiplier ($17.4B → $100B) to bridge the cohort to "enterprise SaaS AI ARR". That multiplier had no provenance trail, and the ratio swung ±25% on a single editorial constant. The corrected page shows the cohort number as-is and flags the cohort-vs-ecosystem gap as a future-Apps-Ledger scope. All four Layer Stack layers are on lookback 2025 actuals on the same time-basis (sum-of-quarterlies for compute, FY26 calendar 2025 for silicon) so the multipliers between layers are apples-to-apples.

Revenue Ledger — entity archetype taxonomy

The Revenue Ledger Sankey routes per-entity revenue across channels (Model Subs / Model API / Hyperscalers / AI Native Apps / Trad. SaaS) and into buyer segments (Consumer / AI Natives / Enterprises & Govs / VC-Investors). Until 06/05/2026 the routing applied a flat 70/30 Model API / Hyperscalers split to every provider's API revenue. That weighting is roughly right for enterprise customers (who buy Bedrock / Azure OpenAI / Vertex for compliance and procurement) but wrong for AI Natives. Cursor, Glean, Perplexity and Harvey go ~95% direct to OpenAI or Anthropic, for cost and latency. Because the cohort is mostly AI Natives, the flat 30% Hyperscalers weight inflated the Hyperscalers channel to $3.63B. The flat split was replaced on 06/05/2026 with per-archetype weights, so each entity now routes through the channels its real customers use.

Every entity in the cohort is tagged with one archetype. The taxonomy:

The channel weights and the buyer-segment weights are both published in the underlying dataset. Each provider is tagged with its archetype, and the routing applies the matching weights. An untagged entity falls through to a conservative default of 15% Hyperscalers and 85% Model API on the API leg, and 50/50 on the enterprise leg. Under-counting the Hyperscalers channel is editorially safer than over-counting it.

Buyer relabel. The Who-Pays column previously showed Consumer / SME / Enterprise. SME conflated AI-native scale-ups (heavy API consumption, light headcount, no traditional SaaS revenue) with small businesses; the new buckets — Consumer / AI Natives / Enterprises & Govs / VC-Investors — name what sits on the demand side of the AI economy. Subscription revenue routes to Consumer; API revenue splits between AI Natives and Enterprises & Govs per archetype; enterprise contracts route to Enterprises & Govs.

Reconciliation against the Compute Ledger. On these weights the Revenue Ledger Hyperscalers channel lands at ~$1.7B (gross). After the 20% hyperscaler take-rate, that implies ~$1.36B of cohort lab revenue passing through Hyperscaler resale. That is comparable to the Compute Ledger Hosted-model-APIs pass-through (~$1B) within tier 2A noise. The remaining ecosystem Hosted-model-APIs gross (~$4.35B) covers non-cohort enterprise spend (Fortune 500 buying Bedrock / Azure OpenAI outside the 9-source cohort) and is documented on the Compute Ledger but out of scope for the Revenue Ledger cohort.

Cross-ledger reconciliation (set 07/05/2026)

Since 06/05/2026 any aggregate published on the site must be checked against the parallel figure on adjacent Ledgers. Where the two differ, the gap is closed by showing the bridge between them, never by quietly re-tuning a number. The three reconciliations below are published in full, so a reader can check each pair without working the bridge out for themselves.

(a) Forward commitments vs realised compute revenue

The Compute Ledger trajectory chart shows realised quarterly compute revenue (e.g. MSFT $9.25B in Q1 2026 — $37B run-rate ÷ 4). The Compute Ledger now also surfaces a separate Forward commitments block that reports the multi-year contracted order book — Google's RPO ($242.8B → $467.8B Q4 25 to Q1 26, +$225B QoQ), Anthropic's $200B five-year deal with Google, and the $741B Anthropic and OpenAI have together committed to compute providers (hyperscalers and neoclouds) in announced deals as at 31/07/2026, summed deal by deal; other neocloud contracts reported during 2026 and the totals reported from Anthropic’s draft S-1 are not yet included. These two views describe overlapping economic reality on different time bases. Bridge: contracted dollars convert into realised quarterly compute revenue over the contract life of each booking (typically 1–8 years); they are not Q1 26 revenue and would double-count if mixed into the trajectory bars. The trajectory chart and the forward-commitments block are reconciled by being kept on separate surfaces with the relationship explicit.

(b) Hyperscaler→lab investment vs realised capex

The Capital Ledger shows realised hyperscaler capex (cumulative 2023–25 ~$745B; 2025 calendar ~$380B). The Compute Ledger forward-commitments block also tracks hyperscaler→lab equity investment — Google→Anthropic cumulative ~$43B, Amazon→Anthropic cumulative ~$33B (incl. contingent), AWS→OpenAI Feb 2026 $13B + up-to $20B more. These dollars are not additive to capex: most of the equity round flows back to the same hyperscaler as compute commitment (Anthropic-Google $200B/5yr is funded in part by Google's equity into Anthropic). Bridge: equity investment is a separate balance-sheet line from PP&E capex and we do not add the two figures. The circular flow (hyperscaler equity into a lab, the lab's compute commitment back to the hyperscaler, and the capex realised over time) is reconciled by tagging each leg separately rather than presenting a single "AI investment" total.

(c) Copilot announced-vs-actual three-band structure

M365 Copilot's published 2025 number on TAIL was previously $5.4B ARR (15M paid seats × $30/mo × 12). The Azure billing leak reported by Zitron on 06/05/2026 put actual revenue an order of magnitude lower. On 07/05/2026 the published M365 Copilot number was restated as a three-band structure:

The published value on TAIL is $1.35B (leaked-actual midpoint), with list and bundling-adjusted bands carried as comparison context. Bridge to the Compute Ledger. The Compute Ledger's Copilot scope-out for 2025 ($6.67B) is Microsoft's own declared exclusion (what Microsoft leaves out of the Azure AI revenue line) and is on a different basis (list-billings level, includes M365 Copilot ~$5.4–7.2B + GitHub Copilot ~$1.65B + Studio/Sales/Service residual). The Trad. SaaS Apps Ledger view uses leaked actuals; the Compute Ledger uses MSFT's own scope-out. The two are not the same number and are no longer presented as though they were. The full bridge is published with the Compute Ledger's disclosures.

Why this matters. Before the restatement, the M365 Copilot $5.4B figure flowed through to the layer stack and to the Apps Revenue-to-Compute multiplier. The leaked-actual restatement reduces the published Copilot line by ~75% and increases the apparent spread between announced AI-product revenue and economically-realised AI-product revenue across the enterprise SaaS stack. That spread is now visible by design.

Power demand — three-method triangulation

The Power Ledger publishes a forward demand curve from 2026 to 2030 and a supply pipeline of named, dated builds. The demand curve is the part that needs methodology, because no single source measures global AI power demand directly. It has to be inferred. Three independent methods are run side-by-side, and the variance between them is published as a health metric rather than hidden.

Method 1 — Anchored projection (primary)

The 2026 baseline is set from third-party published anchors (IEA Energy & AI, BloombergNEF and SemiAnalysis) at ~76 GW of AI-attributable data-centre IT load, with a range of ~64–88 GW. The published anchor is Tier 2B because it is a triangulation of independent measured estimates rather than a single first-party disclosure. Anchor sources are surfaced inline on the Power Ledger page; the full list is published with the demand model in the underlying dataset.

From the 2026 anchor, demand for each forward year grows along compute-spend growth divided by efficiency gain:

demand_T = anchor₂₀₂₆ × (compute_T / compute₂₀₂₆) × (efficiency₂₀₂₆ / efficiency_T)

The compute-spend track comes from the Compute Ledger (sum-of-quarterlies basis, post-Copilot). The efficiency track decomposes into hardware FLOPS-per-watt gains (Tier 2B, anchored on observed accelerator generation cadence) and software efficiency gains (Tier 2B–3A, modelled on observed tokens-per-FLOP improvements at the frontier-model level). The anchor is the absolute level; the chain provides relative growth. There is no tuning constant. The anchor ratios (Compute/Apps net, Compute/Apps gross, Silicon/Compute) are published with the demand model, together with the utilisation assumption and the power-overhead factor (PUE), which is the ratio of total facility power to the power reaching the servers.

Method 2 — Silicon shipments bottom-up

Independent of apps revenue. The silicon base is merchant silicon (NVIDIA Data Centre + AMD Instinct + custom AI ASIC + AI networking, ~$224B 2025, Tier 1A) uplifted by ~50% for hyperscaler internal accelerator fleets (Google TPU, AWS Trainium, Meta MTIA, Microsoft Maia — Tier 2B because internal fleet sizes are not publicly disclosed). Silicon dollars convert to GPU-equivalents using fleet average dollar-per-GPU, retire over a five-year asset life, then multiply by watts per GPU × power-usage-effectiveness × utilisation, and divide by the combined hardware-plus-software efficiency curve. The derived series is published with the demand model.

This method captures the silicon-attributable share of AI power. It deliberately under-counts ecosystem-wide AI power because it excludes data-centre overhead beyond that factor, ad-platform AI workloads not riding on merchant accelerators, and inference run on CPU-class hardware.

Method 3 — Operational tokens × FLOPs

Daily token volume multiplied by FLOPs per token and divided by FLOPs per watt yields the inference-power line. Training compute is added on top; training is FLOPS-saturated, so only hardware efficiency applies to it, while software-efficiency gains help inference. Forward growth tracks end-user usage rather than the infrastructure build-out, because token volume scales with how much people use AI, not with how much capacity is built.

This method's figures are not shown while it is re-run on the current token figures. Methods 1 and 2 are unaffected, and the published Power demand comes from Method 1.

Triangulation health

The three methods describe overlapping reality on different definitional scopes:

• Method 1 captures ecosystem-wide AI power, including hyperscaler internal workloads, ad-platform AI and data-centre overhead.
• Method 2 captures the silicon-attributable share only.
• Method 3 captures inference plus training on measured token volumes only.

Variance across the methods is tracked as a health check, stated against their median, and is not shown as a headline while Method 3 is being re-run. The gap is a cohort-versus-ecosystem definitional gap, not a model error. Shrinking it by quietly re-tuning one method to hit the others would defeat the point of running them independently.

Supply pipeline

Demand is one half; supply is the other. The interconnection-queue data, lead times, and named-project tables on the Power Ledger come from primary grid-operator and operator disclosures — EirGrid (Ireland), EMA (Singapore), AEMO (Australia), ERCOT (Texas), CAISO (California), and equivalents in Japan, Germany, the UK, the Netherlands, and the UAE. Every row in the queue, lead-time and announced-project tables carries its own provenance tier and retrieval date. The cumulative supply curve on the chart is built by stacking deployed capacity, projects under construction, announced projects, and queued projects, in that confidence order. The gap between supply and demand is the published page's headline finding rather than something the methodology smooths over.

ARR vs collected revenue — what each surface shows

The Ledger surfaces two distinct revenue measures for AI providers, and they are not interchangeable. Mixing them is the most common mistake when reading frontier-AI financials.

The two measures typically diverge by 5–6× for frontier model providers because ARR captures the latest quarter annualised (currently growing rapidly) while collected revenue captures the audited annual figure (which lags). For example, OpenAI's reported ARR was around $25B (Q1 2026 run-rate) while its 2025 collected revenue was around $4.3B. The same company, two different numbers, both correct for what they measure. The Ledger keeps both and labels each surface explicitly.

Year-keyed audited revenue (Anthropic's 2026 collected revenue at $6B, for example) surfaces in the timeline's FY revenue section rather than on the dashboard tile. That is an editorial choice. The dashboard tile carries run-rate only, because the dashboard answers "current state at run-rate". Audited year figures belong on the timeline, where the time orientation is explicit.

The three company surfaces — who appears where, and why

A company appears on one of three surfaces depending on what kind of company it is, because the same twelve columns cannot describe an AI application, a frontier lab and a GPU cloud. Each surface reads the same vault and each states its own basis.

Why the totals differ from the ledger totals

Both provider surfaces publish a figure that sits alongside one the Revenue Ledger already publishes, and each states its bridge on the page rather than leaving a reader to reconcile two numbers:

• Compute. Summing the provider table gives what these companies book between them. Subtracting the compute they buy from each other (frontier labs, applications and other compute providers) leaves the revenue paid in from outside, which is the figure the Revenue Ledger publishes. The compute page leads with that figure and shows the subtraction.
• Model providers. The profiled labs sum to less than the model's frontier total, because that total also carries labs whose figure has no dated, named source behind it. Those labs get no profile, and the difference is named on the page.

What keeps a company off a surface

A figure held in our records is not the same as a figure we can publish. Where a company's revenue is not traceable to a dated, named source, the company still appears, in a roster or with an explicit blank, and the reason is stated. A blank is a finding about the record, not a zero, and it is never filled with an estimate to complete a column. Where a company sells no such product at all, that is said plainly rather than rendered as $0.

How confidence is rendered

Every datapoint carries a single confidence value (High, Med or Low) and is rendered as one pill in the colour grammar shared with the Hepburn Advisory site.

This is a simplified surface signal. The richer provenance taxonomy below (1A through 4) is the underlying classification framework. Every datapoint is classified against that detailed scheme, then mapped down to the High / Med / Low pill that ships on the page. Splitting the two axes (provenance separate from confidence) is V1.1 work, deferred.

Tier classification (provenance taxonomy)

Every data point in the AI Ledger carries a provenance tier. This is the underlying classification. It tells you where the number came from and how much weight to give it. The single-axis pill above is derived from this.

Modelling principles

• Changelog discipline: Any revision to a published estimate triggers a changelog entry with the old value, new value, and reason for the change. No silent edits.
• Scenario parameters are authored, not computed: Bear, Base, and Bull scenarios use hand-picked growth rates and ratios (Tier 3C). They are editorial judgements, clearly labelled, not outputs of a forecasting model.
• Source hierarchy is enforced: Higher-tier data cannot be overwritten by lower-tier data. A Tier 1A filing always takes precedence over a Tier 3A projection. The system enforces this programmatically.
• Assumptions are documented: Every derivation step, growth rate, split ratio, and rounding decision is recorded in persistent assumption docs. If you can't trace a number back to its source, it gets flagged for review.
• Replace Tier 4 aggressively: Tier 4 (Editorial) values exist only as placeholders. They are the first priority for upgrade whenever new data surfaces.

Data sources

Primary sources used to construct the ledgers. Each source is classified by category, update frequency, and provenance tier.

What we don't claim

Transparency about our limits is part of the methodology. These are known gaps that we track but do not claim to have resolved:

• China-domestic usage below the top three: We track ByteDance, Baidu, and Tencent through public disclosures. Smaller Chinese labs and enterprise deployments are estimated, not measured.
• We don't audit inference cost claims: When providers disclose cost-per-token or margin data, we triangulate against known infrastructure costs. We don't have access to verify these claims directly.
• Private ARR for non-disclosing labs: Anthropic (pre-IPO), xAI, and others don't report revenue publicly. We use investor call commentary, court filings, and press reports — these carry Tier 1B or 2A confidence at best.
• Idle capacity carries ±20% uncertainty: No hyperscaler discloses GPU utilisation rates. Our idle estimates are residuals after allocating to known workloads.
• Token volume is a lower bound: Our estimates rely on public API throughput and disclosed metrics. Internal inference (not exposed via API) is not captured. Actual global volume is likely higher than our estimates.