How We Estimate Environmental Impact (And Why We Show It)

privacyai-assistant
Keith

Keith

For every AI response, Moondoggle can provide an estimate of how much water and energy were used. If you've used any AI chat tool, you're probably familiar with them showing you how many tokens were used or how long it took to generate a response.

But at Moondoggle, I also want authors to be aware of the environmental impact of AI so they can make informed choices (and cut through some misinformation).

Aerial view of a hydroelectric dam with a reservoir reflecting clouds
Water and energy, the two resources AI inference draws on.

Photo by Casey Horner

Why show this at all?

Moondoggle is built for authors who think carefully about their tools. I believe you deserve to know what your AI assistant costs not just in dollars, but in energy and water.

The goal isn't to discourage using AI. Instead, it is to help you understand the impact rather than (a) ignore it, which most other AI tools do, or (b) blow the impact out of proportion, which a lot of AI critics do.

I can't say these numbers are 100% precise, but I've tried to make them transparent and well-sourced. And it's certainly better than pretending that AI doesn't use important resources.

What you see in the app

You can turn on Environmental Estimates in Moondoggle's settings panel, which will show two small figures beneath each chat response:

  • Electricity (Wh) — estimated energy consumed by the data center processing your query (measured in watt-hours)
  • Water (mL) — estimated water consumed by data center cooling systems (measured in milliliters)
A Moondoggle chat response in Deep mode with the token count, cost, energy, and water estimates shown beneath it
Every response reports its token count, cost, and estimated energy and water use. This Deep-mode response used about 23 Wh and 47 mL.

These measure only the inference step, which is the moment the AI reads your question and writes a response. They don't include the resources it took to manufacture the hardware, the electricity running your own computer, or anything used to power the network in between.

How we calculate

Moondoggle multiplies your query's total token count (input + output, as reported by the AI provider) by a per-mode constant. The constant is derived from published research, not from provider-specific disclosures.

We use mode-based tiers because larger models run on more powerful hardware and consume proportionally more energy per token:

ModeEnergy per 1,000 tokensWater per 1,000 tokens
Efficient~0.3 Wh~0.6 mL
Balanced~0.5 Wh~1.0 mL
Deep~1.0 Wh~2.0 mL

What does that look like in practice?

  • A typical Efficient query (~13,500 tokens): ~4 Wh of energy, ~8 mL of water
  • A typical Deep query (~39,000 tokens): ~39 Wh of energy, ~78 mL of water
  • A full writing session (20 Efficient queries): ~80 Wh, ~160 mL

Those numbers probably don't mean much on their own, so here's how they compare to things you already do:

Your usageEnergy equivalentWater equivalent
One writing session (20 Efficient queries)Charging your phone once (~80 Wh)Three tablespoons of water (~160 mL)
A heavy week (5 active days, mixed modes)Running a laptop for half a day (~500 Wh)One glass of water (~500 mL)
A full month (20 sessions, regular Deep queries)Running an LED lightbulb for two weeks (~2 kWh)Flushing a toilet once (~2 L)
A full year of daily useRunning your microwave for 15 hours total (~24 kWh)One two-minute shower (~24 L)

AI energy and water usage is real and worth being aware of. But for the individual author it's measured in drinking glasses and lightbulbs, not swimming pools and heavy machinery.

A smartphone charging on a wooden wireless charging pad, showing 81 percent charged
A full writing session costs about one phone charge.

Photo by Daniel Korpai

Where the numbers come from

Moondoggle's estimates are grounded in five published sources:

1. Google's 2025 infrastructure disclosure

Google was the first major provider to publish per-prompt figures. Their methodology estimates the median Gemini text prompt uses 0.24 Wh of energy and 0.26 mL of water. This measures on-site data center consumption only.

2. Microsoft Research (2026): "Energy Use of AI Inference"

Published in Nature Energy and detailed on Microsoft's research site, this study modelled three frontier-scale open-source LLMs under production conditions. Key findings: median inference energy of 0.31 Wh per query (interquartile range 0.16–0.60 Wh), rising to 3.91 Wh for long reasoning queries that use test-time scaling.

3. Shaolei Ren, UC Riverside (2024–2026)

Professor Ren's research takes a broader approach to account for the water consumed not just by on-site cooling, but also by power plants generating the electricity. His estimate: ~15 mL total water footprint per GPT-4 prompt. That's roughly 60x Google's figure, but they're measuring different things. Google counts only what evaporates at the data center. Ren counts the full upstream chain.

4. "How Hungry is AI?" (2025)

This infrastructure-aware benchmarking paper tested 30 models across commercial data centers, providing the most comprehensive cross-model comparison of energy, water, and carbon footprints for LLM inference.

5. Industry water-use averages

Data center consulting firm Hyscaler reports an industry average of approximately 1.9 litres of water per kWh consumed across AI-heavy data centres — consistent with ranges reported by IEEE Spectrum and Lawrence Berkeley National Laboratory.

Why do published estimates vary so much?

You may have seen headlines claiming a single AI query uses "a bottle of water." Others say "five drops." Both cite real research, but the gap comes from what they're counting. If you're only counting evaporative cooling in a data center, you're number is going to come in much lower than if you're also counting the water consumed by power plants.

Neither is wrong, they're just operating from different assumptions. We chose the on-site boundary for our in-app display because it's the portion most directly attributable to your query and most consistently measurable across providers. But it's important to acknowledge that there are other ways of measuring that take in the whole complicated, messy picture.

What we don't know

Honest caveats:

  • Different hardware — Anthropic, Google, OpenAI, and DeepSeek all run on different GPU fleets, and there's no way of getting a standard number for energy usage across so many different kinds of chips.
  • Different cooling — A data center in Ireland uses almost no evaporative water, but one in Arizona uses a lot. We can't know which one processed your query.
  • Different grids — A query processed in Oregon might run on hydropower, but the same query in Virginia runs on coal. Providers don't disclose per-query routing, so we have to work with averages.
  • No per-model disclosures — Google's report is the closest thing to per-prompt data, but no other provider has published equivalent figures.

We chose conservative estimates that likely overstate rather than understate. If the real numbers are lower, that's good news.

Why don't we show carbon emissions?

Carbon requires knowing the grid carbon intensity of the specific data center that processed your query, but that intensity varies up to 10x between regions and isn't disclosed per-query by any provider.

Showing a carbon number without knowing the grid would be misleading, so we would rather show you the approximate inputs (energy and water) than a speculative number we can't accurately source.

How will this improve?

As providers publish better data (Google led the way in 2025, Microsoft followed in 2026), our estimates will get tighter. We'll update the constants and note the changes in our release notes.

If a provider begins disclosing per-query energy data through their API, we'll use the real number instead of our estimate.

Turn it on (or don't)

You'll find the toggle in Settings → AI Assistant → Chat Display. It's off by default since we didn't want to clutter your writing space, but you can turn it on if you're curious. Or don't. It's your tool!

*Storming the castle . . . *