Loading
Demo organization. Token totals are OpenRouter's public data, split 75/25 between input and output by assumption; costs, coding agent and extension usage are sample figures. OpenRouter is not a CrbonFree customer.
Our footprint reports the full lifecycle of your AI usage, converged with the Watershed corporate AI emissions framework. We keep our four-way token engine as the innermost layer, then widen the accounting boundary around it in two steps. This page documents the math, the sources, and the uncertainty behind every CO₂ number on your dashboard.
Earlier versions reported only active GPU silicon. Watershed's corporate methodology counts the whole facility and the hardware lifecycle, so their number is larger. Rather than replace our engine with a flat blended factor, v1.2 reports three distinct, inspectable layers — you can see exactly where each gram comes from, and the innermost layer is still our own measured execution energy.
Our engine
Active execution
Per-token joules from the four-way token split (prefill, decode, cache creation, cache read), through PUE and grid intensity.
GHG Scope 2
Facility operational
Active energy scaled by host overhead (×1.18) and cluster utilization (÷0.3) — the server and idle-fleet cost of serving your request.
GHG Scope 3
Full lifecycle
Operational plus embodied hardware (0.02 kg/MTok) and amortized model training (0.008 kg/MTok), carried as its own line — never blended in silently.
Your dashboard headline is Layer 3, the full lifecycle footprint. Layers 1 and 2 are persisted alongside it so any number can be inspected down to the active silicon.
Per request, we split tokens into categories, compute their active energy, then widen to operational and lifecycle. Cached input tokens are near-zero cost because the provider skips the KV-cache rebuild.
Categorize tokens
Split each event into uncached_input, cached_input, cache_creation, and output. Anthropic and OpenAI report these separately; OpenRouter doesn't break out cached, so all input is treated as uncached (conservative default).
Layer 1 — active energy → CO₂
Active energy (J) = uncached × prefill_J + cache_creation × prefill_J + cached × cached_J + output × decode_J, then layer1_kg = J ÷ 3,600,000 × PUE × grid. Prefill and decode are separate because decode is autoregressive and prefill is parallelizable.
Layer 2 — facility operational (Scope 2)
layer2_kg = active_kWh × 1.18 ÷ 0.3 × PUE × grid. Host overhead accounts for the whole server beyond the accelerator; dividing by cluster utilization allocates the idle fleet capacity that has to exist to serve you.
Layer 3 — full lifecycle (Scope 3)
layer3_kg = layer2_kg + (embodied + training) × tokens ÷ 1e6 with embodied = 0.02 and training = 0.008 kg per million tokens. Training is carried as its own component so it is always visible, never folded invisibly into the operational number.
Uncertainty — IPCC Tier 1 RSS
Combined uncertainty is the root-sum-of-squares of activity-data and emission-factor uncertainty: √(20² + 20²) ≈ 28.28%. Bounds are layer3 × (1 ± 0.2828). These bands are real and material — energy-per-token varies with hardware generation, batch size, and inference framework.
Each model is matched to a tier by pattern. Active energy comes from published GPU power draw for representative deployments; reasoning tiers get a higher decode coefficient because extended-thinking chains amplify output-side compute. PUE and grid intensity vary by provider fleet.
| Tier | Prefill (J/tok) | Decode (J/tok) | Cached (J/tok) | PUE | Grid (kg/kWh) |
|---|---|---|---|---|---|
Small / Distilled small | 0.100 | 0.200 | 0.0100 | 1.20 | 0.420 |
Medium / Flagship medium | 0.300 | 0.500 | 0.0300 | 1.20 | 0.420 |
Large / Frontier large | 0.500 | 0.900 | 0.0500 | 1.20 | 0.420 |
Reasoning (extended thinking) reasoning | 0.500 | 1.800 | 0.0500 | 1.20 | 0.420 |
Gemini Flash gemini_flash | 0.080 | 0.500 | 0.0080 | 1.09 | 0.345 |
Gemini Pro (reasoning) gemini_pro_reasoning | 0.350 | 2.500 | 0.0350 | 1.09 | 0.345 |
Gemma (open weights) gemma_open | 0.040 | 0.160 | 0.0040 | 1.09 | 0.345 |
Google embeddings google_embedding | 0.004 | 0.000 | 0.0004 | 1.09 | 0.345 |
We match each model name against these glob patterns at calculation time. Unknown models fall back to medium as a conservative default. If a model you use isn't covered, let us know and we'll add it.
gpt-4o-mini*gpt-3.5-turbo*gpt-5-nano*claude-haiku*claude-3-haiku*text-embedding-3-small*gpt-4o*gpt-5-mini*claude-3-5-sonnet*claude-sonnet*text-embedding-3-large*gpt-4-turbo*gpt-4*gpt-5*claude-3-opus*claude-opus*o1*o3*o4*claude-3-7-sonnet*gemini-3.5-flash*gemini-3-flash*gemini-2.5-flash*gemini-2.5-flash-lite*gemini-3.1-pro*gemini-2.5-pro*gemma-4-*gemma-3-*gemma-2-*codegemma*gemini-embedding-2*gemini-embedding-001text-embedding-005text-embedding-004One million tokens on the medium tier (GPT-4o class): 750k uncached input, 250k output, no caching. PUE 1.20, grid 0.42 kg/kWh.
The headline your dashboard shows for this workload is the Layer 3 figure, ~0.22 kg CO₂ per million tokens, with the active and operational layers inspectable underneath it.
The dashboard also estimates the water behind your AI use: water a data centre uses on site, mostly for cooling, and water power plants use to make its electricity. It is an estimate with a wide range. The signed Footprint Statement records it beside the carbon, with its water version; receipts and audit packs never include it.
Usage counted in tokens
Water = operational_kWh × (WUE ÷ PUE + grid_water). Here operational_kWh is the energy the whole data centre uses to run your tokens, the Layer 2 energy above, so water and carbon count the same energy. PUE (power usage effectiveness) is the energy the whole data centre uses for each kWh its servers use: 1.20 on most tiers and 1.09 on Google's. WUE is per kWh of server energy and operational_kWh already includes PUE, so WUE is divided by PUE to count it once. That gives 1.8 ÷ 1.20 + 2.18 = 3.68 litres per kWh, or 3.83 on Google's tiers.
Microsoft 365 Copilot prompts
Copilot is counted in prompts, and the energy we estimate for a prompt already includes the whole data centre. The formula is the same, with a reference PUE of 1.2: facility_kWh × (WUE ÷ 1.2 + grid_water), which is 1.8 ÷ 1.2 + 2.18 = 3.68 litres per kWh.
Water version v1.2-w2
Water has its own version, so changing it does not change the carbon methodology (v1.2). Water calculated before v1.2-w2 keeps the value it was calculated with, labelled v1.2: for tokens it followed the chip energy (Layer 1) with 2.5 litres per kWh of grid water, so it reads about 3.6 times lower for the same usage.
Uncertainty
We keep a low and a high value 50% either side of each estimate: water × (1 ± 0.5). For Copilot prompts the band is applied to the low and high energy of each prompt, so the range is wider. The dashboard shows the central estimate.
WUE is the average on-site water use of US data centres from Berkeley Lab's data centre energy report (Shehabi et al., 2016) (opens in a new tab), also the typical cooling requirement in Siddik, Shehabi and Marston (2021) (opens in a new tab). Grid water is the US average water consumed per kWh generated, for the 2015 generation mix, from Lee, Han, Elgowainy and Wang (2017) (opens in a new tab). Both are national averages, the same for every provider. The 50% band is CrbonFree's own.
The sentence on the water card compares the estimate with one thing, and the thing changes from day to day: days, months or years of one person's water use at home (opens in a new tab) (82 US gallons, about 310 litres, a day), an average shower (opens in a new tab) (18 US gallons, about 68.1 litres) or a toilet flush (opens in a new tab) at the US federal standard (1.6 gallons, about 6.06 litres), all from US EPA WaterSense. A very small amount is compared with a 500 mL bottle.
The layered boundary, factor values, and uncertainty approach draw on the Watershed framework, the GHG Protocol, IPCC guidance, and peer-reviewed research.