AI Environmental Impact Estimator

Estimate the carbon cost of your AI usage for sustainability reporting

Enter your AI usage pattern — provider, model tier, and approximate monthly query volume — and get an estimated energy use and carbon footprint for sustainability reporting, based on published per-query energy figures and grid carbon-intensity data. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

How accurate is this estimate?

It is an order-of-magnitude estimate, not a precise measurement. Per-query energy varies widely with prompt length, output length, model size, and data-center efficiency, and most providers do not publish exact figures. Use it for directional sustainability reporting, not as an audited number.

AI environmental impact estimator

Generative AI has a real energy cost, and sustainability teams increasingly need a number for it. This estimator turns your usage pattern — model tier and monthly query volume — into an estimated energy use and carbon footprint you can put in a report. It uses representative per-query energy figures from published research and provider disclosures, then converts energy to emissions using a grid carbon-intensity value you can tune to your region.

How it works

Inference energy scales roughly with model size and output length. The tool assigns a representative per-query energy figure to each model tier — small, mid, and large text models, plus image generation, which costs considerably more per output. It multiplies by your monthly volume to get kilowatt-hours, then multiplies kWh by your chosen grid carbon intensity (grams CO2 per kWh) to get CO2-equivalent emissions. Relatable comparisons (such as kilometres driven) make the number meaningful in a report. All calculation is local.

How model tier affects energy use

The energy cost of a generative AI query scales with the number of parameters in the model and the number of tokens generated. Published research and provider disclosures place the range for inference broadly as follows:

  • Small models (efficient consumer-tier models, quantized local models) — a fraction of a watt-hour per typical query
  • Mid-size models (mid-tier API models) — on the order of a fraction to a few tenths of a watt-hour per query
  • Large frontier models (flagship API models, very large context calls) — a few tenths to a few watt-hours per query
  • Image generation — typically higher per output than text, reflecting the heavier compute of diffusion steps

These ranges vary substantially with prompt and output length. A one-sentence query costs far less than a ten-thousand-word document analysis. The estimator uses representative midpoints; treating the results as order-of-magnitude is appropriate.

Why grid carbon intensity dominates the result

The conversion from kilowatt-hours to CO2-equivalent emissions depends on the carbon intensity of the electricity powering the data centre — grams of CO2 per kWh. This number varies enormously by region and provider:

  • A data centre powered primarily by hydro or nuclear electricity can have a grid intensity many times lower than one on a coal-heavy regional grid.
  • Major cloud providers publish sustainability reports that include average grid carbon intensity and percentage of renewable energy by region, and many have committed to running on matching renewable energy.
  • The practical effect is that the same number of AI queries produces substantially different CO2 footprints depending on which cloud region you use — this is a real lever for teams that have a choice of provider region.

The estimator’s grid intensity input lets you set your region’s value or the provider’s published figure.

Inference versus training emissions

This tool estimates inference emissions — the energy used to run your queries — which is the cost you incur as an API consumer. Training a large foundation model is a larger one-time energy event that is typically reported separately by the model provider. As an API customer you are not responsible for the training energy in the same way; it is amortised across all users of that model. The exception is if your organization fine-tunes your own model — in that case fine-tuning compute is part of your footprint.

Tips and notes

  • It is an estimate. Per-query energy varies with prompt and output length; treat the result as order-of-magnitude, not audited.
  • Set your real grid intensity. A low-carbon cloud region can be five to ten times cleaner than a coal-heavy grid — this dominates the result.
  • Inference only. Training is a separate, provider-side cost, not yours as an API consumer.
  • Document assumptions. For ESG/CSRD reporting, record your inputs and prefer provider-supplied figures where they exist.
  • Ask your provider for actual figures. Enterprise agreements with major cloud and AI providers sometimes include access to actual consumption data which is more accurate than any estimator.