Environmental methodology

These are transparent estimates, not certified measurements. The labs don't publish per-token energy, water or carbon, so every figure here is estimated from public research, every number is cited, and every figure comes with the range its sources span. If you have real numbers, tell us and we'll use them.

Centrail counts the exact tokens your AI agents use, then turns them into an environmental footprint. This page is the whole method, in the open — read it before you sign up, then sign in and run your own numbers →.

This is method v2.

The model

Energy is the primitive; water and CO₂ are derived from it — the same approach used by the UNU-INWEH environmental-cost report, which notes that inference energy scales with the tokens processed.

energy = Σ(tokens_in_class × class_rate) × model_factor
CO₂    = energy × grid_carbon_intensity
water  = energy × grid_water_intensity

Where the sources disagree, each coefficient has a low, a central and a high reading. The figure we show is the central one; the range under it is every low reading at once and every high reading at once.

Why the range is wide

The range is wide, and that is the honest size of what is known. No lab publishes energy per token, so every rate here is back-solved from public estimates: one analyst's estimate of one model (GPT-4o), scaled by context length, by list price and by a grid figure that changed between two versions of the same paper. On a typical coding-agent month on Claude Opus, the high end is about 3× the low for energy, 4× for carbon and 5× for water; for a model we can't place, it spans more than an order of magnitude. The equivalents (phone charges, bottles, seedlings) convert the central figure.

Energy per 1M tokens, by class

Output tokens cost far more than input, and cached reads cost far less — so we price each class separately. The rates come from Simon Couch, who back-solved them from Epoch AI's GPT-4o estimates (about 0.3 Wh for a typical query, 2.5 Wh with a 10k-token input, 40 Wh with 100k) and calls the result napkin math. His table has three context cases; we use two:

kWh per 1M tokens, for the anchor model (factor 1.0×, below).

The central figure is the ~100k case, the one Couch used for his own coding-agent figures. Coding agents run long contexts: every request starts with ~20k tokens of system prompt and tools, and Couch regularly ran up against the 200k window. A central figure the method itself expects to be low would understate the footprint, so we don't use one. The low end is the ~10k case, in case caching spares more of a long context than the 100k case assumes (Epoch calls processing a long input "an upfront cost"). The short-query case (0.11 / 0.54) is not used: one short question and answer does not describe a coding-agent session. The high end uses the same ~100k rates; what raises it is the model factor's high reading and the grid, below.

The cache-rate assumption. Cache reads and cache writes are not separate estimates: they are Anthropic's price ratio applied to the input rate (reads at 1/10 of input, writes at 1.25×), as Couch derived them. A price ratio is a business decision, not an energy measurement, and on a coding-agent mix cache reads carry about half the energy and cache writes about a third. The range above does not include this assumption: if a cached token costs more energy relative to input than its price suggests, every coding figure is higher.

For surfaces where we only have a token total (like the public estimator), we apply a blended rate for the selected usage style, clearly labelled illustrative: 0.28 kWh per 1M tokens (low 0.14) for a history-heavy chat mix (~70% cached context), or 0.073 kWh per 1M tokens (low 0.037) for a cache-dominated coding-agent mix (~94% cache reads, as observed in real Claude Code ledgers). The gap is real: cache reads cost ~50× less energy than generated output, so the same token total can legitimately differ ~4× by workload.

Model factor

The class rates describe one model: GPT-4o, in Epoch's estimate, which Couch takes as a ballpark for Claude Opus 4.5 (both list at $5 per million input tokens; GPT-4o launched at $15 output, Opus 4.5 at $25). That model is the anchor, 1.0×. Every other factor is an estimate, scaled by list output price (Anthropic pricing, OpenAI pricing), the same price-as-compute proxy Couch uses, down as well as up: a small model is not floored at the anchor. Central divides a Claude model's price by Opus 4.5's $25 (Couch's reading); high divides it by GPT-4o's $15, in case the rates describe a model priced like GPT-4o, which puts every Claude factor up to 1.67× higher. An OpenAI model divides by GPT-4o's own $15; a row covering several models spans their prices, central at the cheapest.

Every factor is an estimate. No lab publishes energy per token, so nothing here is a reading of a real data centre. Each estimate is a standing request: publish the real figure and we'll replace ours.

DeepSeek. arXiv 2505.09598v6 estimates energy per query, and a reasoning model's query includes the reasoning tokens it generated, which we already count as output tokens, so its per-query ratio against other models cannot be applied per token. What it does show per token is the same model, on the same queries, using 5.7× more energy on DeepSeek's own servers (24.596 Wh) than on Azure (4.331 Wh); logs can't tell which served you, so that is the high end.

Grid factors, by provider

The same kilowatt-hour carries different carbon and water depending on the cloud and grid that served it. Both come from Table 1 of Jegham et al., How Hungry is AI?, and the paper revised them between versions: v1 (May 2025) used US national averages, while v6 (Nov 2025) uses each cloud's regional mix of data centres. We take v6 as central, because it describes where the inference runs, and v1 as the other end of the range. Both links are pinned to their version: the paper's unversioned address always serves the newest one.

Water is the paper's formula: on-site water per kWh divided by PUE, plus off-site water per kWh (AWS: 0.18 / 1.14 + 5.11 in v6, 0.18 / 1.14 + 3.142 in v1; Azure: 0.30 / 1.12 + 4.35, and + 3.142). About 92–97% of that water is off-site: it is used by the power plants that generate the electricity, not by data-centre cooling. A provider we can't place uses the AWS figures, a placeholder rather than a reading.

Real-world equivalents

To make the numbers tangible, we convert the central estimate into everyday reference points — each one sourced:

One tree basis, the EPA's: its calculator converts CO₂ into "tree seedlings grown for 10 years" at 0.060 t each, and its references describe that figure as one urban tree's average yearly uptake over its first 10 years.

Why it's an estimate

Real energy, water, and carbon depend on the exact model, the hardware it ran on, the datacenter's efficiency, and the local grid — none of which a token count can see directly. We publish the full math, cite every coefficient, show the range the sources span, and update the method as better data is published.

Method versions

This is method v2. A shared pledge card records the method version its impact figures were estimated with, and its page names it; when this method changes, the version goes up and cards already issued keep theirs.

Method v1 (cards issued before v2) showed a single figure with no range. It used Couch's maximum-context rates as if they described Claude Sonnet (1.0×), and scaled Opus by a further 5.0×, so an Opus figure was scaled twice: once inside Couch's Opus-based rates and again by the factor. It read the grid factors from the paper's unversioned address (and its AWS water rate, 3.16 L/kWh, matched neither version's formula), put a 10.4× per-query ratio on DeepSeek per token, cited the Netflix figure to a page that does not contain it, and showed a mature tree at 22 kg CO₂ a year, an upper bound shown as typical, from a page since removed.

Cards issued under v1 keep their v1 figures, equivalents and mature tree, and show no range. Their labels follow today's card policy: a v1 card no longer says "Verified usage" but where its usage came from ("tracked from my agent logs", or "Estimated usage" for imports), its figures read approximate ("~360 kWh" where it said "358 kWh"), its footnote says the impact is estimated with method v1, and its image prints the card's own URL.

Ready to see yours? Sign in and run your numbers →

Chat app imports (estimated)

When you import a ChatGPT, Claude, or Gemini data export, we estimate tokens from message text — exports don't include token counts.

• Characters → tokens: tokens = ceil(characters / 4) — the standard rule-of-thumb for English text used across the industry (OpenAI's own guidance: ~4 characters per token).
• Context modeling: chat apps re-send your conversation history to the model on every turn. For each assistant reply we count the fresh user message as input, the reply as output, and all prior conversation text as re-sent context — priced like cache reads, the same semantics as the CLI's token counts. Without this, imports would undercount real usage several-fold.
• Model attribution: ChatGPT exports name the model per message; Claude exports don't, so we apply the model you select at import time; Gemini imports use a Gemini-class factor.
• Response text (Gemini): newer Google Takeout exports include Gemini's responses as HTML, which we strip to text and count exactly like other replies. Older exports record prompts only; for those we assume 250 output tokens per response — an average-length assumption, marked as such.
• Attached images: an image attached to a prompt is priced at a flat 258 tokens (the rate Gemini itself bills for a standard image). Generated videos have no token equivalent and aren't counted. Media files themselves are never read or uploaded — only the filenames in the activity records.

Imported figures are always labeled estimated, live in their own dashboard section, and never mix into the CLI's counts from your agent logs or into CLI pledge cards.