Metric
The usage-phase (inference) footprint of AI API traffic, estimated from
metadata only (model identifier, token counts, region, timestamp). This is a
bounded metric, not a cradle-to-grave one.
In scope: accelerator and server energy, idle and reserve serving
capacity, facility overhead (PUE), on-site cooling water consumed, off-site
water consumed in electricity generation, operational carbon at location-based
grid intensity, and an amortized embodied-carbon adder for hardware
manufacturing.
Water is consumption, not withdrawal. Footprint water means water
consumed (evaporated or otherwise not returned to the source it was drawn
from), on both paths. On-site, WUE follows The Green Grid's
definition[12]The Green Grid, 2011. Water Usage Effectiveness (WUE): the metric definition this methodology follows, applied to IT-boundary energy. on a consumption basis wherever the operator
reports one (Google, Microsoft, LBNL's US average). AWS reports withdrawal
only[11]AWS sustainability reporting. Fleet PUE and WUE reporting (2025 fleet PUE 1.14; WUE 0.12 L per kWh of IT load on a WITHDRAWAL basis, which this methodology uses as an upper bound on consumption; AWS's own stated conversion puts consumption at about two thirds of withdrawal), the basis of the aws facility profile.; withdrawal is never less than consumption, so the aws
profile uses it unconverted as an upper bound, which overstates that
profile's on-site water by about 1.5x on AWS's own stated conversion and
never understates it. Off-site, grid water uses operational water
consumption factors per generation type[13]Macknick et al. (NREL), 2011. A Review of Operational Water Consumption and Withdrawal Factors for Electricity Generating Technologies, NREL/TP-6A20-50900: the operational water CONSUMPTION factors per generation type behind off-site (grid) water intensity (the withdrawal factors are not used). as re-weighted to
current US data-centre generation mixes[14]Hidden Water Geography, 2026. The Hidden Water Geography of U.S. Hyperscale Data Centers in the AI Era, arXiv:2607.02531 (June 2026, preprint, not peer reviewed): location-based grid water consumption for 472 US hyperscale facilities, re-weighting Macknick et al. (2011) and Meldrum et al. (2013) consumption factors by balancing-authority generation mix. Grid-only consumption in Table S2 is 1.95 L per facility kWh (1.11 with reservoir evaporation excluded), the basis of the 2.0 L per kWh central since methodology 1.2.0.
(consumption, location-based, per facility kWh).
Out of scope, disclosed: model training (see below), hardware lifecycle
beyond the adder, network transport (under roughly 5 percent), and end-user
devices. Training is excluded because per-token amortization for heavily
served models is small, the denominator (lifetime inference tokens) is
unknowable from outside[5]Patterson et al., 2022. The Carbon Footprint of Machine Learning Training Will Plateau, Then Shrink: source of the operational split between inference and training for heavily served models, and why per-token training amortization is small. arXiv:2204.05149., and public calibration data covers a single model[6]Luccioni et al., 2022. Estimating the Carbon Footprint of BLOOM: the only full public lifecycle calibration of a large model, and the reason training amortization is treated as uncalibratable from outside. arXiv:2211.02001..
The metric is therefore named usage-phase footprint everywhere, never "the
footprint of AI."
Pipeline
classify model (pinned registry) -> model class (provider prefixes normalized)
resolve coefficients (with boundaries) -> per-token Wh, uplifts, PUE, WUE, grid zone
token accounting -> fresh + cached input, output (reasoning is a
reported subset of output, never re-added)
IT energy (accelerator boundary) -> token terms summed, residual per-class spread
shared factors (applied exactly once) -> x evidence-family factor (fully correlated
across classes) x idle/reserve uplift
boundary normalization -> x PUE (IT -> facility)
water -> on-site: IT-boundary kWh x WUE (Green Grid definition)
off-site: facility kWh x grid water intensity
carbon -> facility kWh x (per-zone grid intensity + embodied adder)
uncertainty -> closed-form lognormal propagation, P05/P50/P95
persist -> estimate + every resolved coefficient + version
Estimates are pure functions of (metadata, version). Every stored estimate
persists the resolved coefficients actually used, so any historical number is
reproducible by reading, not re-deriving.
Uncertainty
Two families of evidence for per-token energy disagree by roughly an order of
magnitude: top-down provider disclosures (Google's published median Gemini
prompt figures[1]Elsworth et al. (Google), 2025. Measuring the environmental impact of delivering AI at Google: median Gemini Apps text prompt at 0.24 Wh comprehensive versus 0.10 Wh accelerator-only, the anchor of the top-down evidence family. arXiv:2508.15734.; Epoch AI's GPT-4o estimate[2]Epoch AI, 2025. How much energy does ChatGPT use? Independent estimate of roughly 0.3 Wh for a typical GPT-4o query, corroborating the top-down family.; Mistral's lifecycle report[4]Mistral AI, 2025. Lifecycle analysis of Mistral Large 2 (with Carbone 4 and ADEME): a provider-published per-response footprint used to sanity-check the evidence families.) imply low values, while
parametric per-token fits (EcoLogits-style[3]EcoLogits (GenAI Impact). Open parametric methodology estimating per-request LLM energy from modeled parameter counts and serving hardware; the high (parametric) evidence family in the per-token energy range.) imply high ones. Batching,
hardware generation, and mixture-of-experts serving explain most of the gap,
but it is unresolved. Per-token P05 values sit at the top-down family, P95
values reach the parametric family, and centrals sit at the geometric
midpoint between them, not nearer the top-down family (derivation under
Constants).
What that means for one request, stated plainly: a frontier chat request
(1,000 input and 400 output tokens on Claude Opus 5.5, reasoning tokens
reported, no recognized region) models at 0.53 Wh (P05), 1.83 Wh (central)
and 6.33 Wh (P95) at the facility boundary. Google's published median Gemini
text prompt (0.24 Wh, 2025)[1]Elsworth et al. (Google), 2025. Measuring the environmental impact of delivering AI at Google: median Gemini Apps text prompt at 0.24 Wh comprehensive versus 0.10 Wh accelerator-only, the anchor of the top-down evidence family. arXiv:2508.15734. and Epoch AI's estimate for a
typical GPT-4o query (about 0.3 Wh, 2025)[2]Epoch AI, 2025. How much energy does ChatGPT use? Independent estimate of roughly 0.3 Wh for a typical GPT-4o query, corroborating the top-down family. both fall BELOW
the modeled P05, by roughly 2x, and 6 to 8x below the central. The
comparison is not exact (neither disclosure states its tokens per prompt, and
a median consumer prompt is probably shorter than 1,000 in and 400 out), but
this methodology's range sits above the top-down disclosures, not around
them. At a shorter shape nearer a median consumer prompt (250 in, 100 out),
which the release-gating calibration test uses, the interval does contain
0.24 Wh: a mid-class Gemini Flash request models 0.043 / 0.14 / 0.47 Wh and
a frontier request 0.13 / 0.46 / 1.58 Wh (P05 / central / P95), so there the
disclosure sits between P05 and the central. 1.3.0 does not recentre: the derivation has no arithmetic error, and
moving toward the top-down family needs a disclosure that states its token
counts.
Because that family-level disagreement affects every model class the same
way, it is carried by a single shared evidence-family factor (central 1.0,
90 percent range 0.45 to 2.2) applied exactly once per estimate, fully
correlated across classes; each per-token coefficient contributes only its
residual, class-specific spread. Without this factoring, summing classes
would treat the shared dispersion as independent noise and understate the
tails. As measured on the 1.1.0 estimator, composed 90 percent intervals
span roughly 10 to 12 fold for energy and carbon and roughly 20 to 27 fold
for water (which stacks WUE and grid-water uncertainty on top). Every
displayed figure carries its range.
All coefficients are modeled lognormal. Products propagate exactly; sums use
Fenton-Wilkinson moment matching[8]Fenton, 1960. The Sum of Log-Normal Probability Distributions in Scatter Transmission Systems (IRE Transactions on Communications): the moment-matching approximation used to combine lognormal terms.. A customer's monthly total is aggregated by
summing token counts per coefficient group first and applying coefficient
uncertainty once, because coefficient error is fully correlated across a
customer's events and does not average out.
The 90th percentile of the modeled range (P90) is the conservative
reference point this methodology reports. The interval covers the
methodology's stated parameter uncertainty only; structural uncertainty
(model form, tokenizer differences, the treated-as-independent PUE/WUE pair,
unregistered models, and the excluded scope) sits outside it by
construction, so P90 is described as the 90th percentile of the modeled
range (parameter uncertainty only) and never as guaranteed coverage. The
console's footprint bars rise to P90, with a shade change marking the median
(P50). Retirements are not sized from any customer's estimate: each tier
retires a fixed basket (see How basket sizes were chosen). Subscription pricing keys on billable
tokens (fresh input + output + 10 percent of cached input; reasoning is a
subset of output and never counted twice), never on footprint magnitude. The 10 percent cached rate is a fixed billing
rule defined in pricing, deliberately distinct from this methodology's
cached-input coefficient, so no coefficient here can influence revenue.
How basket sizes were chosen
Baskets are fixed per tier: a tier retires the same basket every month,
whatever the subscriber's usage or footprint estimate. They were sized once,
in pricing v4 (2026-08-31), at methodology 1.1.0, as the 90th percentile of
the modeled range for the tier's full token allowance under a chat-shaped
workload (20 percent of tokens output, 5 percent of input cached) on a
frontier-class model. They were re-checked at 1.2.0 (2026-10-14) and at
1.3.0 (2026-10-22). At 1.3.0 the chat-shaped P90 at the full allowance still
sits below every basket in every category; for Personal it is 114 gallons,
97 kg CO2e and 135 kWh against a 475 gallon, 230 kg, 425 kWh basket.
Under coding or agentic workloads at the full allowance the modeled P90 can
exceed the basket. Coding traffic (12 percent output, half of input cached,
the agentic hidden-reasoning mode) runs about 1.66 metered tokens per
allowance token, because cached input counts at 10 percent toward the
allowance. At 1.2.0, Personal at its full allowance modeled 492 gallons,
310 kg and 587 kWh against its 475 gallon, 230 kg, 425 kWh basket; at 1.3.0
it models 486 gallons, 419 kg and 579 kWh (carbon rose with the 1.3.0
unrecognized-region default). At 1.3.0 every tier's coding-shape P90 at
the full allowance exceeds its basket in at least one category, and in
carbon for all six tiers.
The basket is a fixed product allowance. It is not derived from any
estimate, and it is not a claim that any footprint is covered, matched, or
exceeded.
Calculation
For a usage event with fresh input tokens i, cached input tokens c, and
output tokens o (reported reasoning tokens are a subset of o and never add
a separate term), in model class m on facility profile f:
E_raw = i·e_in(m) + c·e_in(m)·k_cache + o·e_out(m)·[k_hidden(w) if the model reasons by default and reasoning is unreported;
w = declared workload (chat, agentic) or unknown]
E_raw = E_raw · k_tier (batch or priority service tier, if any)
per-class coefficients enter as residuals; the shared evidence-family
factor F_family and the idle/reserve uplift then apply exactly once:
E_IT = E_raw · F_family · U_idle (accelerator -> IT-equipment boundary)
E_fac = E_IT · PUE(f) (IT -> facility boundary)
Water = E_IT[kWh] · WUE(f) + E_fac[kWh] · W_grid (liters; reported in mL)
Carbon = E_fac[kWh] · ( I_grid(zone) + A_embodied ) (gCO2e, location-based;
embodied is an adder in
gCO2e/kWh, not a multiplier)
Energy = E_fac (Wh, facility boundary)
Every symbol is a lognormal coefficient from the tables below except token
counts, which are metered and exact. Uncertainty propagates in closed form:
fit: mu = ln(central)
sigma = ( ln(p95/central) + ln(central/p05) ) / 2 / 1.6449 (balanced two-sided)
if a physical floor exists: sigma = min( sigma, (mu - ln(floor)) / 1.6449 )
residual: for per-class coefficients, sigma_residual = sqrt( max(sigma^2 - sigma_family^2, 0) )
product: mu = sum(mu_i) sigma = sqrt( sum(sigma_i^2) )
sum: Fenton-Wilkinson moment matching:
S_mean = sum(exp(mu_j + sigma_j^2/2))
S_var = sum((exp(sigma_j^2) - 1) · exp(2·mu_j + sigma_j^2))
sigma_S = sqrt( ln(1 + S_var/S_mean^2) )
mu_S = ln(S_mean) - sigma_S^2/2
quantile: P_q = exp( mu + z_q·sigma ) (z_0.05 = -1.6449, z_0.5 = 0, z_0.9 = 1.2816, z_0.95 = 1.6449)
Monthly totals sum token counts per coefficient group first and apply
coefficient uncertainty once (full correlation across a customer's events),
then combine groups with Fenton-Wilkinson[8]Fenton, 1960. The Sum of Log-Normal Probability Distributions in Scatter Transmission Systems (IRE Transactions on Communications): the moment-matching approximation used to combine lognormal terms..
Constants
Generated from src/core/methodology/configV1.ts (methodology 1.3.0). Every
value is a lognormal coefficient; the table shows the MODELED quantiles
(the median and the 90 percent range the estimator actually integrates
over, after the balanced two-sided fit and any physical floor). The
"Input range" column is the elicited P05 to P95 the fit started from. A
single-sigma lognormal cannot honor two asymmetric bounds, so where the
two differ the modeled range is the one every estimate uses, and both are
published so the gap is visible. Boundary states what the value already
includes (accelerator, server, or facility) so uplifts are applied exactly
once. Full source citations, vintages, and derivations accompany each
value in the config file.
Per-token IT energy (accelerator boundary)
| Model class |
P05 |
Central |
P95 |
Input range |
Unit |
Boundary |
Confidence |
| frontier, input |
0.0000586 |
0.0002 |
0.000683 |
0.00006 to 0.0007 |
Wh/token |
accelerator |
low |
| frontier, output |
0.000465 |
0.0018 |
0.00697 |
0.0005 to 0.0075 |
Wh/token |
accelerator |
medium |
| frontier-reasoning, input |
0.0000586 |
0.0002 |
0.000683 |
0.00006 to 0.0007 |
Wh/token |
accelerator |
low |
| frontier-reasoning, output |
0.000568 |
0.0022 |
0.00852 |
0.0006 to 0.009 |
Wh/token |
accelerator |
low |
| mid, input |
0.0000187 |
0.00007 |
0.000262 |
0.00002 to 0.00028 |
Wh/token |
accelerator |
low |
| mid, output |
0.000161 |
0.0006 |
0.00224 |
0.00018 to 0.0025 |
Wh/token |
accelerator |
medium |
| small, input |
0.00000516 |
0.00002 |
0.0000775 |
0.000006 to 0.00009 |
Wh/token |
accelerator |
low |
| small, output |
0.000045 |
0.00018 |
0.00072 |
0.00005 to 0.0008 |
Wh/token |
accelerator |
medium |
| unclassified, input |
0.000101 |
0.00035 |
0.00121 |
0.0001 to 0.0012 |
Wh/token |
accelerator |
low |
| unclassified, output |
0.00101 |
0.0035 |
0.0121 |
0.001 to 0.012 |
Wh/token |
accelerator |
low |
The unclassified class is deliberately the most conservative row: unknown models
route there, take the hidden-reasoning multiplier whenever reasoning is unreported
(since 1.3.0), and above 15 percent unclassified tokens in a period the certificate
carries a disclosure.
Derivation (spec §3.2, with its primaries): the frontier output P05 of 0.0005 Wh
per token is the top-down anchor (Google's 0.24 Wh median Gemini prompt, about
0.14 Wh of it accelerator[1]Elsworth et al. (Google), 2025. Measuring the environmental impact of delivering AI at Google: median Gemini Apps text prompt at 0.24 Wh comprehensive versus 0.10 Wh accelerator-only, the anchor of the top-down evidence family. arXiv:2508.15734., spread over an assumed ~280 tokens,
since no provider discloses tokens per prompt; Epoch AI's ~0.3 Wh GPT-4o
query[2]Epoch AI, 2025. How much energy does ChatGPT use? Independent estimate of roughly 0.3 Wh for a typical GPT-4o query, corroborating the top-down family. agrees). The P95 of 0.0075 reaches the parametric anchor
(EcoLogits: 8.91e-5 Wh per billion active parameters plus 1.43e-3 Wh per output
token on A100-class hardware, ~0.010 Wh at 100B active, ~0.005 on H100
class[3]EcoLogits (GenAI Impact). Open parametric methodology estimating per-request LLM energy from modeled parameter counts and serving hardware; the high (parametric) evidence family in the per-token energy range.). The central 0.0018 is their geometric midpoint,
sqrt(0.0005 x 0.0065). Input rows are output divided by ~9 (the central
decode-to-prefill ratio); frontier-reasoning output is frontier x ~1.2, mid is
frontier / 3, small is frontier / 10 (elicited class ratios with no
class-specific primary source); unclassified is the frontier-reasoning P75.
Shared factors, uplifts, and token accounting
| Constant |
P05 |
Central |
P95 |
Input range |
Unit |
Boundary |
Confidence |
| Evidence-family dispersion (shared, applied once) |
0.452 |
1 |
2.21 |
0.45 to 2.2 |
multiplier |
accelerator |
low |
| Idle/reserve uplift (server folded in) |
1.3 |
1.57 |
1.9 |
1.3 to 2.4 |
multiplier |
accelerator |
medium |
| Embodied carbon adder (carbon only) |
21.5 |
43 |
86 |
25 to 100 |
gCO2e/kWh facility |
facility |
low |
| Cached-input fraction |
0.0447 |
0.1 |
0.224 |
0.05 to 0.25 |
of input coeff. |
accelerator |
low |
| Batch service tier |
0.437 |
0.6 |
0.825 |
0.45 to 0.85 |
multiplier |
accelerator |
low |
| Priority service tier |
1 |
1.15 |
1.32 |
1 to 1.4 |
multiplier |
accelerator |
low |
| Hidden-reasoning multiplier |
1.1 |
4 |
14.6 |
1.5 to 20 |
on output tokens |
accelerator |
low |
| Hidden-reasoning multiplier, chat workload |
1 |
2 |
4 |
1.2 to 5 |
on output tokens |
accelerator |
low |
| Hidden-reasoning multiplier, agentic workload |
5 |
10 |
20 |
5 to 20 |
on output tokens |
accelerator |
low |
The evidence-family factor carries the shared top-down vs parametric
dispersion and is applied exactly once per estimate, fully correlated
across model classes; per-class coefficients contribute their residual
spread. The hidden-reasoning multiplier applies to models that reason by
default (a per-model registry flag since 1.2.0) when the feed does not
report reasoning token counts. The measured evidence is bimodal (roughly
1.5 to 2.6x on ordinary chat, roughly 6 to 13x on coding and agentic
workloads), so where the workload is declared the matching mode applies
(chat, or coding and agentic); where it is not, the single central sits
between the modes. It never defaults to 1.0.
The embodied term is an ADDER in gCO2e per facility kWh, not a
multiplier, because embodied share and grid intensity are anti-correlated.
The idle/reserve uplift carries a fit floor at its evidence floor (1.3, no fleet
disclosure is lower), so its modeled P05 sits at that floor and its modeled
P95 sits below the elicited upper bound.
Facility profiles (PUE and on-site WUE)
Every PUE carries a physical floor of 1.0 (facility power can never be less
than IT power). WUE is on-site water CONSUMED per IT kWh, except the aws row:
AWS publishes withdrawal only, which is used unconverted as an upper bound on
consumption, so that row overstates on-site water by about 1.5x on AWS's own
stated conversion and never understates it.
| Profile |
PUE P05 |
PUE central |
PUE P95 |
PUE input range |
WUE P05 |
WUE central |
WUE P95 (L/kWh IT) |
WUE input range |
WUE basis |
| google-cloud |
1.04 |
1.09 |
1.15 |
1.04 to 1.15 |
0.704 |
1.15 |
1.88 |
0.6 to 1.6 |
consumption |
| azure |
1.07 |
1.17 |
1.28 |
1.08 to 1.3 |
0.0331 |
0.27 |
2.2 |
0.03 to 2 |
consumption |
| aws |
1 |
1.14 |
1.3 |
1.06 to 1.46 |
0.0101 |
0.12 |
1.43 |
0.02 to 2.85 |
withdrawal (upper bound on consumption) |
| direct-api |
1.01 |
1.2 |
1.42 |
1.08 to 1.52 |
0.0836 |
0.45 |
2.42 |
0.1 to 2.9 |
consumption |
| unknown |
1.19 |
1.45 |
1.76 |
1.15 to 1.7 |
0.112 |
0.5 |
2.24 |
0.15 to 3 |
consumption |
Only AWS region codes are recognized today. A recognized code fixes the grid
zone and applies the serving provider's own fleet profile where that is known
(google-cloud for Google models) and the aws profile otherwise. Azure and Google
Cloud region codes, and any free text, take the unrecognized path: the
google-cloud, direct-api, or unknown profile by model provider, with the
unrecognized-region grid default. That default is the element-wise maximum over
the mapped zones, and every unrecognized profile matches or exceeds the profile
a recognized code would apply, so a customer-supplied region can never reduce
the estimate below what a recognized mapping would produce.
Water and carbon intensity
| Constant |
P05 |
Central |
P95 |
Input range |
Unit |
Boundary |
Confidence |
| Off-site (grid) water intensity, consumption |
0.73 |
2 |
5.48 |
0.8 to 6 |
L consumed/kWh facility |
facility |
low |
| Grid carbon intensity (unrecognized-region default, max over mapped zones) |
563 |
671 |
800 |
570 to 810 |
gCO2e/kWh |
facility |
low |
Grid carbon by zone (location-based annual average)
| Zone |
Mapped regions |
P05 |
Central |
P95 |
Vintage |
Basis |
| eGRID:NWPP |
us-west-2 |
248 |
288 |
335 |
2023 |
EPA eGRID2023 rev.2 (CO2e, generation, direct) |
| eGRID:CAMX |
us-west-1 |
162 |
195 |
235 |
2023 |
EPA eGRID2023 rev.2 (CO2e, generation, direct) |
| eGRID:SRVC |
us-east-1 |
233 |
271 |
315 |
2023 |
EPA eGRID2023 rev.2 (CO2e, generation, direct) |
| eGRID:RFCW |
us-east-2 |
357 |
416 |
484 |
2023 |
EPA eGRID2023 rev.2 (CO2e, generation, direct) |
| EM:IE |
eu-west-1 |
215 |
256 |
305 |
2025 |
Ember 2025 (lifecycle CO2e, generation) |
| EM:DE |
eu-central-1 |
277 |
330 |
393 |
2025 |
Ember 2025 (lifecycle CO2e, generation) |
| EM:GB |
eu-west-2 |
182 |
217 |
259 |
2025 |
Ember 2025 (lifecycle CO2e, generation) |
| EM:FR |
eu-west-3 |
33.2 |
42 |
53.1 |
2025 |
Ember 2025 (lifecycle CO2e, generation) |
| EM:SE |
eu-north-1 |
29.2 |
35 |
41.9 |
2025 |
Ember 2025 (lifecycle CO2e, generation) |
| EM:IN |
ap-south-1 |
563 |
671 |
800 |
2025 |
Ember 2025 (lifecycle CO2e, generation) |
| EM:SG |
ap-southeast-1 |
417 |
497 |
592 |
2025 |
Ember 2025 (lifecycle CO2e, generation) |
| EM:JP |
ap-northeast-1 |
400 |
477 |
569 |
2025 |
Ember 2025 (lifecycle CO2e, generation) |
| EM:AU |
ap-southeast-2 |
435 |
518 |
616 |
2025 |
Ember 2025 (lifecycle CO2e, generation) |
Basis note: both are generation-based annual averages, but eGRID zones are
direct combustion CO2e while Ember zones are lifecycle CO2e (1.1.0 said CO2
only; corrected in 1.2.0), so non-US zones carry roughly 5 to 10 percent of
upstream emissions that US zones do not. Disclosed, not adjusted. Deliberately unmapped pending primary zone data (conservative default applies): EM:CA-QC.
Provenance
Per-token energy P05 values come from the top-down
disclosures[1]Elsworth et al. (Google), 2025. Measuring the environmental impact of delivering AI at Google: median Gemini Apps text prompt at 0.24 Wh comprehensive versus 0.10 Wh accelerator-only, the anchor of the top-down evidence family. arXiv:2508.15734.[2]Epoch AI, 2025. How much energy does ChatGPT use? Independent estimate of roughly 0.3 Wh for a typical GPT-4o query, corroborating the top-down family.[4]Mistral AI, 2025. Lifecycle analysis of Mistral Large 2 (with Carbone 4 and ADEME): a provider-published per-response footprint used to sanity-check the evidence families., P95 values
reach the parametric family[3]EcoLogits (GenAI Impact). Open parametric methodology estimating per-request LLM energy from modeled parameter counts and serving hardware; the high (parametric) evidence family in the per-token energy range., and centrals sit at the
geometric midpoint; the top-down disclosures themselves fall below the
modeled P05 for a typical request (see Uncertainty). Facility PUE and on-site
WUE come from the operators' own fleet reporting[9]Google data center efficiency reporting. Fleet-wide PUE reporting (2025 fleet PUE 1.09), the basis of the google-cloud facility profile.[10]Microsoft datacenter sustainability reporting. Fleet PUE and WUE reporting (FY25 fleet PUE 1.17, WUE 0.27 L per kWh on a consumption basis), the basis of the azure facility profile.[11]AWS sustainability reporting. Fleet PUE and WUE reporting (2025 fleet PUE 1.14; WUE 0.12 L per kWh of IT load on a WITHDRAWAL basis, which this methodology uses as an upper bound on consumption; AWS's own stated conversion puts consumption at about two thirds of withdrawal), the basis of the aws facility profile.,
applied under The Green Grid's WUE definition[12]The Green Grid, 2011. Water Usage Effectiveness (WUE): the metric definition this methodology follows, applied to IT-boundary energy. on a
consumption basis (AWS reports withdrawal, used as an upper bound). Off-site
water uses operational water consumption factors per generation
type[13]Macknick et al. (NREL), 2011. A Review of Operational Water Consumption and Withdrawal Factors for Electricity Generating Technologies, NREL/TP-6A20-50900: the operational water CONSUMPTION factors per generation type behind off-site (grid) water intensity (the withdrawal factors are not used)., re-weighted to current US data-centre generation
mixes (1.95 L consumed per facility kWh)[14]Hidden Water Geography, 2026. The Hidden Water Geography of U.S. Hyperscale Data Centers in the AI Era, arXiv:2607.02531 (June 2026, preprint, not peer reviewed): location-based grid water consumption for 472 US hyperscale facilities, re-weighting Macknick et al. (2011) and Meldrum et al. (2013) consumption factors by balancing-authority generation mix. Grid-only consumption in Table S2 is 1.95 L per facility kWh (1.11 with reservoir evaporation excluded), the basis of the 2.0 L per kWh central since methodology 1.2.0., with the
on-site plus off-site framing following the AI water-footprint literature[15]Li et al., 2023. Making AI Less Thirsty: Uncovering and Addressing the Secret Water Footprint of AI Models: the framing for combining on-site cooling water with off-site electricity-embedded water. arXiv:2304.03271..
The embodied-carbon adder is grounded in architectural embodied-carbon
accounting[16]Gupta et al., 2021-2022. Chasing Carbon (HPCA 2021) and ACT (ISCA 2022): architectural embodied-carbon accounting, the basis of the amortized embodied adder., accelerator product carbon footprints[17]NVIDIA, 2024. HGX H100 product carbon footprint summary: manufacturing emissions for the dominant serving accelerator, the anchor of the embodied adder range.,
and the Boavizta database[18]Boavizta. Open database and methodology for ICT hardware embodied impacts, cross-checking the embodied adder.. Per-zone grid carbon values come
from EPA eGRID subregion CO2e rates, direct combustion (US)[19]EPA eGRID. US subregion grid emission factors (eGRID2023 rev.2, CO2e output rates): the pinned-vintage source for US zone carbon intensities since methodology 1.1.0., and
Ember national generation intensities, lifecycle CO2e (elsewhere)[20]Ember. National generation intensities (Ember Yearly Electricity Data, 2025 data year): the pinned-vintage source for non-US zones since methodology 1.1.0. Lifecycle CO2e (IPCC AR5 lifecycle factors per fuel), generation-based; 1.1.0 described these as CO2 only and widened upper bounds for that, a premise withdrawn in 1.2.0. Against eGRID's direct-combustion basis, non-US zones carry roughly 5 to 10 percent of upstream emissions that US zones do not.. The hidden-reasoning multiplier's
range reflects measured bimodality in reasoning-model output
volume[7]ML.ENERGY / Chung et al., 2025. The ML.ENERGY measurements behind the hidden-reasoning multiplier: reasoning models emit roughly 1.5 to 2.6x a non-reasoning model's output tokens on ordinary chat and roughly 11 to 13x on hard reasoning workloads, the bimodality the multiplier's wide interval reflects. arXiv:2505.06371..
Choices
- Location-based, not market-based, grid carbon (GHG Protocol Scope 2
vocabulary[21]GHG Protocol, 2015. Scope 2 Guidance: the location-based accounting method this methodology follows for grid carbon.): market-based figures would let provider REC matching drive
obligations toward zero; location-based is more physically defensible.
- Average, not marginal, grid intensity: the metric attributes
responsibility for existing load, it does not optimize placement. The
Green Software Foundation SCI specification (v1.1) permits short-run
marginal, long-run marginal, or average grid intensity while excluding
market-based measures; this methodology's location-based annual-average
choice is consistent with that allowance[22]Green Software Foundation. Software Carbon Intensity specification (ISO/IEC 21031:2024): the metric shape this methodology is informed by, while deliberately diverging on marginal versus average intensity..
- Grid carbon values, per zone since 1.1.0: mapped regions use
primary-source annual averages with pinned vintages: EPA eGRID[19]EPA eGRID. US subregion grid emission factors (eGRID2023 rev.2, CO2e output rates): the pinned-vintage source for US zone carbon intensities since methodology 1.1.0.
subregion CO2e rates for US zones, and Ember[20]Ember. National generation intensities (Ember Yearly Electricity Data, 2025 data year): the pinned-vintage source for non-US zones since methodology 1.1.0. Lifecycle CO2e (IPCC AR5 lifecycle factors per fuel), generation-based; 1.1.0 described these as CO2 only and widened upper bounds for that, a premise withdrawn in 1.2.0. Against eGRID's direct-combustion basis, non-US zones carry roughly 5 to 10 percent of upstream emissions that US zones do not. national
generation intensities for non-US zones. The two bases differ: eGRID is
direct combustion CO2e; Ember is lifecycle CO2e (1.1.0 described it as
CO2 only and widened upper bounds for that; 1.2.0 withdrew the premise
after reading Ember's methodology). Non-US zones therefore carry roughly
5 to 10 percent of upstream emissions that US zones do not; this is
disclosed rather than adjusted until eGRID2024 is released. Regions
without a comparable primary-source zone value deliberately stay on the
unrecognized-region default rather than borrow a flattering figure. Since
1.3.0 that default is the element-wise maximum over the mapped zones
(currently India's: central 671, modeled range 563 to 800 gCO2e per kWh),
above the Ember world average of 458 to 471. 1.1.0 and 1.2.0 used central
450 (modeled range 269 to 753), which sat below the world average and
should not have been called conservative. Quebec's published
intensities are a residual market-based rate (Hydro-Québec) and a direct
consumption-based rate (ECCC), neither on this methodology's basis.
- Unclassified models are estimated with the most conservative class in
the table, because unknown models skew toward new frontier and reasoning
models, and since 1.3.0 they are assumed to reason by default, so the
hidden-reasoning multiplier applies whenever reasoning is unreported. An
unclassified request therefore never estimates below the same request on
any classified frontier model (before 1.3.0 it could: 4.18 Wh against
5.86 Wh for Opus 5.5 on 1,000 in and 400 out). Above 15 percent
unclassified tokens in a period, certificates carry a disclosure and the
console alerts.
- Hidden reasoning tokens: for models that reason by default (a
per-model registry flag since 1.2.0, no longer implied by the class)
whose feeds do not report reasoning token counts, output tokens are
scaled by a multiplier with a physical floor of 1.0, since hidden
reasoning cannot reduce compute. The underlying evidence is bimodal:
measured ratios cluster around 1.5 to 2.6x for ordinary chat traffic and
around 6 to 13x for coding and agentic workloads[7]ML.ENERGY / Chung et al., 2025. The ML.ENERGY measurements behind the hidden-reasoning multiplier: reasoning models emit roughly 1.5 to 2.6x a non-reasoning model's output tokens on ordinary chat and roughly 11 to 13x on hard reasoning workloads, the bimodality the multiplier's wide interval reflects. arXiv:2505.06371..
Where the workload is declared (the self-estimator asks; an API feed may
say), the matching mode applies: chat central 2.0, coding and agentic
central 10. Where it is not, the single central of 4.0 sits between the
modes (modeled 90 percent range 1.1 to 14.6) and the wide interval says
so honestly. Whether a provider reports reasoning tokens is recorded per
model in the registry; OpenAI, Google, xAI, Qwen, DeepSeek, NVIDIA,
ByteDance and Meta do, Anthropic, Z.ai, Mistral, Cohere and Microsoft do
not, and Moonshot does on one endpoint only.
- Tokenizer differences across providers (roughly 20 percent for English
prose) are not normalized: each provider's coefficients apply to that
provider's own counts; the effect is second order against the coefficient
interval.
- PUE and WUE are negatively correlated (air cooling trades water for
energy); they are treated as independent, which widens rather than narrows
the interval, because a sourced joint distribution does not exist.
- Region honesty: only AWS region codes are recognized today. A
recognized code sets the grid zone and applies the serving provider's own
fleet profile where known (google-cloud for Google models) and the aws
profile otherwise. Azure and Google Cloud region codes and any free text
are unrecognized: they take the google-cloud, direct-api, or unknown
profile by model provider and the unrecognized-region grid default, which
is the maximum over mapped zones. A customer-supplied region can therefore
never reduce an estimate below what a recognized mapping would produce,
including for India (ap-south-1), the highest mapped zone.
Standards
This methodology does not claim conformance to any standard. It is
informed by: the Green Software Foundation SCI shape (ISO/IEC 21031:2024)[22]Green Software Foundation. Software Carbon Intensity specification (ISO/IEC 21031:2024): the metric shape this methodology is informed by, while deliberately diverging on marginal versus average intensity.,
including its embodied term, while deliberately diverging on marginal
intensity; the GHG Protocol Scope 2 Guidance for the location-based method[21]GHG Protocol, 2015. Scope 2 Guidance: the location-based accounting method this methodology follows for grid carbon.;
and The Green Grid's WUE definition[12]The Green Grid, 2011. Water Usage Effectiveness (WUE): the metric definition this methodology follows, applied to IT-boundary energy.. It does not meet ISO 14067 or the GHG
Protocol Product Standard (cradle-to-grave) and does not reference them as a
basis. ISO 14064-3 third-party review is the intended path before any
strengthened claim.
Unknowables
Stated plainly because every competitor faces the same wall:
- Active parameter counts, serving hardware, and datacenter regions for
closed frontier models are undisclosed; those estimates carry the full
interval width.
- Hidden reasoning token volume where APIs do not report it.
- Site-level WUE and grid mix for unidentifiable datacenters, which is most
direct API traffic.
- Whether the top-down or parametric energy evidence family is closer to
right. Only direct measurement on open-weight models will narrow it.
- Whether restoration in one basin meaningfully addresses water consumed in
another. This is a scientific and ethical question accounting cannot
resolve; water claims stay activity-framed and geographically qualified.
Changelog
| Version |
Date |
Change |
| 1.3.0 |
2026-10-22 |
Self-check review, section E (docs/plans/self-check-review-2026-10-22.md). Numeric changes: every PUE carries a physical floor of 1.0 (the aws balanced fit had a modeled P05 of 0.971; aws now 1.00 [modeled P95 1.34 -> 1.30]); the idle/reserve uplift's evidence floor of 1.30 is now a fit floor (modeled 1.16 / 1.57 / 2.13 -> 1.30 / 1.57 / 1.90), which reconciles the 1.2.0 entry below with the code; the unclassified model class takes the hidden-reasoning multiplier when reasoning is unreported, making it the most conservative estimate and not only the largest coefficient (1,000 in / 400 out: 4.18 -> 13.7 Wh central); the unrecognized-region grid default is the element-wise max over mapped zones, 671 [570, 810] (modeled 563 to 800), replacing 450 [250, 700], which was below the Ember world average (carbon for traffic without a recognized region rises about 45 percent at the central); a recognized region code applies Google's fleet profile to Google models instead of the aws profile. Publication: the constants table adds the elicited input range beside every modeled range; per-token rows cite their primaries, vintages and derivation (centrals are the geometric midpoint of the families, not nearer the top-down family, and Google's 0.24 Wh and Epoch's 0.3 Wh fall below the modeled P05 of a typical request); footprint water defined as consumption, with AWS withdrawal flagged as an upper bound; grid water cited to arXiv:2607.02531 (the study 1.2.0 called the 2026 hidden-water geography study) on Macknick consumption factors; recognized region codes disclosed as AWS-only. Basket sizing note added. The full-allowance figures in that note now convert allowance (billable) tokens to metered tokens, which raises the coding-shape figures about 1.66x and the chat-shape figures about 1.04x; the same conversion feeds the pricing page's full-allowance cost ceiling. |
| 1.2.0 |
2026-10-14 |
First research-watch pass (docs/research/digests/2026-10-12.md, 129 primary-source observations, seven assessed proposals). Six coefficient refreshes: embodied adder 50 [20,120] -> 43 [25,100] on fleet-level Google disclosures and NVIDIA PCFs; idle/reserve elicited p05 1.25 -> 1.30 (no fleet disclosure below 1.31; the balanced fit left the modeled P05 at 1.16 until 1.3.0 made 1.30 a fit floor); Google 2025 PUE 1.09, Microsoft FY25 PUE 1.17 and WUE 0.27, AWS 2025 PUE 1.14 and WUE 0.12 (withdrawal basis, disclosed); direct-api PUE 1.30 -> 1.20 [1.08,1.52] and WUE 0.90 -> 0.45, unknown WUE 1.20 -> 0.50 (both 1.1.0 centrals sat above every measured operator); grid water 2.4 [0.6,6] -> 2.0 [0.8,6] (source: arXiv:2607.02531, named in 1.3.0); EM:AU-NSW renamed EM:AU at the Ember national 518 [435,616]. Ember intensities relabelled lifecycle CO2e (1.1.0 said CO2 only; the widening premise is withdrawn and the lifecycle-vs-direct mismatch with eGRID is disclosed instead). Hidden reasoning restructured: the registry carries a per-model reasons-by-default flag and a provider reports-reasoning-tokens flag, the class no longer implies reasoning, and the multiplier is conditioned on declared workload (chat 2.0 [1.2,5], coding and agentic 10 [5,20], unknown 4.0 [1.5,20] unchanged) because the measured evidence is bimodal and the self-estimator can see the mode. Registry: frontier-reasoning reserved for models whose reasoning cannot be switched off; Sonnet 5 reclassed mid and Opus 5 frontier; 50 models released June to October 2026 added from provider docs; retired rows dated. Self-estimates route the flagship answer to a flagship (Opus 5.5) instead of Sonnet 5. Claims: four phrases added to the banned list from EU 2024/825 recital 12 and SBTi CNZS V2 C37.10. |
| 1.1.0 |
2026-08-06 |
Correlation and coefficient rebuild after independent review: shared evidence-family factor applied once per estimate (fixes P90 understatement from treating family-level dispersion as independent per class); balanced two-sided lognormal fit with physical floors; reasoning tokens treated as a reported subset of output (no separate energy or billing term); embodied carbon changed from multiplier to gCO2e/kWh adder anchored on accelerator product carbon footprints; idle/reserve uplift corrected to 1.571 [1.25, 2.4] per the fleet-level Google accounting; per-zone grid carbon from EPA eGRID2023 (US, CO2e) and Ember 2025 (non-US, CO2-only with widened bounds), unknown default widened to [250, 700]; Google WUE raised to 1.15 (fleet, not the efficient-sites subset); AWS WUE 0.15 (2024 disclosure); hidden-reasoning multiplier floored at 1.0 with bimodality disclosed; published constants table now shows modeled quantiles. |
| 1.0.0 |
2026-08-05 |
First reviewed methodology: coefficient provenance with boundaries, lognormal uncertainty propagation, model registry with conservative unclassified class, hidden-reasoning multiplier, WUE on IT-boundary energy, location-based grid carbon, embodied-carbon uplift, correlated monthly aggregation. |
| 0.1.0-placeholder |
2026-07-29 |
Prototype placeholders. Retained only to reproduce estimates recorded under that version. |
- Claim language and required disclosures:
src/core/config/claims.ts,
docs/TOS-SCHEDULES.md
- Known overlap disclosure: if a customer's model provider reports
its market-based emissions as zero through annual REC matching and the customer
separately retires RECs here, the same megawatt-hour is arguably claimed
twice. The Terms require customers to disclose provider-level claims, and
this document discloses the overlap.