Methodology: How We Estimate AI's Water, Energy, and Carbon

Every figure on this site is one multiplication, done three ways: the energy a prompt uses, times a water (or carbon) factor. The three ways (Low, Mid, High) are not optimism and pessimism. They are accounting boundaries: cooling water only, plus power-plant water, or the full lifecycle including training and chip manufacturing. Every coefficient below carries a source.

#How an estimate is built

When you ask the calculator about a prompt, five things happen, in order:

1. Your usage becomes tokens. A typical chat exchange (your prompt plus the model's reply) averages about 700 tokens (site assumption, consistent with the 400-token-response benchmarks in Jegham et al. 2025 plus a typical prompt).1,2 If you enter token counts directly, we use those.
2. Tokens become energy. Each model is assigned to a class (efficient, standard, frontier, or reasoning) with a benchmarked energy intensity in watt-hours per 1,000 tokens (Jegham et al. 2025; operator disclosures where they exist, like Google's 0.24 Wh per median Gemini prompt).2,3
3. Energy becomes water. We multiply by liters per kilowatt-hour. This is where the scenario toggle matters: the factor ranges from 0.3 L/kWh (Low) to 30 L/kWh (High),4,5,1 and the next section explains why.
4. Energy becomes carbon. Same multiplication, different factor: grams of CO₂e per kilowatt-hour, from clean-power operator (Low) to fossil-heavy grid (High), anchored to EPA eGRID.6
5. The result becomes something you can picture. Milliliters are abstract; bottles, showers, and cups of coffee are not. Every equivalent is sourced too.

#The three scenarios, honestly

Ask "how much water does a chatbot query use?" and you can get answers from a quarter of a milliliter to half a liter (a factor of a thousand or so), all from credible sources. The numbers disagree because the questions disagree: each study draws its boundary around a different amount of the system. Rather than crown one boundary correct, we compute all three and label them. Think of it like asking what a hamburger costs: the menu price, the price with tax and tip, or the price including the farm subsidies. Same hamburger, three defensible answers.

Low: cooling only

What it counts: the water evaporated by the data center's own cooling systems, per unit of computing. Nothing else.

This is the boundary operators use, because it is the part of the system they own and meter. Google's official figure (0.26 mL per median Gemini prompt) lives here, as does OpenAI's ~0.32 mL per ChatGPT query (Altman, June 2025).3,7 Efficient operators report on-site water use of about 0.3 liters per kilowatt-hour (Microsoft's fleet average is 0.30). Google's own per-prompt figure implies about 1.1 L/kWh and OpenAI's about 0.9, so our 0.3 L/kWh Low factor sits at the efficient end of the operator range, and the calculator's Low values for Gemini and ChatGPT come out below those companies' own figures.4,3,7

Low is a real number, honestly measured. It is also the answer to the narrowest possible question. If you've seen a headline that AI barely uses any water, it was built on this boundary.

Mid: + electricity

What it counts: cooling water, plus the water consumed generating the electricity the data center runs on.

Power plants are thirsty. Thermoelectric plants evaporate cooling water; hydroelectric reservoirs lose water to evaporation. On the average US grid, generating one kilowatt-hour consumes roughly 4.5 liters of water somewhere upstream (Siddik et al. 2021),8 several times what the data center itself evaporates. Add the on-site share and Mid works out to 5 L/kWh, or about 2.8 mL for a typical chat exchange on a standard-class model.1

We treat Mid as the most decision-useful boundary: it counts everything that happens because you ran the query, while you ran it, without reaching back into construction and manufacturing. It is the default view in the calculator.

High: full lifecycle

What it counts: everything in Mid, plus a per-query share of the water used to train the model and to manufacture the hardware it runs on.

Training a frontier model consumes water for months before the first user shows up, and fabricating chips is among the most water-intensive manufacturing on Earth. Lifecycle studies spread those upstream costs across the queries the model eventually serves. Mistral's lifecycle analysis, the first from a model developer and externally reviewed, found 45 mL of water and 1.14 gCO₂e per 400-token response on this boundary.5 Mistral published no energy figure; at this site's assumed ~1.5 Wh for such a response, that implies roughly 30 L/kWh.1 The widely quoted ~519 mL per 100-word email (Washington Post with UC Riverside, 2024) is often filed here, but it counts cooling plus electricity at a high 2024 GPT-4 energy estimate, not training or manufacturing.9

High is the boundary you want if your question is "what does AI as a system cost in water?" rather than "what does my query add at the margin?"

One subtlety: withdrawal versus consumption

Throughout this site, "water use" means consumption (water evaporated or otherwise made unavailable to its source watershed), not withdrawal, water borrowed and returned (as once-through cooling does). Studies and headlines mix these freely, which accounts for some of the wilder numbers in circulation. Where a source reports withdrawal, we say so.

#How the scenarios combine with energy

One detail for careful readers. Our energy benchmarks also come as a low/mid/high spread, but that spread means something different: it reflects variance across studies and models, not an accounting boundary. To avoid multiplying two kinds of uncertainty into one opaque number, displayed water and carbon figures are computed from the Mid energy intensity times the scenario's water or carbon factor. The scenario toggle changes what gets counted, not how pessimistic we feel about the energy literature.

#The coefficients

Every number rendered anywhere on this site traces to the table below, which is generated directly from the same file the calculator engine reads, so this page cannot drift from the estimates. Each row carries its source.

Coefficients version 1.3.1 · updated 2026-09

#What we don't count, and other honest limitations

• Your device and the network. The phone in your hand and the fiber between you and the data center use energy too. It's small per query and excluded from all three scenarios.
• Location. A liter evaporated in Phoenix is not a liter evaporated in Oslo. Our factors are US-grid averages; local reality varies by an order of magnitude in both directions.
• Recycled and non-potable water. Some operators cool with reclaimed wastewater or seawater. Our factors don't distinguish water quality, a genuine limitation of the available data.
• Staleness. Models, hardware, and grids all change faster than the literature. The coefficient file is versioned and dated, and we update it when better numbers are published, not when the discourse does.

#How to disagree with us

Productively, we hope. Every coefficient lives in a single versioned file with a source attached, rendered above without editorial smoothing. If you think a number is wrong, you can identify exactly which coefficient, see exactly which study it came from, and point us to a better one. That is the entire trick: we'd rather be corrected than persuasive.