How every number is calculated
The credibility of this index rests entirely on transparency. Nothing here is a black box: the rules below, the source data, and the code fully determine every figure.
1. Evidence ledger first, index second
We do not keep a flat date, company, tokens/day table. Disclosures are
heterogeneous: “monthly tokens,” “fiscal-year tokens,” API-only, router pass-through,
app-level consumption. So we store observations that preserve exactly what
each source said, then derive the series from them.
- Unit: everything is converted to trillions of tokens per day (monthly ÷ 30.44, yearly ÷ 365.25).
- Date: each observation is anchored to the midpoint of its reporting period, never the announcement date. A “980T in July 2025” disclosure sits in July 2025.
2. Two ledgers, never mixed in a headline
Supply
Who processed the tokens: Google, OpenAI, Microsoft Foundry, Fireworks, the China aggregate.
Demand
Who generated the demand: Harvey, Cursor, consumer apps. These tokens are also served by supply providers.
Router
Pass-through (OpenRouter), served by the supply-side providers, so it would double-count if summed in.
Demand and router tokens are already served by supply providers, so summing across ledgers double-counts. The reported floor sums supply + national-aggregate only.
3. Overlap handling: the double-count trap
Two explicit fields resolve overlap by human judgment, not silent summation:
contained_in (an observation’s superset) and include_in_floor.
The floor sums only the curated, non-overlapping set.
contained_in
the aggregate and excluded from the floor. Summing them would invent 120 T/day of phantom usage.
4. Estimated band (layer 2) — six-channel triangulation
Above the floor sit estimates for names with no usable disclosure, triangulated from the
six exhaust streams a company's tokens leave: hardware (fleet × throughput),
energy (power ÷ joules/token), financial (revenue or COGS ÷
$/Mtok), demand (users × messages × tokens/message),
telemetry (third-party market share), and anchors (direct
disclosures, which calibrate the rest). Channels are never averaged: the reconciled band is
the primary channel's, the cross-channel spread is the published error bar, and any channel
that fails its back-test against a disclosed anchor is excluded — visibly.
Every input lives in data/channel_inputs.csv with source, band, and confidence;
the full design is
METHODOLOGY_V2.md.
See the estimates →
5. Compute-implied capacity (layer 3)
An independent cross-check from the hardware side, bounding demand without reference to any disclosure or revenue figure:
capacity = accelerators × tokens/sec/accelerator × inference_fraction × utilization × 86,400| Parameter | Low | Mid | High | Basis |
|---|---|---|---|---|
| Accelerator installed base million_h100_equiv | 12 | 16 | 20 | Epoch AI: ~15M H100-equivalents operational end-2025 (~30 GW); growing ~3.3x/year |
| Throughput per accelerator tokens_per_sec | 1500 | 2500 | 5000 | MLPerf v4.1 audited: H100 dense Llama-70B FP8 ~3066 tok/s/GPU; DeepSeek-R1 MoE ~2788; optimized/Blackwell higher |
| Inference fraction fraction | 0.40 | 0.50 | 0.65 | McKinsey ~50/50 inference/training on a compute basis in 2025 rising to inference-heavy by 2030 (basis-dependent) |
| Utilization fraction | 0.25 | 0.40 | 0.50 | FlexPipe: GPU reservation falls ~75% to ~30% with better pipelining; allocation/duty-cycle utilization (distinct from ~10% per-kernel MFU) |
| Capacity (T/day) | 156 | 691 | 2,808 | low/high compound extreme assumptions |
The point is triangulation, not a precise capacity number:
- Demand is physically comfortable. The estimated total (~360.4 T/day) is only ~52% of mid-case capacity, consistent with much of the fleet on training/idle and the floor being a lower bound.
- The models constrain each other. The reported floor (300.1 T/day, a hard fact) exceeds the low-capacity scenario (156), so the all-pessimistic hardware assumptions are physically impossible and get ruled out.
Sourcing discipline
Every observation carries a source and (where captured) an archived
snapshot, because disclosures move, get edited, or vanish. Numbers are re-verified on a dated
pass; see the verified_date column in the
data.
The full method also lives in the repo’s methodology/methodology.md.