Estimating ChatGPT’s Daily Water Footprint

There is no single measured answer. Depending on the assumptions, ChatGPT’s global service may use roughly 2 million to 160 million litres of water per day. One commonly cited middle estimate is about 17 million litres per day at approximately 2.5 billion prompts per day.

I would treat those figures as scenario estimates, not telemetry. The result changes sharply with the model’s energy cost, data-center cooling design, electricity mix, and what counts as a prompt.

Water Has Two Accounting Layers

The software does not consume water directly. The physical infrastructure behind it does.

On-site water

Data centers may consume water for:

• Evaporative cooling towers
• Water chillers
• Humidification
• Other cooling and environmental-control systems

The usual metric is Water Usage Effectiveness (WUE):

WUE = litres of site water consumed / kWh of IT energy

Electricity-related water

The electricity supplying a data center also has a water footprint. Thermoelectric power plants use cooling water, while fuel extraction and processing consume additional water. IEEE Spectrum and other analyses quantify these effects for different electricity sources.

A fuller estimate is therefore:

Total water intensity =
    on-site WUE
    + water intensity of electricity generation

The scenarios below use the WUE term directly. They do not add a separate grid-water factor, so they should be read as transparent cooling-water estimates rather than a complete lifecycle inventory.

The Conversion

Three inputs are needed:

1. Energy per query in Wh/query
2. WUE in L/kWh
3. Queries per day

The calculation is:

Water per query (L) = (Wh/query / 1,000) × WUE
Water per day (L) = water per query × queries per day

The traffic estimate I use is 2.5 billion queries per day, based on OpenAI and industry reporting. Actual volume varies by month, time zone, and how a provider defines a prompt.

The energy number is much less certain. OpenAI CEO Sam Altman stated that an average ChatGPT query uses about 0.34 Wh and compared its water use with a fraction of a teaspoon. Independent academic and press estimates for heavier AI workloads range from below 1 Wh to several or even double-digit watt-hours per request. Model version, prompt length, output length, routing, storage, and other overhead all matter.

WUE is similarly variable. Published values range from approximately 0.2 L/kWh for highly efficient, closed-loop or non-evaporative facilities to more than 10 L/kWh for water-intensive installations.

Reproducible Scenarios

For the calculations below, I use:

• Queries: 2.5 billion/day
• Low WUE: 0.206 L/kWh
• Average WUE: 1.8 L/kWh
• High WUE: 12 L/kWh
• Low energy: 0.34 Wh/query
• High energy: 18 Wh/query

The gallon conversion is 1 litre = 0.264172 US gallons.

This small script reproduces the cases:

queries_per_day = 2_500_000_000
liters_to_gallons = 0.264172

scenarios = [
    ("low WUE + low energy", 0.206, 0.34),
    ("average WUE + low energy", 1.8, 0.34),
    ("average WUE + 1 Wh", 1.8, 1),
    ("average WUE + 2 Wh", 1.8, 2),
    ("average WUE + 10 Wh", 1.8, 10),
    ("high WUE + high energy", 12, 18),
]

for name, wue, energy_wh in scenarios:
    liters_per_query = energy_wh / 1_000 * wue
    liters_per_day = liters_per_query * queries_per_day
    gallons_per_day = liters_per_day * liters_to_gallons

    print(
        f"{name}: "
        f"{liters_per_query:.6f} L/query, "
        f"{liters_per_day:,.0f} L/day, "
        f"{gallons_per_day:,.0f} gal/day"
    )

The selected outputs are:

Optimistic case

With 0.206 L/kWh and 0.34 Wh/query:

• Water per query: approximately 0.000070 L, or 0.07 mL
• Daily water: approximately 175,000 L
• Daily water: approximately 46,300 US gallons

Altman’s energy estimate with average WUE

With 1.8 L/kWh and 0.34 Wh/query:

• Water per query: approximately 0.000612 L, or 0.61 mL
• Daily water: approximately 1,530,000 L
• Daily water: approximately 404,000 US gallons

This is a defensible midpoint only if both inputs are accepted, and it still excludes separately calculated grid-water consumption.

Moderate energy assumptions

At average WUE:

• 1 Wh/query: 4,500,000 L/day, or approximately 1,188,774 gallons/day
• 2 Wh/query: 9,000,000 L/day, or approximately 2,377,548 gallons/day

High-energy case

At 10 Wh/query and 1.8 L/kWh:

• 45,000,000 L/day
• Approximately 11,887,740 gallons/day

Pessimistic combination

With 12 L/kWh and 18 Wh/query:

• Water per query: 0.216 L
• Daily water: 540,000,000 L
• Approximately 143 million gallons/day

The broad 2 million to 160 million litres/day framing and the roughly 17 million litre/day middle estimate sit among many possible assumptions. The explicit endpoints above are wider because they combine extreme energy and WUE values. That spread is not a rounding error; it comes from multiplying uncertain inputs.

Why Estimates Disagree

Energy per prompt

A short request handled by a small model is not equivalent to a long multimodal request handled by a large model. Independent estimates commonly place plausible usage around 1 Wh to 10 Wh per prompt, while heavier model instances can reach several or double-digit watt-hours.

The distinction between a prompt and a conversation also matters. A long session can trigger repeated inference, context processing, storage, routing, and auxiliary services.

Cooling design

Hyperscale operators use different combinations of air economizers, closed-loop liquid cooling, evaporative systems, and other designs. Some Microsoft-class facilities report very low WUE, with experiments moving toward zero-water cooling. Older or location-constrained facilities can be substantially more water-intensive.

Liquid-to-chip cooling and chip-level immersion can reduce evaporative demand for GPU clusters compared with large evaporative cooling towers.

Electricity mix

A facility powered primarily by solar and wind has a different indirect water footprint from one supplied by thermoelectric plants that depend heavily on cooling water. A complete estimate therefore needs both data-center WUE and regional electricity-water intensity.

Because energy use and water intensity are multiplied, uncertainty in both terms compounds. That is why plausible scenarios span two orders of magnitude.

What Actually Reduces the Footprint?

The largest levers are infrastructure and software efficiency:

• Place workloads in regions and facilities with low WUE, closed-loop or liquid-to-chip cooling, and low-water electricity sources.
• Improve inference batching, quantization, distillation, and model routing to reduce energy per response.
• Report standardized, independently audited PUE, WUE, and per-model inference metrics.
• Require clearer reporting around water permits and local impacts as data-center capacity expands.

For users, the practical steps are smaller but still measurable at aggregate scale:

• Combine related requests into focused prompts.
• Request shorter outputs when a long response is unnecessary.
• Use local models or cached results for repetitive work where privacy and performance allow.

When comparing models experimentally, a unified multi-model API such as CometAPI can keep request formats consistent, but it does not remove the need for providers to disclose the infrastructure metrics that determine water use.

Bottom Line

Using 2.5 billion prompts/day, 0.34 Wh/query, and 1.8 L/kWh produces approximately 1.53 million litres/day, or 404,000 US gallons/day.

That is a useful reference point, not a universal answer. With best-in-class cooling and low per-query energy, the estimate can fall to around 175,000 L/day. With heavier model instances and water-intensive facilities, it can reach hundreds of millions of litres per day.

The most valuable missing data is standardized reporting of energy per inference, WUE, electricity-water intensity, and traffic by model and workload.

---

Originally published at cometapi.com