Session 4 — the physical substrate of scale
Capability is bought with compute; compute is bought with energy, water, hardware and minerals. Why a safety course counts kilowatts: compute is the capability floor, which makes it the main governance lever (Session 12), and its costs fall unevenly, disproportionately on the Global South.
This session's sub-sessions: 4.1 the cost of every prompt · 4.2 infrastructure & the rebound problem · 4.3 critical minerals · 4.4 sustainable & sovereign AI.
What we'll cover
Every time you send a message to an AI assistant, something physical happens: electricity flows through data-centre hardware on the other side of the world. This session puts numbers on that to help you think clearly about its environmental implications as a researcher and as a citizen.
We will look at energy consumption from the level of a single query up to the scale of global AI usage, at water (an environmental cost that receives less attention than carbon), and at why the numbers you read in the media should always be treated with careful scepticism.
This is a topic where the data are uncertain and where companies have strong incentives to present their products in the best possible light. Part of our job here is to understand why the numbers are uncertain.
Mandatory readings
Nature (2024): "Generative AI’s environmental costs are soaring — and mostly secret": a Nature commentary on why accurate environmental data is so hard to get from AI companies. A good starting point for understanding the transparency problem. ≈1,000 words.
Li, Yang, Islam, Ren (2023): "Making AI Less Thirsty": the most-cited quantitative analysis of AI water consumption. Read the paper, not just the media coverage of it; the estimation methodology is §3 ("Estimating Water Footprint of AI Models"), with the GPT-3 case study in §3.3. ≈5,500 words.
Total mandatory load: ≈6,500 words.
Optional readings
MIT Technology Review (2025): "We did the math on AI’s energy footprint. Here’s the story you haven’t heard.": independent measurements of open-source models providing a useful counterpoint to company-reported figures, and the source for several of the energy estimates in this page's tables.
Luccioni et al. (2023): "Power Hungry Processing: Watts Driving the Cost of AI Deployment?": benchmarks inference energy across a wide range of NLP tasks and model types.
A note on numbers throughout this session
Almost all figures in this area come from one of three sources: company self-reports, independent academic estimates, or media extrapolations from those estimates. These often disagree substantially. Throughout these lessons we will flag where figures come from and what assumptions they rest on. Treat any specific number as an order-of-magnitude guide rather than a precise measurement.
The transparency problem
Before we look at any numbers, it is worth understanding why getting accurate figures is so difficult, because the answer shapes how we interpret everything that follows.
Undisclosed company data
Major AI developers (OpenAI, Google, Meta, Microsoft, Anthropic) do not publish detailed energy or emissions data for individual models. What is typically missing:
- Energy consumed per query (by model type or size)
- Data centre locations and their grid carbon intensity
- Water consumption at specific facilities
- Hardware lifecycle data (manufacturing emissions)
- Total annual compute for model training
Some companies publish aggregate sustainability reports, but these cover their entire operations, not AI specifically, and rely on accounting methods that can obscure more than they reveal.
Indirect estimation methods
In the absence of direct data, researchers use indirect methods to estimate AI's environmental footprint:
- Hardware benchmarks: Measure energy use of known GPUs, estimate utilisation rates
- Open-source proxies: Run open-weight models locally and measure directly
- Architectural inference: Use known model sizes and FLOPs estimates to project energy
- Company disclosures: Use reported figures with appropriate scepticism about representativeness
This is why published estimates for the same model can differ by a factor of 10 or more.
Energy per interaction
Let's start at the level of a single query. How much electricity does it take to generate one response?
Energy consumption by task type
The table below combines company-reported figures and independent measurements from MIT Technology Review (2025). Note the wide ranges: these reflect real differences in model size, hardware, and methodology, not just uncertainty.
| Task | Energy estimate | Everyday comparison | Source / confidence |
|---|---|---|---|
| Google Search query | ~0.3 Wh | 108 seconds of a 10 W LED | Google; moderate confidence |
| ChatGPT text prompt (reported) | 0.34 Wh | 122 seconds of a 10 W LED | OpenAI blog, June 2025; likely best-case |
| Gemini text prompt (reported) | 0.24 Wh | 8.6 seconds of a 100 W TV | Google White Paper, 2025; likely best-case |
| Large model text prompt (independent) | 0.1–8 Wh | 0.36–28.8 seconds of a 1 kW microwave | Independent open-weight measurements, 2025 (MIT Technology Review and others) |
| AI image generation | ~2–5 Wh | 7.2–18 seconds of a 1 kW microwave | Various; moderate confidence |
| AI video generation (5 seconds) | ~3.4 MJ (~944 Wh) | Approximately 57 minutes of a 1 kW microwave | MIT Technology Review, 2025; ~700× image cost |
Text generation and video generation are not in the same ballpark: they differ by roughly three orders of magnitude. Company-reported figures for text prompts are at the lower end of independent measurements, likely reflecting optimised infrastructure not available to all deployments.
Video generation
The energy cost of generating a 5-second AI video (~944 Wh, per MIT Technology Review 2025) is not a typing error. High-resolution video generation involves running a very large diffusion model many times over, the equivalent of generating hundreds or thousands of images sequentially and combining them. This figure comes from measuring open-source video generation models; proprietary models like Sora may differ.
For context: 944 Wh is roughly one-seventh of what an average South African household uses in a day (around 6–7 kWh): a meaningful amount for a few seconds of video, but still a fraction of daily household use.
The agentic multiplier: tools like Claude Code
The figures above describe a single prompt: you ask, the model answers once. But the way many researchers now use AI is very different. Agentic tools (Claude Code, Codex, Cursor's agent mode, Gemini CLI) do not answer once. They run a loop: read files, call tools, run code, read the output, reason about it, and call the model again, often dozens of times to complete one task. Energy use scales roughly with the total number of tokens the model processes, so an agentic task can cost many times more than a single chat prompt. This section tries to put bounds on "how much more", and, as with everything in this lesson, the answer is a wide range.
From prompt measurements to workloads
Reported per-prompt figures do not determine the footprint of a research workflow. Agentic tasks can involve different numbers of calls, context lengths and generated tokens. The exercise below asks you to define those inputs and identify the measurements you would need.
Calculation inputs and their sources
Define calls per task and tasks per day, then find an energy estimate appropriate to the calls. Keep workload assumptions separate from measured quantities.
Per-task energy depends on model, hardware, batching, input and output lengths, caching and the number of model calls. A multiplier measured in tokens is not automatically an energy multiplier. In particular, do not multiply a long-context call estimate by a token multiplier that already includes the same context overhead.
Exercise: estimate a defined workload
Work in pairs for 15 minutes. Choose one task and record the model, calls per task, input and output tokens per call, cached tokens if known, and the date. Separate measurements from assumptions. Use an energy estimate only if its workload and accounting boundary are documented.
If a matching measurement gives a mean of e Wh per call, a task has n calls and a day has m tasks, the estimate is E = e × n × m / 1000 kWh per day. If calls differ substantially, sum their energies instead. Multiply by a stated grid factor in kg CO₂/kWh to estimate operational emissions. Report separately whether facility overhead or hardware manufacture is included.
As an arithmetic check, assume 2 Wh per call, 10 calls per task and 20 tasks per day. This gives 0.4 kWh per day. These are exercise inputs, not a measured typical working day. Vary each input separately, then give a range and identify which missing measurement would narrow it most.
Submit your assumptions, calculation and a short explanation of why token usage alone cannot determine the footprint. Compare with a household only after stating its measured daily consumption and location.
Implications for researchers
The per-prompt footprint of AI is small. The footprint of agentic AI is larger because there are so many steps. The same property that makes these tools powerful for research (they keep working autonomously) is what drives their energy use.
This connects directly to the rebound problem we examine in the next session: as agentic tools make each task cheaper and easier, we tend to run far more of them. The individual cost falls; the total can still rise. The responsible choice is to use the right effort level for the job, and to be honest about how uncertain the numbers are.
A worked example: the flight comparison
A common comparison in media coverage: how does using AI compare to taking a transatlantic flight? Let's work through this carefully, because how you do the calculation matters enormously.
Step-by-step calculation
Reference point: one economy-class transatlantic flight (London → New York, ~5,540 km)
- CO₂ per passenger (direct emissions only): ~0.5 tonnes
- Including radiative forcing at altitude (contrails, water vapour): roughly doubles the climate impact
- Commonly used estimate: ~1 tonne CO₂e per passenger
- Note: figures from different calculators range from 0.5 to 1.5 tonnes; this is itself uncertain
Carbon per ChatGPT text prompt:
| Energy assumption | Source | CO₂ per prompt (US grid avg: 0.386 kg/kWh) |
Calls to match 1-tonne flight |
|---|---|---|---|
| 0.34 Wh | OpenAI (reported, 2025) | 0.13 g CO₂ | ~7.6 million |
| 2 Wh | Mid-range independent estimate | 0.77 g CO₂ | ~1.3 million |
| 8 Wh | Large model, independent measurement | 3.1 g CO₂ | ~323,000 |
Depending entirely on which figures you use, one transatlantic flight equals somewhere between 300,000 and 7.6 million ChatGPT text queries. That spread reflects the difference between company-optimised infrastructure and real-world large-model deployments, as well as uncertainty about what "a ChatGPT query" even means in terms of model size and compute.
The two-order-of-magnitude spread
That this calculation can produce answers spanning two orders of magnitude is itself the finding. It tells us that glib comparisons ("ChatGPT = X flights per day") depend almost entirely on unstated assumptions, and that the opacity of AI companies makes it impossible to pin down a single answer.
As researchers, the appropriate response is to present the range and to push for better disclosure, rather than picking the number that fits our preferred narrative.
AI’s share of global emissions
The per-query comparison above is useful for personal calibration, but it can’t tell you what share of global emissions AI represents. For that, you have to layer estimates from primary sources and be honest about what is measured versus modelled.
A back-of-envelope: AI vs aviation
Step 1 — Inputs (primary sources):
- Data centres ≈ 1.5% of global electricity (≈ 415 TWh in 2024). IEA, Energy and AI (2025).
- AI-focused share ≈ 0.5% of global electricity (2025). Hannah Ritchie’s estimate from the IEA inputs, in her 2025 summary at Sustainability by Numbers (2026).
- Electricity & heat ≈ 40% of energy-related CO2; energy-related CO2 ≈ 85–90% of total CO2. IEA / Our World in Data sectoral breakdown.
Step 2 — Calculation: If AI’s electricity were at average grid carbon intensity, AI’s share of energy-related CO2 ≈ 0.5% × 40% ≈ 0.2%. AI loads are concentrated in the US (gas-heavy) and China (coal-heavy), pushing intensity above average; the largest operators’ renewable and nuclear procurement pulls below it (though annual matching overstates hourly cleanliness). Net plausible range: 0.2–0.4% of energy-related CO2, or roughly 0.15–0.35% of total CO2 / GHG depending on denominator.
Step 3 — The aviation benchmark. Aviation accounted for 2.5% of global energy-related CO2 in 2023 (≈ 950 Mt). IEA, Aviation. Passenger flights are ≈ 81% of that and freight ≈ 19%, so passenger aviation ≈ 2% of global CO2.
In sum: Passenger air travel emits roughly 6–10× what AI does operationally right now. AI is around a tenth to a fifth of aviation’s footprint at the system level.
Two caveats sharpen the comparison further:
- Aviation’s real impact is larger than the CO2 alone. Non-CO2 effects (contrails and NOx at altitude) push aviation’s share of anthropogenic warming closer to 3.5–4% (Lee et al. 2021, Atmospheric Environment). The gap on a warming basis is wider than the gap on a CO2 basis.
- Aviation is concentrated; AI use is broadly distributed. Only ≈ 11% of the world’s population flew in 2018, and the most frequent ≈ 1% account for more than half of passenger-flight emissions (Gössling & Humpe 2020, Global Environmental Change). AI use is becoming more broadly distributed, which makes the per-person picture different from the per-person flight picture even when the system-level numbers sit in the same neighbourhood.
And the ratio is narrowing. The IEA projects data-centre electricity roughly doubling from approximately 415 TWh (2024) to approximately 945 TWh (2030, ≈ 3% of global electricity), with the AI-optimised slice more than quadrupling, the fastest-growing part of that load. Even so, the IEA projects data-centre CO2 staying under ≈ 1.5% of energy-sector CO2 (≈ 300 Mt by 2035). AI would need several-fold growth relative to aviation to close the gap.
Reading these numbers
These are layered estimates, not audited measurements. The 0.2–0.4% calculation rests on three assumptions, each with its own uncertainty: (a) the IEA’s 1.5% data-centre figure, (b) Hannah Ritchie’s one-third allocation to AI specifically, and (c) average grid intensity. Treat the headline as a well-reasoned estimate from primary sources, not as a measurement; the same scepticism the rest of this lesson asks you to apply to vendor claims applies to careful third-party estimates too.
The figures also exclude embodied emissions: chip fabrication, server manufacture, data-centre construction (concrete, steel). 4.2 and 4.3 return to those in detail, because lifecycle accounting can raise the operational number materially. And the definition of “AI” versus general accelerated compute is itself fuzzy: not every workload on a GPU is what most people mean by AI.
The water footprint
Energy gets most of the attention, but water is the environmental cost of AI that is least reported and least understood. Data centres are thirsty in two distinct ways.
Direct water use: cooling
Modern data centres generate enormous amounts of heat. The most common solution is evaporative cooling: running water over heat exchangers where it evaporates, carrying heat away.
- Water is used rather than air because evaporative cooling is far more energy-efficient at the temperatures involved
- The water is usually filtered municipal supply: minerals in unfiltered water would corrode and clog sensitive hardware, so most large data centres use high-quality drinking water
- A 100 MW data centre may consume the equivalent of ~2,600 households' daily water use (IEA estimate)
- US data centres directly consume roughly 17.5 billion gallons of water per year, about 0.3% of the US public water supply (Lawrence Berkeley National Laboratory, 2024)
Indirect water use: electricity
Generating electricity also consumes water, at the power plant rather than the data centre. This "indirect" water use is often larger than the direct cooling water.
- Thermal power plants (coal, gas, nuclear) use water for steam generation and cooling
- This water is often not returned to its source; it is evaporated or discharged at a different temperature
- A commonly cited estimate (Shaolei Ren, UC Riverside): a ~30-turn ChatGPT conversation = roughly 500 ml of water, of which only 12–13% is direct cooling water; the rest is from electricity generation
- Water extracted in arid regions has very different consequences from the same volume extracted in water-abundant areas
Treating the 500 ml figure with care
The "500 ml per 30-turn conversation" figure (from Li et al., 2023 / Shaolei Ren) became widely cited in media coverage, often without key caveats: it is an estimate based on assumed data centre locations (US-average), a specific model generation (GPT-3 era), and indirect water attribution methods that are contested. Modern data centres vary widely in water efficiency; some use closed-loop systems that recirculate water rather than evaporating it. Treat this as an order-of-magnitude estimate. The original paper acknowledges significant uncertainty.
Putting it at scale
Individual query costs only matter if we multiply them by usage. Let's consider what the aggregate picture looks like.
AI usage at global scale (2025)
| Metric | Figure | Source / note |
|---|---|---|
| ChatGPT queries per day | ~2.5 billion | OpenAI (reported to Axios, 2025) |
| Organisations using AI | 78% of surveyed organisations | Stanford AI Index, 2025 |
| US data centre electricity (2023) | 176 TWh/year (4.4% of US electricity) | Lawrence Berkeley National Laboratory, 2024 (roughly tripled over the past decade) |
| Projected US data-centre electricity (2028) | 325–580 TWh/year | LBNL 2024; ≈6.7–12% of US electricity |
| US household electricity reference | ~1,200 TWh/year total | US EIA; for comparison purposes |
At the upper end of the LBNL 2024 projection (~580 TWh by 2028), US data centres would use close to half of what US households consume. These projections carry high uncertainty: they depend on assumptions about AI adoption rates, hardware efficiency improvements, and grid composition.
Training vs. inference: where the energy goes
Much early coverage of AI's environmental cost focused on the energy required to train a model: the one-time compute cost of creating GPT-4 or Claude. But for widely-deployed models, inference (running the model to answer queries) can easily exceed training energy over the model's lifetime.
With 2.5 billion queries per day, the cumulative inference cost of ChatGPT dwarfs the one-time training cost within months of deployment. This is why statements like "training GPT-3 emitted X tonnes of CO₂" need to be placed in the context of ongoing inference costs.
Summary and key takeaways
Before we can have a productive conversation about AI's environmental impact, we need to understand the numbers and their limits:
- Corporate opacity is the fundamental problem: AI companies don't disclose the data needed to calculate their environmental footprint, so all estimates involve assumptions
- Text vs. video is not comparable: Video generation uses roughly 1,000× more energy than text generation; these are different categories of use
- The flight comparison spans orders of magnitude: 300,000 to 7.6 million queries per flight, depending on model size and whose figures you trust
- Water is underreported: Both direct cooling and indirect electricity generation consume significant water, with geographic implications
- Scale is what matters: Individual query costs are small; billions of queries per day is not
- Inference, not just training: The ongoing cost of running models at scale quickly exceeds one-time training costs
- Agentic tasks can involve many calls, long contexts and substantial generated output. Their energy use must be estimated for a defined workload; the exercise above illustrates the calculation without assigning a typical daily footprint.
Next (4.2): We zoom out from individual queries to the infrastructure level: where does the electricity come from, how does manufacturing hardware fit in, and why do efficiency gains so often fail to reduce total energy use?