Electricity
A cleaner grid changes the balance.
Lower operating emissions make manufacturing a larger share of the total. Changing the operating grid does not undo the footprint of making the hardware.
Explore the crossover chart ↗ A clearer picture of AI's footprint
The full-stack footprint of AIfrom chip to token.
Explore the carbon footprint and water consumption of AI workloads, from hardware manufacturing to everyday use.
Built on REEL LCIThe carbon of compute is the greenhouse gas burden of running a computing workload, counted across four parts: the electricity the hardware draws while it works, the manufacturing burden built into that hardware and spread over its working life, the facility overhead that keeps it powered and cooled, and the share of model training the workload carries, which a reader can include or leave out. This site estimates those parts for AI workloads, from the chip up to a single response, and reports water consumption beside carbon where the evidence allows. The hardware part is built on REEL LCI, a life cycle inventory database of electronics manufacturing that records the source or the derivation behind its flows.
The model explorer
Same workload. Different footprint.
Grid evidence: this legacy NWPP life cycle estimate has an untraced upstream adjustment. It is an annual-average engineering scenario, not a verified marginal factor. Grid sources and boundaries →
Scenario settings
Reasoning
Measured and estimated inputs; workloads, hardware and latency criteria differ. Reading guide ↗
OperationalHardwareFacilityTrainingEach bar = 100% of footprint · composition
| # | Model | gCO₂e / 1M tokens ▼ | Footprint breakdown | Estimated range |
|---|
No calculated models match your search.
Release identities checked September 5 and October 10, 2026. These models have no footprint estimate and are excluded from rankings and usage totals. Missing evidence is not zero impact. This list follows model search across providers; tier filters apply to calculated rows only.
Operational evidence reviewed September 5, with OpenAI and Anthropic releases added October 10: measured inputs and documented estimates, with an optional matched benchmark filter. Training synthesis remains June 27; benchmark run dates are unresolved. Sources, availability and reference calculations →
How to read these results
Compare the same work
Compare magnitude in the numeric totals. Each bar is 100% stacked: colors show each layer’s share of that model’s footprint, or its covered water subtotal.
Read the range, not just the rank
Ranges reflect each input’s evidence: observed configurations for measurements, documented scenarios for estimates, plus environmental assumptions and optional training. Measured central values select the lowest observed GPU energy within their stated conditions. These spans are not confidence intervals and do not quantify every transfer assumption. Some training estimates have no quantified range and stay fixed in the calculation; each model's breakdown explains this. Overlapping ranges mean the ranking may not be meaningful. The small range markers use a shared logarithmic scale.
What the water estimate leaves out
Electricity-generation water is included. The water estimate does not include model training or making the data center's power and cooling equipment. Hardware-manufacturing water is also incomplete. Models without hardware-water data are marked in the results; missing data does not mean zero water use.
Water ranges combine complete operational configurations with cooling and hardware-allocation scenarios. The selected grid, reservoir setting, PUE and hardware life stay fixed. These spans do not quantify all model-transfer, background-factor or manufacturing-inventory uncertainty, and do not cover omitted layers. The separate benchmark-response view retains its own documented scenario span. The reservoir setting includes or excludes gross evaporation allocated to hydropower. See the method report for coverage and cooling-factor limitations.
What the badges tell you
Measured and Derived describe the operational-energy evidence, not the whole footprint. Estimated rows use weaker evidence and are not directly comparable to measured rows.
Explore what drives the footprintGrid intensity, hardware, and price
These charts explore carbon. They use the current scenario and all models in the selected model tier.
When does electricity overtake the rest of the footprint?
Change the operating electricity grid while holding hardware, facility, and training assumptions fixed. The crossover is where the two contributions are equal.
Operating electricityHardware + facility + training
Scroll the chart sideways to explore the full scale.
Price vs. carbon
Scroll the chart sideways to explore the full scale.
From models to everyday use
What does your workload add up to?
Illustrative output volumes
Your yearly footprint Based on the output-volume presets
I use about
per
.
Agentic use: counting the input Same model as the presets · per 1M billed output tokens, thinking included
Rates are per output token, measured or estimated on short chat-style requests. Agent tools and long documents can send several hundred input tokens for each output token, most of them read from a prompt cache. That input work is not counted in the leaderboard or the presets above; the agentic profile here adds it as a separate input term.
For the agentic coding sessions we measured, counting the input raises the result per billed output token about 4.3 times in the central case. In the low case it raises the model's own low-scenario rate at least 1.3 times. We found no upper bound. It is higher if attention cost grows with context (about 10 to 11 times for a dense-attention model) or if cache reads cost more than assumed.
Assumptions and limits
- The token shape is our own measurement of 24 hours of agentic coding sessions with Claude Opus 5.5: 6.72 cache writes and 493.3 cache reads per output token, output including thinking. A public vLLM agentic trace has about 320 input tokens per output token, taking the ratio of its median input and median output. Applying the shape to any other model, including Sonnet 5.5 and Haiku 5.5, is a transfer. Haiku 5.5 is the weakest transfer: its prompts over 100,000 tokens are billed at 5 times its input price, a different long-context regime.
- A cache read is assumed to cost 0.01 of a fresh prompt token, and attention cost is assumed not to grow with context. Both are declared choices, not measurements. Reading one new prompt token is taken to cost 0.45 of the energy of generating one output token. That ratio comes from server time, not measured energy, at one provider for one model family.
- The leaderboard rate already includes the prompt work of its own short requests, about 0.3 to 1 input token per output token. The input term multiplies only the rest of the rate, taking that prompt at 1 input token per output token, so no prompt work is counted twice. If the prompt was nearer 0.3, the agentic and uncached figures would be 1.28 times higher, so they may be up to about 22 per cent too low. The rate for Gemini 2.5 Flash comes from a production average per prompt, so the prompt work inside it is not known.
- The electricity of holding prompt caches between turns is not counted.
- Water scales with the same multiplier as carbon. Two water lines scale: operational water (on-site cooling and the water used to generate the electricity) and, where available, hardware water (manufacturing water, allocated by the same GPU time as IT embodied carbon). The training term does not scale, and no training water is included.
- Opus 4.8, Opus 5, Opus 5.5, Fable 5 and Fable 5.1 are held in the agentic and uncached profiles. Their rate is per visible output token. To put it per billed token it is divided by the number of billed tokens per visible token, and for these models that number is an older assumption of 7 that has not been checked against measured token use. So no figure per billed token is shown, and no comparison of Opus with Sonnet per token.
- Other reasoning models are held for the same kind of reason when their thinking ratio was borrowed from another model or set by class analogy rather than measured for that model. Of the rows with a thinking ratio, only DeepSeek-R1, Gemini 2.5 Flash and Qwen3 235B-A22B have one measured on the same model or the same backbone, so only they show agentic figures. Each held row is listed in the method report; the source line of each ratio is in the data file.
- The long-context uncached profile charges every cache read as a fresh prompt token. It is a stress case, not a likely value.
A measured benchmark responseExplore the source workload
Uses the grid, PUE, cooling, lifetime and utilization controls above. Benchmark hardware and thinking mode stay fixed; training is excluded. These model-generated responses differ in length and are not matched for answer quality.
Source and calculation boundary
Go a layer deeper
Understand the footprint.
A prompt uses electricity, but its footprint starts before you press send.
What we count
The detailed boundary ↗Running the model
Electricity for the accelerator, host computer and data-center overhead.
Making the hardware
Manufacturing chips, memory, packaging and host equipment, spread over their use.
The facility
Power and cooling infrastructure, backup fuel and refrigerant losses.
Training the model
Training emissions spread over estimated lifetime output; optional in the settings.
What water leaves out: the water estimate does not include model training or making the data center's power and cooling equipment. Hardware-manufacturing water is also incomplete; models without hardware-water data are marked in the results.
Workload
The task matters, not just the model.
A short answer and a long research session are different amounts of work. Output length, hidden reasoning and repeated calls all affect the footprint.
Compare everyday workloads ↑Water
Low-carbon is not always low-water.
Electricity sources have different carbon and water profiles. Cooling and reservoir evaporation matter too, so the two footprints need separate comparisons.
Explore the water estimates ↑More tools and detail
Read the full methodology ↗Generative media - image & video · side board
Beyond text: the carbon of generating one image or one second of video, through the same engine (operational + embodied + facility) at the default data-center scenario. The dominant driver is the output spec - resolution, denoising steps, clip length - which swamps the choice of model. Closed providers disclose no energy, so those rows are badged estimates and video is low-confidence - read the range, not the point. Units are incommensurable: an image, a second of video, and a token are never directly comparable.
| Image model | gCO₂e / image | range | confidence |
|---|
| Video model | gCO₂e / sec | per 5 s clip | range | confidence |
|---|
How to read this. Closed models (Imagen, gpt-image, Sora, Veo, Kling, Runway, Pika, Luma, Hailuo) disclose zero energy - their rows are class-proxy estimates with wide bands. Frontier video (Sora, Veo) is physics-anchored (bottom-up DiT FLOPs); the commodity models are priced against the one measured open anchor, WAN-14B. For scale: a 15-second frontier clip ≈ 1 kg CO₂e, comparable to ~1M output tokens of a reasoning flagship - video diffusion is more efficient per FLOP than memory-bound text decode, which closes the gap. Training is excluded from these figures (corrected for the per-unit basis it adds only ~10% to the base, but the lifetime-images/-seconds denominator is too soft to default on). All at the default scenario (US grid 386 gCO₂e/kWh, PUE 1.15); see the methodology. Never sum across modalities.
02Use it for Scope 3: AI is a purchased service
Explore an illustrative emissions scenario for monthly visible-output volumes using the selected models. These conditional factors include modeled operation, hardware and facility contributions. A commercial API can use different hardware, batching, software and workloads; matching a model name alone does not validate an inventory factor.
Match the evidence to your use
- Supplier-specific evidence - use a provider's documented energy or emissions with matching model, region, workload and accounting boundaries when available.
- Your measured deployment - pair measured electricity and hardware time with your actual configuration and workload. Keep input, visible-output and hidden-thinking tokens separate.
- This calculator scenario - apply a model’s measured, derived or estimated rate to visible-output volume. Check deployment differences before using it in an emissions inventory; the displayed span is not complete uncertainty.
- Unlisted models or spend - select a documented reference scenario only when its assumptions fit; API price alone does not establish energy.
Pull your token activity (by model, type, project)
| OpenAI | Usage API · dashboard · cost export | tokens by model, input vs output, reasoning tokens, by project/key |
| Anthropic | Usage & Cost API · Console | uncached input, cache-write, cache-read and output tokens by model, by workspace/key |
| Google Gemini/Vertex | Cloud Billing → BigQuery · Vertex metrics | tokens by model, by project, by region |
| Azure OpenAI | Azure Monitor · Cost Management | tokens by deployment/model, by resource |
| AWS Bedrock | CloudWatch · Cost & Usage Report | input/output tokens by model, by account/tag |
| Self-hosted | vLLM/TGI metrics + GPU-hours | tokens by model + your measured kWh (best - your own grid) |
| Image / Video gpt-image · Sora · Imagen · Veo | Usage API · Vertex · dashboards | images generated, seconds of video, by model / quality / resolution |
Capture: model · uncached input tok · cache-write tok · cache-read tok · output tok · reasoning tok · modality · project/cost-center · region · period.
Explore monthly output volume
Enter monthly visible output tokens using a denominator compatible with the selected model's rate. Do not paste inclusive billed output: it can include reasoning already represented in that rate. Subtracting reported thinking from output does not automatically recover native visible tokens. If the denominator is unresolved, keep this an illustrative volume scenario. Grid, PUE and hardware assumptions follow the controls above. Training is excluded by default and can be included where an estimate exists. Measured benchmark configurations have thinking off; estimated reasoning rows use their declared work assumptions. In the agentic and uncached profiles, enter billed output and the three input fields from your provider's usage data. The input term then applies, and the result has a floor but no upper bound. Training is added once and is not multiplied. A model whose thinking ratio was not measured for that model, the Opus group included, shows no figure in these profiles.
| Model | Visible output tokens / month | Factor gCO₂e/1M output | Monthly CO₂e |
|---|
Scope and limits. Default carbon covers inference electricity, IT manufacturing and facility contributions. It excludes training unless selected. The measured task is text chat. In the chat profile, output-volume scaling does not count long-context prefill, RAG or tool input separately; the agentic and uncached profiles add an input term for cached and uncached input. Successful task completion is not modelled. These results require deployment-specific validation before inventory use. Models without matching evidence are unavailable. Image and video use separate units and an older evidence set in the media side-board.
03Comparisons need context
Everyday comparisons can make a footprint easier to picture. To make them useful, check what each number counts.
Why compare AI queries with almonds?
A widely reported comparison equates 38,000 ChatGPT queries with the water used to produce one California almond. It offers a familiar reference point, but the two numbers need matching definitions.
A California life cycle study gives about 5.8 liters per almond, using a 1.2 g kernel. It counts applied freshwater across production, excluding rainfall; this is not a direct measurement of net consumption.
Other estimates use different regions or water definitions. An AI comparison also needs a defined workload and matching boundaries for cooling, electricity and manufacturing. There is no universal queries-per-almond conversion.
Sources in the methodology section.
04Training footprints: before the first prompt
Training depends on both the amount of compute and its electricity supply. Published figures also differ in which training stages and infrastructure they include. The examples below are not a like-for-like ranking.
How we include training when a lab does not report it
A missing disclosure does not mean we assign zero. The earlier Claude entries used modeled training scenarios, not Anthropic-reported footprints. These entries are now withheld from numerical calculations pending operational evidence. Sonnet 4.6 and Opus 4.8 use third-party compute estimates for earlier related models, with assumptions about hardware, power and electricity supply. Haiku 4.5 has a rough estimate with a documented evidence gap.
The leaderboard excludes training by default. To include it, select a lifetime-output scenario in Scenario settings. We spread the estimated training emissions across the output tokens we expect the model to produce over its lifetime. Where research provides bounds, the range changes both the training estimate and how many tokens share those emissions. These are alternative scenarios, not statistical confidence intervals. Where bounds are unavailable, the training estimate stays fixed; this is explained in the model's breakdown.
The table below is a separate collection of published training examples, not the list of inputs used for every model above. Open a model's result for its training source, or read the training calculation and assumptions.
| Model | Org | Year | tCO₂e | GPU-hours | Hardware / grid | Embodied? | Conf. |
|---|
05Before use: making the hardware
Operational energy gets all the attention because it is easy to meter. The carbon emitted to manufacture the silicon, memory, and server is far harder - it needs a bottom-up inventory of the chips themselves. That is exactly what REEL LCI is. Below: cradle-to-gate manufacturing carbon per accelerator, shown as a range where both a REEL-derived estimate and a vendor footprint are available.
These figures come from the published REEL LCI 1.0 release. The component inventories, the memory capacity mappings and the comparison with vendor footprints were rechecked together against that release. Each line of the bill below opens the dataset it was read from, so any figure here can be traced to the published inventory behind it.
Embodied carbon per accelerator (kg CO₂e, cradle-to-gate)
The spread compares a component-level model with an allocated vendor product footprint; it is not a statistical uncertainty interval. Differences can reflect component coverage, manufacturing assumptions and allocation. The older per-stack HBM comparison is retired; the HBM figures shown are each accelerator's share from the published REEL LCI 1.0 inventories.
Why embodied is really a grid story
Manufacturing uses electricity too. A chip's embodied carbon reflects the fab's electricity supply, process emissions and material inputs at the time it was made.
- Embodied carbon falls as fabs decarbonize - it isn't fixed.
- As the operating grid cleans up, manufacturing becomes a larger share of the total, holding other assumptions fixed. Compare grids in the model explorer to see this relationship.
06Methodology
Every number traces to a public source or a published REEL inventory. The differentiator is the bottom-up, process-node-resolved silicon inventory underneath the embodied numbers - granularity no other AI-carbon tool exposes. Sources and the background characterization are detailed below.
This is a characterized derivative of REEL LCI inventory data, built for public
communication. REEL builds its bottom-up foreground inventory (energy, materials, emissions) from public
specifications; that inventory is then characterized to kg CO₂e, m³ water, etc. using ecoinvent 3.12 cumulative
LCIA as the background (IPCC 2021 GWP100 for carbon, ReCiPe 2016 WCP for water). The differentiator is the
process-node-resolved foreground granularity, not the background method. Figures are best-available estimates
with documented uncertainty, not a measurement of any specific deployment. The full calculation chain - every input,
its source and confidence, and one model worked end to end - is in the
method report companion; the facility-side numbers draw on the
REEL LCI white paper Modeling the AI Factory. Hardware snapshot and pending refresh.
What we count (the boundary)
Total carbon per output-token workload = operational + hardware manufacturing + facility + training-amortized.
- Operational - energy of the active accelerator + host CPU/DRAM (the "node"), uplifted for idle/provisioned machines (×1.12) and data-center overhead (PUE), times the grid's carbon intensity. The broad view includes measured, derived and estimated inputs with their source boundaries. Shared overhead assumptions create a common accounting scenario; they do not establish production deployment equivalence. Separately executed routing, safety and scoring models, retrieval, storage and tool services are not consistently covered. Google's Gemini Apps source includes supporting models; single-checkpoint benchmarks do not establish that broader coverage. Host, idle and PUE multipliers do not add those services. We also report the narrow "accelerator-only" number - the one most benchmarks quote - which counts the accelerator's own draw alone. The full-stack number on this page also counts the host CPU and DRAM, the idle and provisioned machines and data-center overhead, and comes out ~1.8× the narrow one (Google reports a comparable ~2.4× for Gemini).
- Embodied - cradle-to-gate manufacturing carbon of the accelerator (logic die + HBM + advanced packaging) plus its share of host compute, fabric and storage, using REEL inventories, vendor footprints or explicitly named hardware proxies. It is amortized over active accelerator-hours: measured paired time where available, otherwise time inferred from the stated energy and power assumptions. Manufacturing data describe a device; this allocation assigns its lifetime burden to a workload.
- Facility (non-IT) - the rest of the data center: embodied carbon of the power chain and cooling plant (annualized), plus standby diesel generator operation and refrigerant fugitive emissions - contributions that grid×PUE does not capture. Allocated per kWh of IT energy (from REEL's Modeling the AI Factory reference hall). Refrigerant uses the IPCC 2006 Tier 2 chiller life cycle (install + annual operation + end-of-life) at optimistic hyperscale leak rates, and uses the same default R-134a scenario for measured benchmarks. Older provider-specific scenarios remain assumptions; model authorship does not identify a benchmark deployment operator.
- Training-amortized - an assumed training footprint spread over lifetime served output tokens. Inputs include disclosures, compute-based reconstructions, proxies from related models and rough estimates where evidence is sparse. The range uses model-specific training scenarios where documented, together with low and high lifetime output. It does not cover every uncertainty in power, grid or training stages. Where no supported training bounds exist, that gap is flagged rather than assigned an arbitrary percentage. How this works for Claude.
- Water - reported separately (L per 1M tokens; toggle the leaderboard to Water): three layers - on-site cooling (WUE, by heat-rejection backend) + semiconductor manufacturing water where data is available, spread over its use. Electricity-generation water uses facility electricity including PUE and regional life cycle estimates based on ecoinvent background results and public generation mixes. Covered hardware comprises accelerator die/HBM/package and host CPU, system DRAM and NVSwitch. Storage, boards, NICs, PSUs, chassis and fabric lack corresponding water terms. TPU/Trainium hardware water, model training and making the data center's power and cooling equipment are also unestimated. Missing data does not mean zero water use.
The displayed total range spans complete configurations for measured inputs or documented scenarios for estimates, plus hardware-utilization and optional training-estimate scenarios. Each configuration retains its paired energy, power and throughput. Host/idle transfer uncertainty is not quantified. This scenario range is not a statistical confidence interval or a production deployment range.
The functional unit & standardized workloads
Primary unit: gCO₂e per 1,000 visible output tokens. Input processing for each source's own short prompts is included within that source's boundary. Longer agentic input is added as a separate input term in the agentic and uncached profiles, never in the ranking. Workloads scale the selected rate to an output-token budget; they do not measure equal-quality task completion: . Image and video generation use a per-image unit and are reported separately.
What drives the range
The carbon range combines the assumptions we can vary, including documented training-estimate bounds where available. It is not a range for every input. Missing training bounds are flagged. The token leaderboard and benchmark-response view each show a scenario span for covered water. These spans do not cover missing layers or every source of uncertainty.
Embodied carbon is allocated over active accelerator time. The lifetime busy fraction is the assumed share of installed life spent serving at the rate represented by the selected configuration. We retain 0.15, 0.33 and 0.55 as low, central and high allocation scenarios. These values are not measured fleet busy-time fractions or SM-utilization readings. Device occupancy, performance relative to a peak rate and commercially reserved capacity measure different quantities. Lower lifetime busy fractions spread manufacturing over fewer served tokens; no matching production observation validates this scenario band.
Native hardware allocation uses each selected configuration's measured GPU-time per output token. Embodied share can therefore differ between models on the same chip. Hardware lifetime and serving utilization remain scenario assumptions. An accelerator override changes the manufacturing allocation using rated-power assumptions; it does not predict that chip's operational performance.
Embodied carbon: data sources & the HBM caveat
REEL LCI bottom-up inventory characterized to kg CO₂e via ecoinvent 3.12 IPCC-2021 GWP100 (background flows) + IPCC AR6 (direct fab gases). Accelerator & server bills of materials are reconstructed from public specifications (die area, HBM stack counts, package type, server BOM). Vendor PCFs (NVIDIA HGX H100 1,312 kg/board; B200 2,274) and Google's TPU LCA are shown alongside for the range. The HBM figures above are read from the published REEL LCI 1.0 inventories, as each accelerator's HBM share; older per-stack contrasts are not shown and should not be treated as current REEL results. Die carbon uses geometric dies-per-wafer without a defect-yield derate - an optimistic (lower-bound) simplification (it would raise reticle-scale dies, but moves the server total <4%). System DDR5 DRAM (about 29% of host embodied) has no external PCF and is the next-largest sensitivity.
Operational energy: comparison protocol and sources
Measured means direct operational energy observations under the stated configuration. Derived means a reconstruction from published quantities. Estimated includes declared predecessor, architecture, power and reasoning assumptions. These labels describe operational inputs; the complete carbon and water results include modelling in every case.
The default includes all supported evidence types. Scenario settings can filter them, including a matched H100 BF16 non-thinking chat cohort with a 50 ms p95 token-gap screen. Other measurements retain their actual hardware, precision and latency. Neither view establishes equal answer quality or actual commercial API operations.
Native measured GPU-time uses paired power and throughput. Host, idle, grid and manufacturing allocation remain scenarios. Measured ranges span configurations; estimated ranges cover only documented scenarios, with additional uncertainty left unquantified. Google's May 2025 Gemini Apps aggregate supports an explicitly assumed 300-output-token family proxy, not an exact-version measurement. The six earlier rates now use explicit repaired transfers. Entries without a defensible numerical reference or architecture premise remain searchable without numbers. Sources and individual reviews.
Cite this explorer
Include a scenario link when citing a specific result so readers can see the assumptions.
BibTeX
@misc{balsvik_carbon_of_compute_2026,
title = {The Carbon of Compute: a public-data leaderboard of AI workload
carbon (operational + embodied + facility)},
author = {Balsvik, Jonathan},
year = {2026},
note = {REEL LCI},
url = {https://carbonofcompute.com/}
}
Plain text: Balsvik, J. (2026). The Carbon of Compute. REEL LCI. https://carbonofcompute.com/
Go from the footprint to its foundations.
Built on REEL LCI, the bottom-up environmental inventory for the electronics inside AI. The unaggregated, component-level data (per wafer, per HBM stack, per package) is available as REEL LCI datasets.
Browse the underlying datasets → Need support?