AI carbon footprint: what it is and how to measure it

Most articles about the carbon footprint of AI are about the industry: the data centres being built, the grid they will need, the gas plants being kept open to feed them. This one is about the footprint a company creates by using AI, because that is the number a sustainability officer, an auditor or a board will ask for, and it is the hardest one to find.

What counts

A company’s AI footprint is the greenhouse gas emitted to serve the calls it makes: chat prompts, API requests, coding agents, embeddings, everything that sends tokens to a model and gets tokens back. It has three parts. The electricity used by the accelerators that run the model. The electricity used by the rest of the facility around them, the host servers, the idle capacity and the cooling. And the carbon embodied in the hardware and spent training the model, spread over every token the model serves.

Training a model is the provider’s footprint; using it is yours, and it lands in your accounts as a purchased service. Under the GHG Protocol that makes AI usage a Scope 3 line item for almost every company, because the inference runs in someone else’s data centre. As disclosure rules tighten, that line is starting to get asked for, and a spend-based guess does not survive the question.

Per query

Per query the numbers are small, and so are the energy and water behind them. Google measures 0.03 grams of CO₂e for a median Gemini text prompt. Under CrbonFree’s methodology v1.2, a task of 1,000 input tokens and 300 output tokens on a medium tier model comes to about 0.28 grams once the facility, the hardware and the training are counted, and 0.12 grams on a small tier. A reasoning model doubles the medium figure because its thinking is output, and output tokens cost the most.

The reason two well-founded figures can differ by ten times is boundary. Google’s number is its own fleet, its own grid mix and its own power usage effectiveness, counted to the facility boundary. Ours applies published average factors and adds the lifecycle layer. Neither is wrong, since they answer different questions, and a defensible report says which question it is answering.

Per million tokens, by model tier

Tokens are the unit that scales. This is what a million of them emit under methodology v1.2, at the 75% input and 25% output split used for aggregate counts, with no caching:

The right-hand column is the figure the dashboard, the API and the receipts report. The other two are always available underneath it, because an auditor may want the operational boundary on its own.

The three layers

The columns above are the three layers of the methodology, and each contains the one before it.

Active energy

Each token is charged joules for the work it causes on the accelerator: 0.3 for an input token and 0.5 for an output token on the medium tier, a tenth of that for a cached read. Joules become kilowatt-hours, then CO₂e through the facility’s power usage effectiveness and the carbon intensity of its grid.

Facility operation

Accelerators do not run alone. Host servers add 18%, and clusters average about 30% utilisation, so the active figure is scaled up to what the data centre draws. This is the operational, Scope 2 boundary from the provider’s point of view.

Full lifecycle

Manufacturing the hardware adds 0.020 kilograms and training the model 0.008 kilograms per million tokens, amortised over the fleet’s serving life. Both are carried as their own line, never blended in silently.

This structure follows the open framework for corporate AI emissions published by Bistline and colleagues and written up by Watershed, adopted in methodology v1.2 around a token engine that had previously reported active energy only. The adoption is independent. Watershed’s own reference factors give a larger per-token figure, and the training factor above is a conservative default pending confirmation, so the lifecycle figures are a floor.

Why published figures disagree

The number moves with four inputs, and a figure that does not state them cannot be compared with anything. The first is the boundary, whether the figure stops at the accelerator, the facility or the full lifecycle. The second is power usage effectiveness, 1.09 for Google’s fleet against a 1.2 default. The third is the grid, 0.345 kilograms per kilowatt-hour for Google’s mix against 0.42 for the default. The fourth is the hardware generation: Google reports a 33 times drop in energy per prompt in one year, so a 2023 measurement and a 2025 measurement of the same task are different numbers. The methodology pins a factor version on every billing period and every receipt so that a report filed today does not move when the factors improve.

What a year at scale looks like

A billion medium-tier tokens come to about 221 kilograms of CO₂e, with bounds of 158 to 283 kilograms. A trillion tokens, a fraction of what a large gateway routes in a month, come to about 221 tonnes, the annual emissions of 48 passenger cars on the US EPA figure of 4.6 tonnes each. Our case study ran a year of public OpenRouter traffic through the same factors and found a footprint that appears in nobody’s Scope 3 disclosure.

How to measure it

1. Meter the tokens, per model and per provider, from the provider’s own usage data. Spend cannot tell an efficient model from a wasteful one.
2. Match each model to a tier and apply the published factors for input, output and cached tokens.
3. Convert energy to CO₂e with the facility’s power usage effectiveness and the grid’s intensity, then add the facility and lifecycle layers.
4. Attach the uncertainty band and the factor version to every figure, so the number can be reproduced later.

The methodology's own calculator runs the arithmetic for any volume of tokens, showing the three layers and the uncertainty band:

CrbonFree does all four from a read-only provider key, the CLI or the browser extension, and reads the results back through the dashboard, the SDKs, the MCP server and the API. The sample account shows a year of real traffic metered this way, with no login required.

How to report it

Report it as Scope 3, purchased services, with the boundary and the factor version stated. Keep the measured footprint and any climate action separate: if credits are retired against the number, the number is reported unchanged and the retirement is reported alongside it with its own signed receipt and serial numbers. State the uncertainty band. And keep the three layers available, because the first question from an auditor is usually which one the headline figure includes.