What a ChatGPT Query Actually Costs in Energy and Water: Every Number, Traced to Source

Two numbers dominate every conversation about the environmental cost of chatbots: 2.9 watt-hours per query, and a 500 ml bottle of water. Both come from real, citable work. Neither says what the popular version says it says.

The 2.9 Wh is a 2023 estimate for a GPT-3.5-era model, built on an assumption that replies run to roughly 1,500 words. The 500 ml is a peer-reviewed figure for 10 to 50 responses, not one conversation — and about 87% of it is water evaporated at power stations rather than at the data centre. Meanwhile the real range of AI energy per query in late 2026 spans roughly three orders of magnitude, depending on whether the model answers a one-line question or runs an agent loop.

This post collects every published per-query energy and water figure I could trace. Each one gets its scope, method, date and funder recorded, and the disagreements are put side by side rather than resolved.

What this covers: the provenance of the headline numbers, the workload spread that makes any single figure fragile, what water usage effectiveness does and does not measure, the contested training-versus-inference split, aggregate demand and grid evidence, and the measurements that would settle the open questions.

Context and Background

Until August 2025 there was no production measurement of AI inference energy in the public record. Every number in circulation was a bottom-up estimate: take a plausible model size, a plausible accelerator, a plausible utilisation, multiply, and publish. That is a legitimate method — it is how industrial AI inference carbon accounting has been done for years — but it inherits the error of whichever assumption is least well grounded, and in practice that was almost always the number of output tokens per query.

The disclosure picture is lopsided in a specific way. Hyperscale operators publish fleet-wide efficiency ratios — power usage effectiveness (PUE) and water usage effectiveness (WUE) — in annual sustainability reports, because those metrics were standardised by The Green Grid and later by ISO/IEC 30134. They do not generally publish per-query figures, per-model figures, or the utilisation data you would need to derive them. Model developers publish benchmark scores and, occasionally, training energy. Almost nobody publishes inference energy broken down by workload type.

That asymmetry matters because the two sides of the argument draw on different evidence classes. Aggregate grid data is strong: interconnection queues, capacity auction clearing prices and utility filings are public, audited and hard to spin. Per-query data is weak: mostly estimates, mostly from parties with an interest, mostly without error bars. Articles that pair a confident per-query number with a confident aggregate number are usually mixing a weak measurement with a strong one.

Three institutional positions frame most of the current debate. The International Energy Agency’s Energy and AI report (April 2025) and its 2026 follow-up model data centre demand globally and are explicit about where their proxies are weak. Lawrence Berkeley National Laboratory’s US data centre reports set the reference range for American consumption. And the operators — Google, Microsoft, Amazon, Meta — publish the only first-party instrumentation that exists. Each of those parties has something at stake, and this post names it each time a number of theirs appears. For the build-out side of the story, see the companion analysis of AI data centre power and the nuclear question; the IEA’s energy demand from AI page is the primary source for the aggregate figures used here.

Every published AI energy per query figure, traced to its source

There is no single correct figure for AI energy per query. Published estimates for a standard text prompt cluster between 0.24 and 0.34 watt-hours, the older and most-quoted estimate of 2.9 Wh rests on a 2023 model and an output-length assumption roughly eight times typical, and workloads that use reasoning or agent loops measure one to three orders of magnitude higher.

Figure 1: The workload spread. Per-query GPU electricity for five workload classes, from IEA, “Key Questions on Energy and AI” (April 2026), Figure 2.1.

The five values in Figure 1 come from Figure 2.1 of the IEA’s Key Questions on Energy and AI (April 2026), captioned “Indicative inference GPU electricity consumption across different model types for text generation and agentic tasks.” They are internally consistent because they all measure GPU electricity only — no host CPU, no idle reserve, no facility overhead. That makes them unsuitable for comparison against the Google or Microsoft figures below, which use wider boundaries, but excellent for comparison against each other.

A medium language model generating text lands at 0.05 Wh. A large mixture-of-experts model doing the same task lands at 0.31 Wh. An agentic pattern making four to six sequential model calls lands at 1.14 Wh. Turning on reasoning takes it to 7.6 Wh. Agentic plus reasoning reaches 50 Wh — about the energy in one phone charge. The ratio from top to bottom is roughly 1,000 to 1.

Three qualifiers travel with those numbers, and the IEA states all three itself. The specific models are named: medium LM and reasoning are both DeepSeek-R1-Distill-Llama-70B, with reasoning off and on respectively; the large MoE is Qwen3-235B-A22B. The text-generation values come from the AI Energy Score leaderboard, which benchmarks open-weight models under standardised conditions “designed to ensure cross-model comparability rather than to represent optimised production deployments” — so they are not production figures. And the agentic values are not measured at all: they are “derived by applying token-scaled decomposition” to the underlying model’s consumption. The IEA asks that they be read “as indicative of the order of magnitude rather than as precise figures for any specific system.”

One further caution, because it is an easy error to make. The IEA’s earlier Energy and AI report (April 2025) contains an analogous chart at Figure 1.17 whose numbers are not compatible with these — its medium-sized language model sits at roughly 4 Wh against the 2026 figure’s 0.05 Wh, an eighty-fold revision driven by different benchmark models and the move to the AI Energy Score leaderboard. The two figures look similar and are a year apart. Citing the 2025 report for the ladder above would be wrong.

Where 2.9 Wh came from and what it assumed

The 2.9 Wh figure is usually attributed to the Electric Power Research Institute, whose May 2024 report Powering Intelligence put it in wide circulation. EPRI quoted it; EPRI did not produce it. The report’s reference 47 points to Alex de Vries, “The Growing Energy Footprint of Artificial Intelligence,” published in Joule 7(10) in October 2023. De Vries in turn built on a February 2023 SemiAnalysis estimate.

Figure 2: The transmission chain. How two narrow published claims became two broad popular ones, and the step at which the qualifying scope was dropped.

The underlying assumptions are specific and knowable. The model is a GPT-3.5-class 175-billion-parameter dense transformer. The hardware is A100 HGX nodes at 800 W per GPU. The query is assumed to consist of 4,000 input tokens and 2,000 output tokens — roughly a 1,500-word reply. That last assumption dominates the result. Typical chatbot replies run around 260 output tokens, so the estimate models a query nearly eight times longer than the median, on hardware two generations old, for a dense architecture that has since been largely displaced by sparse mixture-of-experts serving. For a standard 2026 text query the figure is roughly an order of magnitude high.

None of that is a flaw in de Vries’s paper, which was explicit about its inputs and was making a point about growth rates rather than publishing a per-query constant. The distortion happens in transmission: EPRI quoted it correctly, headlines quoted EPRI, and the assumptions did not survive the trip.

The same applies to the companion claim that “an AI query uses ten times the electricity of a Google search.” The 0.3 Wh search figure comes from a 2009 blog post by Urs Hölzle, then Google’s senior vice president for operations. It has not been updated in seventeen years. It predates the smartphone-dominant web, inline video, and Google’s own TPU fleet. The comparison sets a 2023 AI estimate against a 2009 search figure and treats the ratio as current.

The one production measurement that exists

In August 2025 a Google team — Cooper Elsworth, Keguo Huang, David Patterson, Jeff Dean, Amin Vahdat, James Manyika and colleagues — published Measuring the environmental impact of delivering AI at Google Scale (arXiv:2508.15734). It is, as the abstract states, the first study to measure AI serving environmental metrics in a production environment. The headline result: the median Gemini Apps text prompt in May 2025 consumed 0.24 Wh of energy, emitted 0.03 gCO2e, and consumed 0.26 mL of water.

The methodological contribution is the decomposition, not the total. Of the 0.24 Wh, 0.14 Wh is active accelerator draw, 0.06 Wh is host CPU and DRAM, 0.02 Wh is idle and reserve capacity, and 0.02 Wh is data centre overhead. That idle-capacity term is the part almost every prior estimate omits. Serving fleets must hold headroom for traffic spikes and failover; that headroom burns power whether or not a query arrives, and attributing it to queries is the honest accounting choice. Google also reports a 33x reduction in energy and a 44x reduction in carbon per median prompt over the preceding twelve months.

The caveats are equally important and Google states them. It is a median, not a mean, and the mean of a long-tailed distribution sits well above the median. It is text only — no image, video or audio generation. It is Google’s own TPU fleet, which is vertically integrated in ways that do not generalise to a company renting H100 capacity. And training is explicitly out of scope. Google had the instrumentation in 2025 and chose not to publish the training side.

A month later, a Microsoft team led by Felipe Oviedo published Energy Use of AI Inference, Efficiency Pathways, and Test-Time Scaling (arXiv:2509.20241, later Joule 2026). Using a bottom-up framework built from token throughput, node power and overhead under production deployment assumptions, they estimate a median of 0.31 Wh per query for frontier-scale models above 200 billion parameters on H100 nodes, with an interquartile range of 0.16–0.60 Wh. They conclude that widely cited estimates are overstated by 4–20x, and that grid strain comes “not from inference energy use, but from training loads, the rapid rate of AI adoption, and concentrated capacity build-up.”

Microsoft’s interest here is worth stating plainly, because it runs opposite to the one usually named. NVIDIA and AWS sell inference hardware and benefit from inference being understood as large and growing. Microsoft and Google operate the data centres taking the regulatory and permitting heat, and benefit from per-query figures being understood as small. Both sets of incentives are real. The Microsoft paper is also the one that most clearly documents the upside of the range: in test-time-scaling scenarios about 15x longer than a typical query, their median rises 13x to 3.91 Wh, with an IQR of 2.15–7.05 Wh and a significant portion above 10 Wh.

Why a single number stopped being meaningful

Two trends of comparable magnitude are running in opposite directions. Per-token efficiency is improving fast: Google’s 33x in twelve months, and Epoch AI’s finding that machine-learning hardware energy efficiency has been doubling roughly every two years. Workload intensity is rising at least as fast, because reasoning modes and agent loops multiply the number of model calls and tokens per human action.

The clearest measurement of that second trend comes from Zeke Hausfather’s August 2026 analysis of his own coding-agent logs. Over eight weeks he typed 1,138 prompts into Claude Code. Those prompts produced more than 14,000 distinct model calls and processed 3.2 billion tokens. Running the measured token counts through three independent published energy methodologies gives roughly 170 kWh, with a range of 70–330 kWh across methods — about 150 Wh per typed prompt, or roughly 600 times the energy of a median chat prompt. Around 96% of those tokens were cache reads, the agent re-processing its own accumulated context at each step.

Figure	Source	Model and workload	Date	Method	Boundary
2.9 Wh	de Vries, Joule 7(10), from SemiAnalysis	175B dense, GPT-3.5 class; 4,000 in / 2,000 out tokens	Oct 2023	Bottom-up estimate	GPU energy, scaled
0.3 Wh	Epoch AI (Josh You)	GPT-4o reference, ~100B active params, 500 output tokens	Feb 2025	Analytic FLOP model, H100, 10% utilisation, 1,500 W/GPU	Server level, self-described as pessimistic
0.34 Wh	Sam Altman, The Gentle Singularity	“average ChatGPT query”	Jun 2025	Not published	Unspecified
0.24 Wh	Elsworth et al., arXiv:2508.15734 (Google)	Median Gemini Apps text prompt	Aug 2025	Production fleet instrumentation	Accelerator + host + idle reserve + DC overhead
0.31 Wh (IQR 0.16–0.60)	Oviedo et al., arXiv:2509.20241 (Microsoft)	Frontier-scale >200B on H100 nodes	Sep 2025 / Jun 2026	Bottom-up from token throughput and node power	Node + overhead at production utilisation
3.91 Wh (IQR 2.15–7.05)	Oviedo et al., same paper	Test-time scaling, ~15x longer query	Sep 2025 / Jun 2026	Same framework	Same
0.05 → 50 Wh	IEA, Key Questions on Energy and AI (2026), Fig 2.1	Medium text gen → agentic plus reasoning	2025–2026	Compiled published benchmarks	GPU electricity only
~150 Wh per prompt (60–290)	Hausfather, The Climate Brink	Coding-agent sessions, measured logs	Aug 2026	Measured tokens × three published factors	Data centre electricity

Epoch AI’s own appendix makes the same point from the other direction: their 0.3 Wh reference case rises to about 2.5 Wh at 10,000 input tokens and about 40 Wh at 100,000. The variable that moves the answer most is not the model and not the chip. It is how much text the system processes, and that is a property of the workload, not the provider.

The water numbers and what scope each one covers

Water is where scope confusion does the most damage, because the same physical system produces two legitimate numbers that differ by roughly twentyfold, and almost nobody states which one they mean.

What the 500 ml paper actually says

The source is Pengfei Li, Jianyi Yang, Mohammad A. Islam and Shaolei Ren, Making AI Less “Thirsty” (arXiv:2304.03271, now published in Communications of the ACM, 2025). The sentence that travelled reads: GPT-3 needs to consume a 500 ml bottle of water “for roughly 10–50 medium-length responses, depending on when and where it is deployed.”

Two qualifications are in that sentence and both are routinely dropped. It is 10 to 50 responses, not one conversation. And the range is not uncertainty about the physics — it is geography, because the water intensity of both cooling and electricity generation varies enormously by location.

Table 1 of the paper gives the breakdown. For the US average case the paper assumes PUE 1.170, an on-site WUE of 0.550 L/kWh and an off-site electricity water intensity factor of 3.142 L/kWh, and derives per request: 2.200 mL consumed on site, 14.704 mL consumed off site at power stations, 16.904 mL in total — which is 29.6 requests per 500 ml bottle. On the on-site figure alone, a 500 ml bottle covers about 227 requests.

Figure 3: The scope boundary. On-site evaporation versus off-site generation water for one request, and where the reported WUE metric stops.

So roughly 87% of the famous figure is water evaporated at power stations, not at the data centre. That is not a criticism of the paper — it defines scope 1, 2 and 3 water explicitly in Section 2.2, in deliberate alignment with greenhouse-gas accounting convention, and reports all three columns. It is a description of what gets lost when the total is quoted without the scope.

The same table shows the location spread on identical assumptions about the model: Texas 7.590 mL per request against Arizona 29.926 mL — a factor of four inside one country. Washington state comes out at 47.506 mL, Ireland at 7.107 mL. Where a query is served changes its water footprint more than which model serves it.

The 519 ml email figure is a different study

A widely shared claim that a 100-word email costs 519 ml of water comes from a September 2024 Washington Post collaboration with UC Riverside researchers, modelling GPT-4. It is a different study, a different model and a different year from the CACM paper. Shaolei Ren, an author on both, has publicly stepped back from it: in correspondence with Sentient Media in August 2026 he described the 2024 GPT-4 estimate as time-specific and assumption-based, and said it should not be used to describe general AI systems or today’s optimised ones.

Current per-query water figures, side by side

Figure	Scope	Source	Basis
2.200 mL/request	On-site consumption (scope 1)	Li et al., Table 1, US average	GPT-3, PUE 1.170, on-site WUE 0.550 L/kWh
14.704 mL/request	Off-site generation (scope 2)	Li et al., same row	EWIF 3.142 L/kWh, location-based
16.904 mL/request	Total (29.6 requests per 500 ml)	Li et al., same row	Sum of the above
7.590 / 29.926 mL	Total, Texas / Arizona	Li et al., Table 1	Same model, different grid and climate
0.26 mL	On-site consumption only	Google, arXiv:2508.15734	(Total energy − overhead) × WUE 1.15 L/kWh
~0.32 mL	Unspecified	Altman, Jun 2025	No method published
~6.1 mL	Broader, includes off-site	EcoLogits calculator, 2026	ChatGPT-5.5, one email

Read as a set, these figures are less contradictory than they look. Around 0.3 mL is the right order of magnitude for on-site consumptive water on a modern fleet serving a short text prompt. Around 5–6 mL is defensible for a total that includes power-generation water. They differ by roughly twentyfold because they measure different things. Quoting “5 ml” without saying which reproduces exactly the ambiguity that produced the 500 ml claim in the first place.

What WUE excludes

Water usage effectiveness is defined as litres of site water per kilowatt-hour of IT energy, introduced by The Green Grid in White Paper #35 in 2011 and later standardised as ISO/IEC 30134-9. As universally reported it is a scope-1, on-site-only metric. It excludes all power-plant water by construction.

The Green Grid anticipated this. The same 2011 paper defined WUEsource, which adds the water embedded in electricity generation. Essentially nobody reports it. The size of the omission is measurable: US average electricity water consumption runs around 3.1 L/kWh, against typical on-site WUE values of 0.2–1.2 L/kWh. Meta’s own disclosure makes the gap concrete — a 2024 scope-2 water figure of 3.92 L/kWh against an on-site WUE of 0.19, roughly twenty-one to one.

Reported WUE values also are not comparable across operators, because they do not all measure the same physical quantity.

Operator	Reported WUE (2026)	Basis	Comparable to Google?
Google	1.15 L/kWh	Consumption, ISO Category 2, 2023 and 2024	—
Microsoft	0.27 (EMEA 0.03)	Withdrawal-style, wholly-owned sites only	No
Meta	0.19 (up from 0.18)	Withdrawal	No
AWS	0.12	Withdrawal	No

Withdrawal is water taken from a source; consumption is water that does not return to it. Google reports consumption and says it consumes roughly 80% of what it withdraws, so its withdrawal-basis number would be higher still — meaning the gap to the others is narrower than the table implies, in Google’s favour. Amazon’s marketing table claiming roughly sevenfold better water efficiency than Google, Microsoft and Meta stacks these incompatible quantities against each other.

Energy and water pull against each other

The trade-off that almost never appears in coverage is that low water use and low energy use are, in a data centre, largely opposed. Heat has to leave the building. Evaporative cooling does it cheaply in electricity and expensively in water. Mechanical refrigeration does it cheaply in water and expensively in electricity.

Figure 4: The cooling trade-off. Why a low WUE usually implies higher electricity draw, with two sites from one operator’s FY25 disclosure.

The operators say this themselves. Amazon states that chillers “typically require 25% to 35% more electricity” than evaporative approaches. Google has written that shifting to water cooling reduces energy consumption while “recognizing that this tradeoff will increase our data center water footprint.” Neither statement is a concession extracted by critics; both are in sustainability documentation.

Microsoft’s FY25 site-level table puts numbers on it. Dublin consumed 1,308,581 MWh with 18 megalitres of water. Singapore consumed 338,845 MWh with 423 megalitres. That is roughly 0.014 L/kWh against roughly 1.25 L/kWh — a ninetyfold difference in water intensity inside a single operator, driven by ambient climate and cooling design rather than by efficiency effort. A cool maritime climate permits free-air cooling for most of the year; a tropical one does not.

This is why cross-site WUE league tables are close to meaningless, and why a company can improve its reported WUE substantially by building in cold climates and worsen its electricity consumption at the same time. The honest framing is that cooling is a two-variable optimisation under a local constraint, and the carbon-aware scheduling techniques used in cloud FinOps and GreenOps face the same structure: moving a workload to improve one metric usually moves another.

What PUE does and does not tell you

Power usage effectiveness, standardised as ISO/IEC 30134-2 (second edition, 2026) and originating with The Green Grid in 2007, is total facility energy divided by IT energy. It has two structural problems that its own custodians acknowledge.

First, it measures overhead ratio, not useful work. Replacing efficient servers with inefficient ones improves PUE, because the denominator grows. Second, the boundary choice — UPS output, PDU output, or rack inlet — moves the reported value by 0.1 to 0.2 with no physical change to the facility. Uptime Institute’s 2026 report states that trade-offs between facility power, water, temperature setpoints and IT efficiency “are outside the scope of PUE,” and that the metric is best suited to evaluating a single site over time rather than comparing a small number of differing facilities.

Proposed successors exist — ITUE and TUE from Patterson and Poole at ISC 2013, plus CUE, REF and ERF for carbon, renewables and energy reuse. None has displaced PUE, largely because there is no standardised, cross-tenant way to measure useful IT work.

The 2026 values are worth recording. Uptime’s industry average is 1.52 across 644 respondents, up the efficiency curve from 1.54 in 2025 and 1.56 in 2024. Capacity-weighted, it falls to 1.36; facilities of 20 MW and above run around 1.44–1.45. Hyperscale figures are much lower: Google 1.09 fleet-wide for CY2025 with per-site values of 1.04–1.14, Meta 1.08 for CY2024, AWS 1.14 for CY2025, Microsoft 1.17 global for FY25. Microsoft’s number went up from 1.16 in FY24, which the company attributes to new capacity not yet running at full load. That regression is a useful complication: efficiency does not improve monotonically when you are building fast.

Training versus inference: four bodies, four answers

Whether AI electricity is mostly training or mostly serving is genuinely unresolved, and the most-cited claims on the subject are the weakest.

The statements that “NVIDIA says inference is 80–90%” and “AWS says inference is 90%” are about money, date from 2019, predate large language models, and come from vendors selling inference hardware. The NVIDIA claim traces to a single HPCwire paraphrase of a GTC 2019 keynote aside about the cost of machine learning at scale; there is no NVIDIA publication and no method. The AWS claim is live marketing copy on the Inferentia product page, phrased as “up to 90% of the infrastructure spend” being on inference, sourced to unnamed customers, on a page selling an inference chip.

The only published first-party measured energy splits are older and narrower than the debate they are used to settle. Patterson and colleagues (arXiv:2204.05149, 2022) report that machine learning was 10–15% of Google’s total energy across 2019–2021 despite being 70–80% of its FLOPS, and that “about 3/5 of ML energy use is for inference and 2/5 for training.” That is one week of sampling per year, Google-specific, and predates serving LLMs at scale. Meta’s Wu et al. (MLSys 2022, arXiv:2111.00364) report roughly 65% inference and 35% training by carbon for language models, and about 50/50 for recommenders. Nothing published since has replaced either.

The best current estimate for the installed US fleet comes from LBNL’s 2025 Update (June 2026), which assumes around 35% of US AI-server power went to training in 2024, falling to about 20% by 2030 — implying roughly 65% inference now and 80% by 2030. That should be quoted with its provenance: it is an Omdia market-research assumption imported into an energy model, not a measurement, and LBNL explicitly notes a lack of verifiable data to confirm typical inference utilisation levels.

Epoch AI dissents, stating that training and inference currently receive comparable compute. And the IEA offers an arithmetic check that cuts against strong inference dominance: at roughly 1 Wh per query and 10 billion queries per day, global text inference comes to about 3.6 TWh per year — under 1% of the 485 TWh data centres consumed in 2025. The IEA’s conclusion is that the capacity build-out must be destined for other workloads.

These positions reconcile more easily than the coverage suggests. Frontier laboratories, where the largest runs happen, are training-heavy. The installed global fleet, dominated by serving, is inference-heavy. Both statements can be true simultaneously because they describe different denominators. Most articles present them as a contradiction.

What training actually costs, where it is disclosed

Model	Training energy	Carbon	Status
GPT-3	1,287 MWh (PUE 1.10 already included)	552.1 tCO2e	Third-party estimate, Patterson et al. 2021
BLOOM-176B	433 MWh	24.7 t operational / 50.5 t full LCA	Disclosed
Llama 2 (all sizes)	1,325 MWh	539 t	Disclosed
GPT-4	~43 GWh at 2.1e25 FLOP	Not published	Epoch estimate
Llama 3.1 405B	21,588 MWh (30.84M H100-hours)	8,930 t location-based	Disclosed
DeepSeek-V3	~1,950 MWh	Not published	Derived from disclosed GPU-hours
Llama 4 Scout + Maverick	5,166 MWh	1,999 t	Disclosed
Grok 3	~238 GWh	Not published	Epoch estimate, ~110 MW × ~90 days
GPT-5, Gemini 3, Claude 4.x	—	—	Nothing disclosed

Several traps sit in this table. The GPT-3 row is Google’s estimate of OpenAI’s run, with the chip count taken from an NVIDIA press release and the power and PUE figures obtained by personal communication; OpenAI has never published it. Its PUE of 1.10 is already applied, so the GPU-only figure of roughly 1,170 MWh must not be multiplied again. And the 552 tCO2e is weaker than the energy number, because the 0.429 kg/kWh carbon intensity is a 2020 US national average rather than the actual grid the run used.

Two further figures should never appear alongside these. The famous 284 tCO2e / 626,155 lbs number is from Strubell et al. 2019 and describes neural architecture search, not GPT-3 — Strubell predates GPT-3 entirely, and Patterson’s section 4.1 shows that estimate was 18.7x too high against an actual 7.5 MWh and 3.2 tonnes. Separately, Mistral Large 2’s 20.4 ktCO2e is a full life-cycle assessment including eighteen months of inference and embodied emissions; it belongs in a different column from Patterson’s operational 552 t.

The Llama 3.1 405B row carries its own trap. The claim that it emitted zero carbon is a market-based figure reflecting renewable energy certificate purchases. The location-based figure, which reflects the physical grid, is 8,930 tonnes.

The safe framing on trend: frontier training compute has grown roughly 1,000–1,600x since GPT-3, while training energy has grown less — on the order of 100–200x — because chip efficiency has improved around 40% a year. In absolute terms the frontier has moved from about 1 GWh to a few hundred GWh per run. Epoch’s own tracking puts frontier training compute growth at 4–5x per year and training power at 2.2x per year, with the largest runs now exceeding 100 MW and projections of 4–16 GW single runs by 2030.

Aggregate demand and what the grid data shows

The aggregate numbers rest on better evidence than the per-query ones, and they are also where the language gets loosest.

The IEA’s Energy and AI Box 2.1 states that accelerated servers accounted for 24% of server electricity demand and 15% of total data centre demand in 2024. The IEA itself calls the accelerated-server share a second-best approach and an imperfect proxy, and notes that direct estimates of AI’s share vary widely. The widely repeated “14%” does not appear in any primary source I could find.

The IEA’s 2026 update puts global data centre consumption at 485 TWh in 2025, rising to about 950 TWh by 2030 — roughly 1.5% to 3% of world electricity. AI-focused data centres more than triple to around 465 TWh by 2030. Data centre demand grew 17% in 2025; AI-focused demand grew 50%.

For the United States, LBNL’s 2024 report put consumption at 176 TWh in 2023, or 4.4% of national electricity, with a 2028 range of 325–580 TWh (6.7–12%). The 2025 Update revises to 192 TWh (4.7%) for 2024 and projects 649 TWh (11.8%) by 2030, with a range of 521–843 TWh, or 9.5–15.3%. EPRI’s 2026 projection is 9–17% by 2030. The spread between those bounds is larger than the entire current consumption of several countries, which is itself the finding.

Grid stress is the best-evidenced part of the whole story because it shows up in regulated filings. ERCOT reported more than 233 GW of large-load interconnection requests as of December 2025, over 70% of it data centres. PJM capacity auctions have cleared at the price cap three years running, and PJM attributes roughly 97% of near-term peak-load growth to data centres. PJM’s Independent Market Monitor ran a counterfactual concluding that data centre load added $23.1 billion across three auctions, including 65.5% of the 2027/28 auction cost. Four regulatory firsts landed in 2026: a New York moratorium in July, a Texas interconnection pause pending an ERCOT audit in August, a FERC show-cause order covering all RTOs in June, and a NERC Level 3 Alert in May.

On retail electricity prices the evidence is genuinely contested, and both sides have funders worth naming. The frequently quoted “8% nationally, 25% regionally” figure is a Carnegie Mellon forward simulation — not peer-reviewed, and not a measurement of anything that has happened. LBNL and Brattle’s Retail Electricity Price Trends 2026 finds that over 2019–2025, states with the largest data centre demand growth generally saw electricity price decreases, with PJM as the exception. And the counter-analysis arguing for lower attribution of price increases to data centres, by consultancy E3, was funded by the Data Center Coalition. Each of those three should be read with its sponsor in view.

Trade-offs, gotchas, and what goes wrong

The most common failure in this literature is not a wrong number. It is a correct number pulled across a boundary it was never defined on.

Double-counting PUE. Patterson’s GPT-3 figure of 1,287 MWh already includes facility overhead at PUE 1.10. Several secondary sources multiply it again. The same happens with per-query figures: Google’s 0.24 Wh already contains its 0.02 Wh of data centre overhead, so applying a PUE multiplier on top inflates it.

Mixing market-based and location-based carbon. A model trained on certificates-backed power can be reported at near-zero emissions while the physical grid burned gas to serve it. Llama 3.1 405B is the clearest case: zero market-based, 8,930 tonnes location-based. Both are legitimate accounting; putting them in one table is not.

Comparing withdrawal to consumption. Every WUE league table in circulation does this. It is the water equivalent of comparing revenue to profit.

Operational figures against life-cycle figures. Mistral Large 2’s 20.4 ktCO2e includes embodied emissions and eighteen months of serving. Patterson’s 552 t for GPT-3 is operational training only. The ratio between them says nothing about the two models.

Everyday comparisons built on nameplate ratings. The “an AI query is like running an oven for X seconds” genre usually assumes an electric oven consumes about 4 kWh per hour. That is three to five times too high, and the error is the classic one of treating a kilowatt nameplate rating as kilowatt-hours consumed at a 100% duty cycle. Domestic ovens are rated 2.0–3.5 kW but draw full power only during a roughly 15–20 minute preheat, after which thermostat cycling averages around 1–1.5 kW. The EU energy label standard cycle under EN 60350-1 gives 1.09 kWh conventional and 0.79 kWh fan-forced on a real 2025 product fiche; the EU market average for new ovens works out to about 0.76 kWh per cycle. Roughly 1 kWh per hour is the defensible figure, with pyrolytic self-clean cycles and commercial-style double ovens as genuine exceptions above 3 kWh/h.

Steel comparisons that hide their route. The claim that GPT-3’s 1,287 MWh equals about 2,500 tonnes of steel implies 514.8 kWh per tonne. That only works as electric-arc-furnace melting electricity at the top of its range. On whole-site electricity for scrap-EAF (600–680 kWh/t) it is 1,893–2,145 tonnes; on total onsite EAF energy (DOE’s 6.1 GJ/t) it is 760 tonnes; on the worldsteel global all-route average of 20.95 GJ/t it is about 221 tonnes. There is also a category error underneath, since 70–80% of blast-furnace energy arrives as coke acting as a chemical reductant rather than as heat, and roughly 72% of world crude steel is still blast-furnace route.

Laundry comparisons are the one that holds up. Around 50 litres per wash is well supported: EU Eco 40-60 at full load registers 43 L for an 8 kg A-rated machine and 48 L for a 9 kg Miele, and US ENERGY STAR full-sized machines average 53 L with front-loaders at 47 L. The caveat is that EU label figures describe the most efficient cycle at full rated load, and older top-load agitator machines run 114–151 L.

Practical recommendations

If you need to quote a per-query figure in a document that will be read critically, the useful discipline is to carry the scope with the number every time, in the same sentence.

For energy, state the workload class and the boundary. “0.24 Wh for a median Gemini text prompt including idle reserve and facility overhead” is a claim someone can check. “0.24 Wh per AI query” is not, because it silently generalises a text median to reasoning and agent workloads that measure one to three orders of magnitude higher.

For water, state on-site or total, and state the region. Around 0.3 mL is right for on-site consumptive water on a modern fleet serving short text; around 5–6 mL is defensible for a total including generation water; the Li et al. US-average GPT-3 case is 2.200 mL on site and 16.904 mL total. Those are all correct and they are not interchangeable.

For anything aggregate, prefer the regulated filings. Interconnection queues, capacity auction results and utility rate cases are audited, public and dated. They are far stronger evidence than any per-query estimate, and they are the part of the story where the numbers are not seriously disputed.

A short checklist before publishing a figure:

• Name the model or model class, the date, and the workload type.
• State the measurement boundary explicitly — GPU only, node, or full facility.
• For water, say on-site or total, and name the region.
• Check whether PUE is already applied before applying it.
• Keep market-based and location-based carbon in separate columns.
• Carry the range or IQR, not just the central value.
• Name who funded or published the estimate, on every side.
• If the figure is an estimate rather than a measurement, say so in the same sentence.

For teams choosing models rather than reporting on them, the workload lever is larger than the vendor lever: routing simple tasks to smaller models changes per-token energy by roughly five to sevenfold, which is the practical argument behind small language models running on CPU inference.

What would actually settle these questions

Several of the disagreements above are not philosophical. They would close if specific measurements existed.

A second production measurement, from a company renting capacity. Google’s paper is the only one of its kind, and Google owns its silicon, its fleet and its facilities. A comparable instrumented study from a laboratory serving on rented H100 or GB200 capacity would tell us whether 0.24 Wh reflects the state of the art or reflects vertical integration.

Per-workload distributions, not medians. Every operator that publishes a median knows the full distribution. Publishing the 50th, 90th and 99th percentiles, split by text, image, reasoning and agentic traffic, would replace the entire single-number argument with a chart. The Microsoft paper’s IQRs are a partial step; nobody has published the tail.

Training energy from a frontier lab. GPT-5, Gemini 3 and Claude 4.x have disclosed nothing. Every frontier training figure after Llama 3.1 is an outside estimate derived from chip counts and press releases. The labs have the meter readings.

WUEsource, as The Green Grid defined it in 2011. Every operator already computes scope-2 water for its sustainability report. Reporting it as a per-kWh ratio alongside on-site WUE would end the withdrawal-versus-consumption confusion at essentially zero cost.

A cross-tenant measure of useful IT work. This is the hard one, and it is why PUE has survived nineteen years of criticism without a successor. Until there is a standardised unit of work in the denominator, every facility efficiency metric will measure overhead rather than output.

Independent verification of inference utilisation. LBNL says plainly that it lacks verifiable data on typical inference utilisation levels, and that assumption drives the training-versus-inference split in the most-cited US projection. A survey of measured accelerator utilisation across operators would replace a market-research assumption with data.

Until those exist, the honest position is the one the numbers themselves support: the per-query figures are converging in a narrow band for short text prompts, diverging sharply across workload types, and resting on a single production measurement; the aggregate figures are well evidenced and widely dispersed in their projections; and the transmission of both into public discussion has consistently dropped the scope qualifiers that made them meaningful.

Frequently Asked Questions

How much energy does one ChatGPT query use?

No measurement exists for ChatGPT specifically. The nearest production measurement is Google’s, which puts the median Gemini Apps text prompt at 0.24 Wh including accelerator, host, idle reserve and facility overhead. Microsoft’s bottom-up estimate for frontier-scale models is 0.31 Wh with an interquartile range of 0.16–0.60 Wh. Sam Altman stated 0.34 Wh in June 2025 without publishing a method. All three describe short text prompts, not reasoning or agentic workloads.

Does ChatGPT really use 500 ml of water per conversation?

The source paper says a 500 ml bottle covers roughly 10 to 50 medium-length responses for GPT-3, depending on when and where it runs. In the US-average case it is 29.6 requests per bottle. Of the 16.904 mL per request, 2.200 mL is evaporated at the data centre and 14.704 mL is consumed at power stations. On the on-site figure alone, one bottle covers about 227 requests.

Why do published AI energy per query figures differ so much?

Three reasons. Boundary: some count GPU electricity only, others add host, idle reserve and facility overhead. Workload: the IEA’s 2026 benchmark ladder spans 0.05 Wh for medium text generation to 50 Wh for agentic plus reasoning. Date: efficiency is improving fast, with Google reporting a 33x reduction per median prompt in twelve months. A figure without all three qualifiers cannot be compared to another one.

What does water usage effectiveness actually measure?

WUE is litres of site water per kilowatt-hour of IT energy, defined by The Green Grid in 2011 and standardised as ISO/IEC 30134-9. As reported it covers scope-1 on-site water only and excludes water consumed generating the electricity. US average electricity water consumption is around 3.1 L/kWh against on-site WUE values of 0.2–1.2 L/kWh, so the excluded portion is typically several times larger than the reported one.

Is AI electricity mostly training or mostly inference?

It depends which fleet you mean, and the sources genuinely disagree. LBNL’s 2025 Update assumes about 35% training in 2024 falling to 20% by 2030. Epoch AI says training and inference receive comparable compute. Google measured roughly 3/5 inference in 2019–2021 and Meta about 65% inference for language models in 2022. Frontier laboratories are training-heavy; the installed global fleet is inference-heavy. Both can be true.

Do low-water data centres use more electricity?

Generally yes, and operators say so. Amazon states that chillers typically require 25% to 35% more electricity than evaporative cooling, and Google has written that water cooling reduces energy while increasing its water footprint. Microsoft’s FY25 disclosure shows Dublin at 1,308,581 MWh with 18 ML of water against Singapore at 338,845 MWh with 423 ML — roughly a ninetyfold water-intensity gap driven by climate and cooling design.

Further Reading

• Industrial AI inference carbon footprint benchmarks — how per-inference carbon is measured for edge and factory-floor workloads.
• AI data centre power, the grid, and the nuclear question — the build-out and interconnection side of the same story.
• FinOps, GreenOps and carbon-aware scheduling — moving workloads in time and space to cut both cost and emissions.
• Small language models on CPU inference, compared — the model-size lever, which moves per-token energy further than most infrastructure choices.
• Measuring the environmental impact of delivering AI at Google Scale — the only production measurement of AI serving energy, carbon and water in the public record.
• Making AI Less “Thirsty” — the original water-footprint methodology, including the Table 1 breakdown quoted throughout this post.

References

Every figure quoted above, with the source it came from. Where a number reached the public through an intermediary, both links are given so the chain can be checked.

Per-query energy

1. Elsworth, Huang, Patterson, Dean, Vahdat, Manyika et al., Measuring the Environmental Impact of Delivering AI at Google Scale, arXiv:2508.15734, 21 August 2025 — https://arxiv.org/abs/2508.15734. The 0.24 Wh / 0.03 gCO2e / 0.26 mL median Gemini text prompt, and the full-stack boundary including idle reserve capacity.
2. Oviedo et al. (Microsoft), Energy Use of AI Inference: Efficiency Pathways and Test-Time Scaling, arXiv:2509.20241; published in Joule (2026) — https://arxiv.org/abs/2509.20241. The 0.31 Wh median, the 4–20× overstatement finding, and the 3.91 Wh test-time-scaling median.
3. Josh You, How Much Energy Does ChatGPT Use?, Epoch AI Gradient Updates, 7 February 2025 — https://epoch.ai/gradient-updates/how-much-energy-does-chatgpt-use. The 0.3 Wh estimate, its stated assumptions, and the long-context appendix values.
4. de Vries, A., The Growing Energy Footprint of Artificial Intelligence, Joule 7(10):2191–2194, 2023 — https://www.cell.com/joule/fulltext/S2542-4351(23)00365-3. The origin of the 2.9 Wh figure.
5. EPRI, Powering Intelligence: Analyzing Artificial Intelligence and Data Center Energy Consumption, May 2024 — https://restservice.epri.com/publicdownload/000000003002028905/0/Product. Where the 2.9 Wh figure is quoted (reference 47) rather than produced.
6. Sam Altman, The Gentle Singularity, June 2025 — https://blog.samaltman.com/the-gentle-singularity. The 0.34 Wh and ~0.32 mL claims, published without methodology.
7. IEA, Key Questions on Energy and AI, April 2026, Figure 2.1 — https://www.iea.org/reports/key-questions-on-energy-and-ai. The 0.05 → 50 Wh workload ladder, its named benchmark models, and the IEA’s own order-of-magnitude caveat.

Water

8. Li, Yang, Islam & Ren, Making AI Less “Thirsty”, arXiv:2304.03271; published in Communications of the ACM, 2025 — https://arxiv.org/abs/2304.03271 and https://dl.acm.org/doi/10.1145/3724499. Table 1’s on-site / off-site / total split and the “10–50 medium-length responses” sentence.
9. Sentient Media, ChatGPT’s Water Use: What Uses More?, August 2026 — https://sentientmedia.org/chatgpts-water-use-what-uses-more/. Shaolei Ren’s statement that the 2024 GPT-4 email estimate “should not be used to describe general AI/ChatGPT or today’s optimized systems.”

Training

10. Patterson et al., Carbon Emissions and Large Neural Network Training, arXiv:2104.10350, 2021 — https://arxiv.org/abs/2104.10350. Table 4’s 1,287 MWh / 552.1 tCO2e for GPT-3, and section 4.1’s correction of the earlier NAS estimate.
11. Patterson et al., The Carbon Footprint of Machine Learning Training Will Plateau, Then Shrink, arXiv:2204.05149, 2022 — https://arxiv.org/abs/2204.05149. Google’s measured three-fifths inference / two-fifths training energy split.
12. Wu et al., Sustainable AI: Environmental Implications, Challenges and Opportunities, MLSys 2022, arXiv:2111.00364 — https://arxiv.org/abs/2111.00364. Meta’s 65/35 inference-to-training carbon split for language models.
13. Epoch AI, Power Demands of Frontier AI Training — https://epoch.ai/publications/power-demands-of-frontier-ai-training. Training compute and power growth rates, and the projection to multi-gigawatt runs.

Aggregate demand and grid

14. IEA, Energy and AI, April 2025, Box 2.1 — https://www.iea.org/reports/energy-and-ai/energy-demand-from-ai. The accelerated-server proxy and the IEA’s own caution about it.
15. Shehabi et al., 2024 United States Data Center Energy Usage Report, Lawrence Berkeley National Laboratory, December 2024 — https://eta-publications.lbl.gov/sites/default/files/2024-12/lbnl-2024-united-states-data-center-energy-usage-report_1.pdf.
16. Lawrence Berkeley National Laboratory, 2025 Update to the United States Data Center Energy Usage Report, June 2026 — https://escholarship.org/uc/item/33m6w3x0. The 192 TWh (2024) → 649 TWh (2030) range and the training-share assumption.

Efficiency metrics and everyday comparisons

17. The Green Grid, Water Usage Effectiveness (WUE): A Green Grid Data Center Sustainability Metric, White Paper #35, 2011 — the origin of both WUE and the rarely-reported WUEsource.
18. Uptime Institute, Global Data Center Survey 2026 — the 1.52 industry-average and 1.36 capacity-weighted PUE figures, and Uptime’s own statement of PUE’s limits.
19. worldsteel, Energy Use in the Steel Industry — https://worldsteel.org/about-steel/energy-use-in-the-steel-industry/. The 20.95 GJ/t global average used to recalculate the steel comparison.
20. European Commission, Domestic Ovens product database (EN 60350-1 standard cycle) — https://energy-efficient-products.ec.europa.eu/product-list/domestic-ovens_en. The ~1 kWh per cycle figure.
21. ENERGY STAR, Clothes Washers — https://www.energystar.gov/products/clothes_washers. The ~50 L per load figure.

By Riju — about