Why we measure the footprint of your AI
A single AI response is small.
But across thousands of users, thousands of workdays, and millions of conversations a year, the numbers stop being small. People deserve to see those numbers instead of being asked to pretend the cost does not exist.
Most chat apps tell you nothing about the environmental footprint of the model that just answered you. We do.
Every message has a real footprint. It uses electricity. That electricity has a carbon cost, depending on the grid that powers the datacenter. The datacenter also uses water for cooling, and the electricity grid itself uses water upstream.
Our position is simple: if we cannot measure it, we cannot reduce it.
So aim2balance.ai measures it and shows it. Not as a guilt trip, and not as a perfect measurement down to the last decimal. It is a calibrated estimate, shown clearly.
What we measure — and why we picked the methodology we did
For every AI message, we estimate two things:
- Energy, shown in kWh or Wh
- Water, shown in mL
Those numbers are not guessed from a single global average. They come from four factors that matter in the real world.
First, the model. A small model answering a short question is not the same as a large reasoning model writing a long technical report. We account for how large the model is, whether it uses a mixture-of-experts design, what precision it runs at, and how fast it generates text.
Second, the datacenter. Some facilities are far more efficient than others. We look at how much extra energy a datacenter spends on cooling and overhead, usually expressed as PUE, and how much water it uses.
Third, the electricity grid. A datacenter on a clean local grid has a very different carbon footprint from the same hardware on a fossil-heavy grid. Same compute, different impact.
Fourth, the length of the response. A short answer costs less than a long one. For our calculation we deliberately count output tokens only — the text the model generates for you.
We did not invent the math. The methodology comes from EcoLogits, an open-source, peer-reviewed project published in the Journal of Open Source Software in 2025. We apply it faithfully and calibrate it to the specific datacenters our models actually run in.
That last part matters. Many calculators use broad averages because they do not know where the model ran. We do know, so we use that context.
Why we pulled the trigger on showing this
We could have shown nothing. Most chat apps don't, because the number is inconvenient and not required.
We chose to show it anyway, on every message, because a cost you cannot see is a cost you cannot manage.
Here is what a single message actually looks like.
A short reply from our default model — Gemma 4 31B, running in Sweden — costs roughly:
Energy 0.04 Wh
Water 0.05 mL
That is genuinely tiny. Less energy than a typical web search, a fraction of a thousandth of a gram of CO₂, and a drop of water.
But "small" is not "zero," and not every message is small.
Ask a large frontier model on a fossil-heavy grid for a long, detailed analysis — say 16,000 tokens — and the same kind of message can cost:
Energy ~36 Wh
Water ~240 mL
That is hundreds of times higher. Still small per message, but repeated across teams, workflows, and a full year of usage, it adds up.
This is why the dashboard shows running totals for energy, and water. You can see the cost of your usage over time instead of only seeing one message in isolation.
The point is not to make people feel bad for using AI. It is to make the cost visible enough that individuals and teams can make better choices — sometimes a smaller model, sometimes a shorter answer, sometimes infrastructure that does more with less.
Why WHERE the model runs matters as much as WHICH model you use
People usually focus on the model: small model, large model, reasoning model, coding model.
That matters. But where the model runs can matter just as much.
Take the electricity grid. One kWh of electricity in Sweden produces about 18 grams of CO₂. The same kWh in Germany produces about 360 grams. That is roughly a 20× difference for identical compute.
In plain English: the same AI response can have a very different environmental footprint depending on where the machine is plugged in.
Datacenter efficiency matters too. A clean, efficient datacenter like the Swedish facility where we run our default model has a PUE around 1.15 — it spends about 15% extra energy on cooling and overhead. A typical global datacenter with a PUE around 1.58 spends about 58%. That is a large reduction before we even talk about model choice.
This is why we host where we host. The aim2balance.ai application runs in the EU on Hetzner in Germany. For inference, we route to EU providers such as Berget (Sweden), Scaleway (France), and Tensorix (Ireland), because their grid and efficiency profiles give us a better starting point.
The lowest-footprint AI message is still the one you do not need to generate. But when you do need AI, the location and efficiency of the infrastructure are not side details. They are part of the footprint.
For the technically curious
The methodology source is EcoLogits — open-source and peer-reviewed through the Journal of Open Source Software (2025). We did not build our own model of GPU power draw; we apply theirs and feed it our specific model and datacenter pairings.
For each message, the calculation takes in:
- Model profile — total parameters, active parameters per token, quantization (precision), throughput, and architecture (dense vs mixture-of-experts).
- Datacenter profile — PUE and water-use efficiency.
- Grid zone — carbon intensity and water intensity for the country the datacenter runs in.
- Output tokens — how many tokens the model generated.
From those, it produces electricity in kWh, then converts that to CO₂ in grams using the grid's carbon intensity, and to water in mL using both the datacenter's cooling water and the upstream grid water — not just one of them.
Two deliberate choices keep the estimate honest:
- Output tokens only. We do not count prompt tokens, embeddings, search calls, or network transit. This makes the number conservative on purpose — we would rather under-report than overstate precision we do not have.
- We never lower a number to look better. Where a provider's real throughput would reduce the reported impact, we keep the conservative figure. For an environmental number, erring toward over-reporting is the honest direction.
The model-to-datacenter mappings are verified against provider model cards and our own routing logs, and re-checked whenever we rotate a model.