There is no fixed cost per call
Cloud APIs price by token, and it is tempting to price energy the same way. Real serving hardware does not behave that way. Every request pays a fixed cost before any token comes out: the model is loaded into accelerator memory, the request is scheduled, and the first token has to be generated before the rest of the answer can follow. What is billed as "1,000 tokens" is a slice of that process, not the whole of it.
This is why a per-token rate is only meaningful once you state the prompt shape it applies to. The same model, measured two different ways, gives two different answers per 1,000 tokens — and neither is wrong.
Three prompt shapes, measured
The open benchmark this site uses measured 28 models at three shapes: a short chat prompt of 100 input and 300 output tokens, a balanced prompt of 1,000 and 1,000, and a long-context prompt of 10,000 input tokens with 1,500 output tokens. Each measurement is the electricity drawn by the serving node, including cooling, for one request of that shape.
On GPT-4.1 those three measurements are 0.918 Wh, 2.513 Wh and 4.233 Wh. Normalised per 1,000 tokens they become 2.30 Wh, 1.26 Wh and 0.37 Wh — the same model, a 6.2× difference in apparent cost per token, purely because the fixed part of a request is spread over 400 tokens in one case and 11,500 in another.
Model choice matters more than size
For the balanced prompt, the measured range runs from 0.271 Wh (GPT-4.1 nano) to 21.414 Wh (o3). GPT-4o costs 1.214 Wh and the older GPT-4 Turbo costs 6.758 Wh, so a newer model can be several times cheaper per call than the one it replaced. Claude 3.7 Sonnet lands at 2.781 Wh, and DeepSeek-R1 at 29 Wh — the highest of any model measured.
Reasoning models are expensive for a structural reason: a long chain of internal "thinking" tokens is generated before the visible answer, and every one of those tokens costs the same as a visible one. Turning reasoning down, or routing easy requests to a smaller model, is usually a larger saving than any infrastructure change available to you.
The grid decides the emissions
Energy becomes carbon through one multiplication: kWh × kgCO₂e per kWh. National averages differ by more than an order of magnitude. France sits near 41 gCO₂e/kWh, Norway and Switzerland below 40, the United States near 384, and India above 670 — all from the same energy dataset. The identical call therefore emits roughly sixteen times less carbon in France than in India.
Providers do not publish this figure. The benchmark models each provider's own grid: 0.353 kgCO₂e/kWh for OpenAI on Azure, 0.385 for Anthropic and Meta on AWS, and 0.6 for DeepSeek. Use those as a starting point and override them with your own grid when you are modelling a self-hosted model.
Batching is the largest lever you do not control
Energy per prompt falls steeply as a server batches more requests together, because the fixed cost is shared. The benchmark assumes a batch size of 8 and its sensitivity analysis reports that moving from a batch of 4 to 8 cuts energy per prompt by about 45%, and from 8 to 16 by a further 43%. Providers therefore have far more influence on per-prompt energy than API users do — which is also why two providers serving the same model can quote very different footprints.
What these numbers cannot tell you
Several important effects sit outside any such estimate. Caching, quantization and speculative decoding all reduce real energy use and are invisible from the outside. Embodied carbon — the manufacturing of the accelerators — is excluded deliberately, because allocating a whole GPU's footprint to one prompt makes models incomparable. And a measurement taken with a batch of 8 understates the footprint of a latency-sensitive deployment running a batch of 2.
One vendor does measure its own stack. Google reports that a median Gemini Apps text prompt consumed 0.24 Wh and 0.03 gCO₂e under a comprehensive boundary covering accelerators, host memory, idle capacity and cooling, and that software and procurement work cut median energy 33× and carbon 44× within a year. That is the honest benchmark for the question "what does serving AI cost", and it is smaller than most published inference estimates because most of them omit the same overheads.
Using the numbers responsibly
Use these figures for the jobs they can do: comparing models, sizing a monthly bill's environmental cost, deciding whether a cache or a smaller model is worth adding, and sanity-checking a supplier's claim. Do not use them for a public disclosure or an audited report without replacing them with your provider's own measurement and stating the boundary you measured.
When you do publish a number, say four things: the boundary you measured, the grid intensity you used, the batch size assumption, and the date. All four change the answer, and all four are cheap to state.
Energy and CO₂e for your own traffic
Runs in your browserCommon questions
How do I calculate the carbon footprint of an LLM call?
Multiply the energy the call uses by the carbon intensity of the grid serving it. A prompt using 2.5 Wh on a 0.35 kgCO₂e/kWh grid emits about 0.88 gCO₂e: 0.0025 kWh × 0.35 kgCO₂e/kWh.
Which model uses the least energy per call?
GPT-4.1 nano, at 0.271 Wh for a balanced 1,000-in/1,000-out prompt. It is also the least capable model in the benchmark, so the useful question is usually which model is the smallest one that still passes your quality bar.
Does a bigger model always cost more energy?
No. Hardware, batching and serving software dominate the cost. GPT-4o uses less energy per prompt than the older GPT-4 Turbo, and Llama 3.3 70B costs less than Llama 3.1 70B.
Why do output tokens cost more than input tokens?
Output is generated one token at a time, so each token keeps the model resident and repeats the same memory traffic, while input tokens are processed in parallel batches. Trimming a long answer usually saves more than trimming the same number of context tokens.
Does this include the carbon from manufacturing the hardware?
No. These figures cover operational energy (scopes 1 and 2) for serving. Embodied emissions from building accelerators are excluded because they cannot be attributed to a single call in a way that still allows models to be compared.
How accurate is this compared to a real provider bill?
It is a modelled estimate from measured latency and throughput plus published hardware and data-centre data. Google's own production measurement of a median Gemini Apps text prompt is 0.24 Wh under a comprehensive boundary, so treat these as order-of-magnitude figures with a reliable ranking, not as invoices.
Sources and further reading
- Jegham et al.: How Hungry is AI? Benchmarking Energy, Water, and Carbon Footprint of LLM Inference (arXiv:2505.09598)
- Elsworth et al.: Measuring the environmental impact of delivering AI at Google Scale (arXiv:2508.15734)
- Our World in Data: energy dataset — national grid carbon intensities
- US EPA: Greenhouse Gas Equivalencies Calculator — calculations and references