Methodology

Last reviewed: 2026-09-28. Changes are listed in the changelog at the bottom of this page.

LowRouter estimates the carbon footprint of every inference request using the formula and data sources described on this page. This is the reference document; the numbers on the dashboard, the model browser, and the API responses all come from it.

What we report

Two numbers per request:

  • Energy in watt-hours (Wh).
  • Carbon in grams of CO₂ equivalent (gCO₂e).

The carbon number is also normalised to gCO₂e per 1,000 generated tokens so requests of different sizes are comparable.

The formula

Text
energy_wh   = ((α × P_active) + β) × completion_tokens
carbon_g    = energy_wh × PUE × grid_intensity_g_per_kwh / 1000

Where:

  • P_active: number of active parameters during inference, in billions. For dense models this is the parameter count; for Mixture-of-Experts (MoE) models it’s the parameters activated per token, not the total count.
  • α = 8.91 × 10⁻⁵ Wh per output-token-billion-param.
  • β = 1.43 × 10⁻³ Wh constant overhead per output token.
  • completion_tokens: the tokens the model generated. Prompt tokens are not counted: see prompt tokens below.
  • PUE = 1.20: data-center Power Usage Effectiveness, the overhead for cooling and power distribution on top of the compute energy itself. Applied to every request.
  • grid_intensity_g_per_kwh: annual-average carbon intensity of the electricity grid in the region serving the request.

The / 1000 in the carbon line is the Wh → kWh conversion: energy is carried in Wh (EcoLogits’ native unit) while grid intensity is published per kWh.

The energy formula is the EcoLogits v0.4 inference model. The grid-intensity values are Ember Climate annual country averages, replaced by regional grid-operator data where a supported operator publishes it (see data sources).

Prompt tokens

EcoLogits counts generated tokens only. Its maintainers treat the prompt-processing (prefill) phase as negligible next to generation, because the GPU processes a prompt’s tokens in one parallel pass, while generation produces one token per pass and is limited by memory bandwidth. α and β are therefore per-generated-token coefficients, and we apply them to completion_tokens only.

This under-counts requests that are mostly prompt, such as agent loops and retrieval-augmented generation with long contexts and short answers. Published estimates of a prompt token’s energy relative to a generated one range from about 0.03× (prefill throughput benchmarks) to 0.35–0.65× at 10k–100k-token contexts (Epoch AI). Nobody publishes a single, validated factor, and EcoLogits has not adopted one (discussion #86). We follow the cited methodology rather than invent a factor, and will adopt EcoLogits’ treatment if it adds one.

Embedding requests are outside EcoLogits’ scope: an embedding generates nothing, so its estimate applies the model’s per-token figure to the input tokens instead. See limits.

Why this formula

The EcoLogits model is published, peer-reviewed in spirit if not fully formally, and reproducible from public model parameter counts. Other credible estimates exist, but this one has the clearest derivation and the most active maintenance. Using it for every provider means numbers are compared on the same basis, without reconciling each provider’s own estimate.

Confidence bands

Every estimate carries one of three labels:

BandWhen
accurateModel size verified by the provider or in the EcoLogits registry; recent grid data.
mediumModel size from a credible third party (research paper, well-supported leak); grid data current.
grossModel size estimated from the model name or industry rumour; or grid data older than 12 months.

These bands describe uncertainty in the inputs, not whether the formula itself is right. The formula has its own model-class limits documented on the limits page.

The bands are ordinal, not quantified: accurate rests on better-grounded inputs than medium, which is better-grounded than gross. We deliberately do not publish a percentage error for each band. We have not run a validation study against measured energy consumption, and we are not willing to attach a number to a carbon figure without one, because readers take an invented error bar for a measured one. The dominant source of error is the model’s active-parameter count, which enters the formula multiplicatively and asymmetrically, so a symmetric ± would misrepresent it even if we had measured it.

When the band is gross, the dashboard widgets that aggregate carbon across many requests show a reduced-confidence indicator and link back to this page.

Methodology versioning

Every estimate stores the methodology_version that produced it (see per-request metadata). The version captures:

  • The values of α and β.
  • The grid-intensity dataset version (Ember Climate country averages plus regional grid-operator data; see data sources).
  • The model parameter-count dataset version.

When any of these change, the version is bumped and the change is noted in the dashboard’s footer with the date. Old generations are not recomputed retroactively: their methodology_version is the one in effect when the request was served.

Worked example

A request:

  • Resolved model: openai/openai/gpt-4o-mini.
  • Active parameters: 8B (this is the value we use; the provider has not officially confirmed it, so the band is medium).
  • Tokens: 1,200 prompt, 200 generated (completion_tokens).
  • Provider region: eu-west.
  • Grid intensity: 270 gCO₂e/kWh (Ember 2024 EU average).

The EcoLogits v0.4 coefficients are in watt-hours per output token, which is also the unit energy is stored and reported in, so no conversion sits between the published formula and energy_wh:

Text
energy_wh_per_token  = (α × P_active) + β
                     = (8.91e-5 × 8) + 1.43e-3   = 0.002143 Wh/token
energy_wh            = 0.002143 × 200            = 0.43 Wh   (prompt tokens not counted)
carbon_g             = 0.43 × 1.20 × 270 / 1000  = 0.139 g
carbon_per_1k_tokens = 0.139 × (1000 / 200)      = 0.70 g    (per 1,000 generated tokens)

So a 200-token completion on gpt-4o-mini from eu-west is estimated at 0.43 Wh and ~0.14 gCO₂e, with medium confidence. These are the numbers your eco block would carry.

If you find a discrepancy between this worked example and what the gateway returns, the gateway is the source of truth. Please file an issue so we can fix the documentation.

Everyday equivalences

The dashboard and model pages translate a measured gCO₂e figure into everyday terms: kilometres driven, phone charges, tree-days. These are illustrative framing and not part of the estimate. Each one divides the measured emissions by a single published factor:

EquivalentFactorSource
Phone charge12.4 gCO₂e per full smartphone chargeUS EPA Greenhouse Gas Equivalencies Calculator
Car travel106.7 gCO₂e per kilometreEuropean Environment Agency
Tree uptake60.3 gCO₂ per tree-dayEuropean Environment Agency
Text
phone_charges = carbon_g / 12.4
car_km        = carbon_g / 106.7
tree_days     = carbon_g / 60.3
tree_years    = tree_days / 365

Some surfaces show tree-years (or trees/yr) instead of tree-days; those divide the tree-day count by 365 at the same per-day factor, so both readings trace back to the one published number.

What each factor is, precisely

  • Phone charge: 12.4 gCO₂e. The EPA calculator’s figure (1.24 × 10⁻⁵ metric tons per charge). Its derivation: a charge draws 28.446 Wh − (22 h × 0.411 W) = 19.404 Wh, which at the 2022 US national weighted average rate for delivered electricity (1,405.3 lb CO₂/MWh, including transmission and distribution losses) gives 12.4 gCO₂e. The EPA page displays the energy rounded to 0.019 kWh but carries the unrounded value through; using the rounded figure yields 12.1 g, so we quote the unrounded one to keep the arithmetic reproducible. This is a US grid number; the same charge on a lower-carbon grid emits less. We use it because it is the most clearly documented per-charge figure available, not because US grid intensity is representative of our routing.

  • Car travel: 106.7 gCO₂e/km. The EEA’s average for passenger cars newly registered in the EU in 2024. Anyone citing it should know two caveats: it covers new registrations rather than the whole on-road fleet (older cars in service emit more), and type-approval values are known to understate real-world emissions (the ICCT has documented a widening gap, most sharply for plug-in hybrids). Treat this as a conservative floor, not a fleet-wide figure.

  • Tree uptake: 60.3 gCO₂/day. Derived from the EEA’s statement that a mature tree takes up roughly 22 kg of CO₂ per year (22,000 ÷ 365). This is the weakest-sourced of the three: it is a widely-repeated rule of thumb rather than a result traceable to a specific field study, and real uptake varies substantially by species, age, and site. We keep it because it is the figure public discussion uses, and we flag its weakness here.

The factors live in one place in the codebase (frontend/src/utils/carbonEquivalents.ts) and this page is checked against that module by a test, so the numbers here and the numbers on the dashboard cannot drift apart.

The full picture

Read the data sources page next for where each number in the formula comes from. The limits page lists what we explicitly do not claim.

Changelog

  • 2026-09-28: Request energy counts generated tokens only, as the EcoLogits model this page cites does (#733). It previously applied the per-generated-token coefficients to prompt tokens as well, which charged every prompt token a full generation step: a 40,000-token prompt with a 2-token answer was reported as 141 Wh instead of 0.007 Wh. Figures for prompt-heavy requests drop sharply; requests dominated by generated output barely move. Requests recorded before this date keep their stored figures. Per-token figures in the model catalogue and routing are unchanged.

  • 2026-08-19: Everyday equivalence factors published with their sources for the first time (#438). Two of the three were corrected in the process: the phone-charge factor moved from 8.22 g to the EPA’s documented 12.4 g, and the car factor from 171 g/km to the EEA’s 106.7 g/km for 2024 new registrations, because the previous values did not match the bodies they were attributed to. The tree factor moved from 57.5 to 60.3 gCO₂/day to match the EEA’s 22 kg/year figure exactly. Displayed equivalences changed accordingly; the underlying emissions estimates did not. The dashboard’s carbon unit toggle carried a separate, third set of factors (121 gCO₂/km, 21 kg/tree/year); it now reads the same published values, so every surface answers a given measurement identically.

  • 2026-07-22: Grid-intensity attribution corrected: country averages come from Ember Climate, refined by regional grid-operator data; the IEA figure is used for the global aggregate only. Worked example recomputed against the Ember 2024 EU average (270 gCO₂e/kWh, previously ~340).

  • 2026-07-06: API parameters, endpoints, and metadata field names corrected to match the backend (#279).

  • 2026-04-29: First published (#117).