What one AI question actually uses

The claim has been circulating for years, and you remember it after one reading:

"Every question you ask an AI consumes a bottle of water."

It is memorable, alarming and wrong. Not because AI is free of environmental cost, but because the original research said something else.

The claim traces back to a 2023 study called Making AI Less "Thirsty". Its first version states, word for word, that ChatGPT needs to drink a 500 ml bottle of water for "a simple conversation of roughly 20-50 questions and answers", depending on when and where it is deployed.

A bottle per conversation, not a bottle per question.

The paper's current version is more careful still. It no longer refers to ChatGPT but to the GPT-3 model, and the figure is 500 ml for "roughly 10-50 medium-length responses". Either way, turning that into "one question, one bottle" inflates the study's own estimate by at least an order of magnitude.

But the more important point is a different one: this was never a meter reading.

It was a model-based estimate of GPT-3. The researchers had to assume the model's electricity consumption, because nobody had published it. Their footnote is honest and worth reading: one inference is assumed to consume 0.00396 kilowatt-hours, or about 3.96 watt-hours, with a data centre PUE of 1.2, an electricity water intensity factor of 1.8 litres per kilowatt-hour for off-site generation, and on-site cooling water of 0.5 to 5 litres per kilowatt-hour depending on the weather.

The estimate was valuable because it surfaced something nobody had counted. It was never meant to be a universal conversion formula for every AI service.

What a measured number looks like

The first measurement covering the full serving stack in a real production environment was published in 2025. It is Google's own, which is worth keeping in mind while reading it.

For the median Gemini Apps text prompt in May 2025, Google reported:

• 0.24 watt-hours of electricity
• 0.26 millilitres of water
• 0.03 grams of CO₂ equivalent

Google's own comparisons are good ones: less energy than watching nine seconds of television, and the equivalent of five drops of water.

The energy figure covers the AI accelerators, the host machine's CPU and memory, idle capacity held in reserve, and data-centre overhead. Excluded are external networking, the user's own device and training the model. The water figure is water evaporated in data-centre cooling, not water consumed generating the electricity.

At this point the reader does a division in their head, so it is worth doing it out loud.

A gap of orders of magnitude that is nobody's mistake

The old estimate of 500 ml per 20 to 50 exchanges works out at roughly 10 to 25 millilitres per exchange. The current version's 500 ml per 10 to 50 responses works out at 10 to 50 millilitres per response. Google's measured figure is 0.26 millilitres.

So the gap runs from about forty-fold at its narrowest to nearly two hundred-fold at its widest, depending on which version you take. Google itself describes the difference from earlier estimates as one or two orders of magnitude.

Neither number is wrong. They describe different things, and the gap has three parts.

Model and year. The old estimate assumes 3.96 watt-hours per query. Google's measured median is 0.24. That assumption alone accounts for a factor of about sixteen, and it is entirely plausible: in between sit GPT-3, three years of hardware progress and production-scale utilisation.

The water boundary. The old estimate counts both data-centre cooling water and the water consumed generating the electricity. Google's figure counts only the first. The paper's own framework is useful here: scope 1 is on-site cooling, scope 2 is electricity generation, scope 3 is manufacturing the hardware.

Place. The same study reports that data centres evaporate on average 1 to 9 litres of water per kilowatt-hour of server energy: about one litre at Google's annualised global efficiency, and nine litres at a large commercial data centre in Arizona in summer.

A litre in Arizona and a litre in Finland are not the same litre. For water, a global average is a fundamentally worse measure than it is for electricity, because scarcity is a local property.

The boundary is not a detail, it is the number

Google's paper demonstrates this itself, and this is the most important part of the story.

For the same prompt, in the same month, measured by the same company, it reports two figures. Under a narrow boundary counting only the AI accelerators in the most efficient data centres, the figure is 0.10 watt-hours. Under the comprehensive boundary covering the full serving stack across the whole fleet, it is 0.24 watt-hours.

The same applies to water: 0.12 millilitres under the narrow boundary, 0.26 under the wide one.

Nothing is being hidden. Both numbers are correct. The choice of boundary alone changes the result by a factor of 2.4.

Compare two different providers and the gap grows far wider. In July 2025 Mistral AI published a life cycle assessment of its Mistral Large 2 model, carried out with the French environmental agency ADEME and the consultancy Carbone 4, and peer reviewed. Its result for a typical response of about 400 tokens is 1.14 grams of CO₂e and 45 millilitres of water.

Forty-five millilitres against Google's 0.26. A factor of about 170.

Both are first-party numbers. Both were published in the same year. Neither is marketing: Mistral's was peer reviewed and produced with a national environmental agency. They differ because the response is a different length, because a life cycle assessment counts things a production measurement does not, and because water and electricity are counted at different boundaries on a different grid.

Which brings us to the thing worth knowing about this subject: "one prompt" is not a unit of measurement unless the model, the task, the location and the accounting boundary are stated alongside it.

Four numbers that keep getting mixed up

Training and use are different activities

Training creates the model. Inference is what happens when a finished model answers a user.

The same water study estimated that training GPT-3 could consume millions of litres once both cooling and electricity generation are counted. That is a large, occasional computing project.

One user question is a small, endlessly repeated event. Allocating training to a single prompt would require knowing how many times the model will be used, how often it is retrained and which later models reuse the work. Providers do not disclose enough for that calculation to be made reliably.

PUE measures what is spent around the computers

PUE, or Power Usage Effectiveness, compares a facility's total electricity with the electricity delivered to the equipment itself.

A PUE of 1.20 means every unit going into computation requires another 0.20 for cooling, power conversion and other infrastructure. Google reports a fleet-wide PUE of 1.09. According to the IEA, cooling and environmental control range from about seven per cent of demand in an efficient hyperscale facility to over thirty per cent in a less efficient enterprise data centre.

WUE measures water, but not always inside the same boundary

WUE, or Water Usage Effectiveness, is usually given as litres per kilowatt-hour of computing.

Some figures include only the water evaporated in data-centre cooling. Others add the water consumed generating the electricity. Manufacturing chips and servers is typically left out altogether.

This is why two apparently precise water figures can differ a hundredfold without either calculation containing an error. They are measuring different systems.

"One question" is not one workload

A short text answer from a small model does not compare with a long reasoning task, an image or a video.

Under experimental conditions the IEA measured text generation at about 0.3 watt-hours on a small language model and around 5 watt-hours on a medium-sized one. A large reasoning model was estimated at around 9 watt-hours for the same text task. Generating an image took about 1.7 watt-hours.

Then there is video. Producing a six-second, deliberately low-quality video took about 115 watt-hours, roughly the same as charging a laptop twice over.

These figures cover only GPU electricity under controlled conditions rather than a complete production service, and the reasoning model figure is an estimate rather than a measurement. So there is no contradiction between a 0.24 watt-hour production prompt and a multi-watt laboratory result. Model size, response length, hardware utilisation, batching and the measurement boundary all change the answer.

Scale without the guilt trip

Take Google's 0.24 watt-hours as an illustrative reference point.

• Charging a phone takes about 15 watt-hours in the IEA's figures, roughly 60 such prompts. Charging a laptop takes about 60 watt-hours, roughly 250 prompts.
• An hour of streaming video came to about 77 watt-hours in the IEA's 2019 estimate, roughly 320 prompts. That figure includes the viewing device, which Google's prompt figure does not, and it is now seven years old.
• A 6-kilowatt sauna heater at full power for an hour is 6,000 watt-hours. That is the same arithmetic as 25,000 prompts.
• And AI itself: one six-second AI video is, in the IEA's experimental conditions, worth about 480 such text prompts.

Now for the thing that has to be said out loud, because it is the risk this article creates. Those conversion factors belong to one measured prompt, at one service, in one month. If you see any of them quoted somewhere without that sentence attached, it is precisely the mistake this article is about. The more honest form is a range: the same sauna hour is about 700 prompts on a large reasoning model and 25,000 on a small text prompt. Even that range splices together two figures measured at different boundaries, because the reasoning model figure is GPU-only under laboratory conditions. Better data has not been published.

The comparisons are not an argument for unlimited computing. They restore scale. The concern is not one person typing one useful question, but billions of requests, increasingly demanding workloads and the infrastructure built to serve them.

The IEA estimates data centres consumed around 415 terawatt-hours in 2024, about 1.5 per cent of the world's electricity, and projects that roughly doubling to around 945 terawatt-hours by 2030. A small per-use number and a large total can both be true at once.

The Finnish factor: when a data centre becomes a heat plant

Almost all the electricity a server uses eventually becomes heat.

In most places that heat is moved out of the building and released into the air or into water. From the energy system's point of view, it is waste.

Finland has another option: district heating.

A data centre built near a district heating network can hand its low-temperature excess heat to heat pumps. The temperature is raised to a usable level and the energy is distributed through existing pipes to homes, offices and public buildings.

Fortum and Microsoft are building this at Kolabacken in Kirkkonummi and Hepokorpi in Espoo. The stage matters and should be stated precisely, because two different versions of it are in circulation: the heat pump plants started up in May 2026, but for now they produce district heat from ambient air and electric boilers. Recovery of waste heat from the data centres begins step by step only next year, following Microsoft's own construction and commissioning schedule.

Once fully implemented, Fortum expects data centre waste heat to cover about 40 per cent of the area's annual district heating demand of 2 terawatt-hours, serving a network of around 250,000 heat users.

None of this makes the electricity consumption disappear. The data centre still uses the same watt-hours, and the heat pumps need more electricity on top. The correct system-level accounting is this:

Electricity into the data centre remains an input. Recovered heat is counted separately as a useful output that may displace another source of heat.

The real benefit depends on how much heat can be recovered, how efficiently the heat pumps run, how heating demand varies by season, and what form of heat is displaced. A gas boiler, a biomass plant and already clean electric heating produce very different avoided impacts.

The advantage is real all the same. The same computing work produces a different system-level result when its location offers clean electricity, a cool climate and a paying customer for the heat.

Fingrid reports that electricity consumed in Finland had an emissions factor of 26 grams of CO₂ per kilowatt-hour in 2025. If Google's 0.24 watt-hour prompt were hypothetically served on that annual average, its location-based emissions would be about 0.006 grams. That is an illustration, not a claim about where Gemini prompts are processed.

One qualification is compulsory here. Google's reported 0.03 grams is a market-based figure, meaning it credits the clean electricity the company buys. The location-based figure would be higher. The two cannot be compared directly, which is the same story again: the boundary decides.

What actually determines the footprint

For an ordinary user, the decisive variables are not how politely the question is phrased or whether it could have gone unasked. They are mostly infrastructure choices beyond their reach:

• Which model performs the task?
• How long and computationally demanding is the answer?
• How efficiently is the hardware being used?
• What electricity runs the data centre?
• Is cooling water scarce in that particular place?
• Is the resulting heat thrown away or recovered?

A user can avoid repeatedly generating long outputs they do not need, particularly video and heavy agentic tasks. An organisation buying AI services can do considerably more. It can require the provider to state energy per task, the measurement boundary, the location-based emissions factor for the electricity, water use by watershed, and what happens to the excess heat.

These are ordinary procurement questions. They are just rarely asked.

The number worth retiring

"One AI question consumes a bottle of water" is not a rough approximation. It is a real study converted into the wrong unit and detached from its own assumptions.

An ordinary text prompt at an efficient modern service can use a fraction of a watt-hour and less than a millilitre of direct cooling water. A long reasoning task uses many times more. A video uses a hundred times more. Water used in electricity generation is still poorly disclosed, and the total impact of rapidly expanding data-centre infrastructure is significant, particularly at the local level.

The individual prompt is probably smaller than it feels.

Where the millions of prompts are run is where the environmental decision is actually made.