How much energy does AI use? Per query, per year, per token

The question has two honest answers and they point in opposite directions. Per query, AI uses less energy than the older estimates said, and the figure keeps falling. In total, AI is one of the fastest growing loads on the grid, and the figure keeps rising. Both are true because the number of queries is growing faster than the energy per query is falling.

Per query: three measurements that agree

Until 2025 the most quoted figure was about 3 watt-hours per ChatGPT query, roughly ten times a web search. It came from early hardware, early models and generous assumptions about prompt length. Three sources have since put real numbers on it.

OpenAI’s figure is 0.34 watt-hours. In June 2025 Sam Altman wrote that the average query uses about 0.34 watt-hours, about what an oven draws in a little over a second. No method was published with the figure.

Google’s figure is 0.24 watt-hours. In August 2025 it published a methodology paper for its own fleet. A median Gemini Apps text prompt uses 0.24 watt-hours and emits 0.03 grams of CO₂e, counting the accelerator, the host machine, idle capacity and the data centre overhead. The same paper reports that energy per prompt fell 33 times in twelve months.

Epoch AI’s estimate is 0.3 watt-hours. In February 2025 the research group worked through GPT-4o’s likely serving cost from the outside and landed on about 0.3 watt-hours for a typical text question, with the caveat that queries with very long inputs run to 2.5 to 40 watt-hours.

Earlier academic measurements sit lower still. Luccioni, Jernite and Strubell measured 88 open models on their own hardware in 2023 and found text generation at about 0.047 kilowatt-hours per 1,000 queries, which is 0.047 watt-hours each, while image generation cost orders of magnitude more. So the per-query range for text is a few tenths of a watt-hour, and the shape of the request matters more than the brand of the model.

Per token, and why "per query" hides the answer

A query is not a unit. It can be ten tokens or ten thousand, and the answer can be a sentence or a report. CrbonFree meters tokens instead, and its methodology charges each one a published number of joules by model tier: prefill for input, decode for output, a much smaller figure for a cached read. Scaled up by host power, cluster utilisation and the facility’s power usage effectiveness, that gives site energy for any exchange. Here is a task of 1,000 input tokens and 300 output tokens across the tiers:

The table shows three things. Output tokens cost two to four times what input tokens cost, because generating a token means a full pass through the model while reading one does not. Reasoning models cost the most per token and produce the most tokens, since their thinking is output. And a cached input token costs a tenth of an uncached one, 0.03 joules against 0.3 on the medium tier, which is why prompt caching is the cheapest efficiency a team can switch on.

Run it for your own usage. Pick an exchange size, a tier and how many queries a day, and the calculator gives the energy and the CO₂e per query, per day and per year from the same factors.

Per year: the totals

The per-query figures are small. The totals are not, because the queries are many and growing.

These totals cover everything data centres do. AI is what is driving the growth: Berkeley Lab attributes the doubling of data centre power demand between 2017 and 2023 largely to AI servers. Our own case study shows the demand side of the same curve. Token traffic through the OpenRouter gateway grew many times over in a single year, and every one of those tokens is a fraction of a watt-hour that nobody was metering.

Training versus inference

The per-query figures above are inference: the cost of answering. Training a model is a separate, one-off cost, spread across every answer the model gives afterwards. Because a widely used model answers billions of queries, the training share per query is small, but it is not zero, and it is easy to leave out. CrbonFree’s methodology carries training as its own line, 0.008 kilograms of CO₂e per million tokens, alongside the embodied carbon of the hardware at 0.020, so neither is blended into the energy figure silently.

How to measure your own

1. Count tokens per model from the provider’s usage data, not from spend. A dollar buys very different numbers of tokens on different models, so spend cannot tell an efficient model from a wasteful one.
2. Convert tokens to joules with per-tier factors, then to site energy with the host, utilisation and power usage effectiveness factors. CrbonFree does this under methodology v1.2 and publishes every factor with a version number.
3. Keep the layers separate: active energy, facility energy, and the lifecycle carbon on top. An auditor will ask which one you reported.
4. Report the uncertainty. Every CrbonFree figure carries a plus or minus 28.3% band, from a 20% activity uncertainty and a 20% factor uncertainty combined the IPCC Tier 1 way.

What cuts it

Energy per answer falls with fewer tokens, cheaper tokens and smaller models. Caching the fixed part of a prompt cuts its input cost by ten times. Routing routine tasks to a small tier cuts the site energy of a typical task from 0.59 to 0.21 watt-hours. Asking for a short answer costs less than asking for a long one, and using a reasoning model only when the task needs reasoning avoids the most expensive tokens there are. None of this needs new hardware; it needs the numbers per model, which is what metering provides.