Methodology_

Version: v4.12-methodology-2026-10 Last updated: 2026-10-06 Status: versioned document; every change produces a new version. English translation of the French original (docs/methodology.md), which remains the source of truth; both carry the same version number, enforced in CI.

TokenClimate produces an estimate of the environmental impact of LLM usage per team, on three quantities: energy consumed (Wh), greenhouse gas emissions (gCO₂e) and estimated water consumption (mL). These are not measurements; they are estimates derived from the volume of tokens consumed and from sourced public parameters. This document describes the scope, the assumptions, the equations, the sources, the known limits, and how to verify the values.

Normative framing and scope

The methodology is grounded in LCA principles (ISO 14040), in an attributional approach, and aligned with AFNOR Spec 2314 for the datacenter third. It is not a full third-party-verified LCA. The table below maps the framing points of AFNOR Spec 2314 §4.1 to the sections of this document. Two rows are practices of this methodology, not requirements of the standard: the min-best-max presentation of uncertainties and the versioning of the method (§4.1 asks for documented assumptions and dated sources, without imposing those forms).

Functional unit

The token. All quantities are expressed per million tokens (Mtok), broken down by token type (non-cached input, cache write, cache read, output) and by model family.

System boundaries

The covered scope is the datacenter third, inference only:

• IT electricity of the inference servers, increased by the PUE (cooling and datacenter overhead);
• embodied carbon of the inference hardware (GPU + host server), amortised;
• on-site cooling water (WUE) and water embedded in purchased electricity (EWIF, off-site).

Excluded: user devices and networks (respectively ~50% and ~4% of the digital footprint in France, datacenters being ~46%, according to the ADEME-Arcep update of January 2025 on 2022 data: the datacenter third is only part of the whole), model training and development (not allocated to inference; the split is not published by Anthropic), datacenter construction, and overprovisioning.

These exclusions do not weigh the same. Model development can be large: Epoch AI estimates Anthropic's 2025 R&D compute spending at $4.1bn against $2.7bn for inference, an estimate it itself calls "somewhat speculative", and OpenAI's 2024 figures at $5bn against $1.8bn, i.e. 1.5 to 2.8 times inference. These are dollars, for two companies and two years: they do not convert to energy without an assumption, and we apply them to no provider. A method that adds this item to the inventory gets, for the same usage, a markedly higher figure than ours. Datacenter construction is small: Google amortises it over 20 years and puts it at 59 to 218 kgCO₂e per TPU machine over six years of service (Schneider et al., arXiv:2502.01671, Table 1 and appendix A.5), on the order of 1 to 2 gCO₂e per kWh drawn by the machine, less than 1% of our total intensity. Overprovisioning, the capacity kept in reserve to absorb peaks and failures, is not in our source, which only counts the GPUs assigned to requests. Google puts it at 10% of the energy of a median prompt (see "Assumptions and uncertainties", idle capacity).

Allocation

The impact of shared infrastructure is allocated pro rata to the IT energy attributable to the session's tokens. Embodied carbon is amortised over 5 years of hardware service then allocated per IT kWh. That figure is the one Amazon adopted on 1 January 2025, shortening the accounting useful life of a subset of its servers and network equipment from 6 to 5 years, with the stated reason: "the increased pace of technology development, particularly in the area of artificial intelligence and machine learning". Two counterpoints exist, pulling in opposite directions: the AWS Customer Carbon Footprint methodology (Model v3.0, October 2025, §3.3.4.3) aligns racks on 6 years, while EcoLogits uses 3. ADEME's GPU LCA, the source of our GPU term, also uses 3 years ("nous choisissons pour cette étude une durée de 3 ans"): at 3 years the same derivation gives 82 gCO₂e/kWh instead of 49, above the published 22-66 range (see "Assumptions and uncertainties"). Claude Code subagent tokens are aggregated into the parent session (see Caveats). No offsets, no compensation: market instruments are outside the calculation, in line with the SCI.

SCI vocabulary (ISO/IEC 21031)

The calculation can be described in the vocabulary of the Software Carbon Intensity for AI: a Consumer-type score (inference usage, not training), per token (R = the token). The three components are published separately and never merged into an opaque score:

• E (energy): energy_wh, the estimated IT energy;
• I (intensity): PUE × CIF, location-based;
• M (embodied): EMB, the hardware term.

That is SCI = (E × I) + M per token. Offsets are excluded by construction.

Assumed location

We do not know in which region each request is served. The assumption remains US multi-cloud, AWS-dominant: the CIF is the weighted mix of AWS inference regions (see next section). It is now partial, and that has to be said.

On 6 May 2026, Anthropic announced a deal with SpaceX (which absorbed xAI) covering the entire capacity of Colossus 1, near Memphis, 300 MW. The May 2029 horizon is not in the announcement; it is reported by TechCrunch. The announcement explicitly mentions inference for subscribers. The grid involved is the Tennessee Valley Authority's, which is not part of the AWS-region weighting our CIF is built on. Its subregion factor (SRTV) is 0.429 kgCO₂e/kWh in eGRID2024.

Added to GCP and Azure, where Anthropic also operates with no published split, this leaves the sensitivity of the CIF to that unknown at ±30%, an estimate we currently have no means of tightening. Work is open to rebuild the weighted mix ourselves from Electricity Maps.

eGRID2024 reference points for the subregions of the AWS inference regions, as combustion emissions, without upstream or grid losses (EPA code re-run published by the Cornerstone Sustainability Data Initiative, Zenodo, March 2026, sheet SRL24): Virginia (SRVC, us-east-1) 0.291, Ohio (RFCW, us-east-2) 0.406, Northwest (NWPP, us-west-2) 0.264, US average 0.341, Tennessee Valley (SRTV) 0.429 kgCO₂e/kWh. Our 0.287 sits at the level of Virginia and the Northwest; more weight on Ohio or on Memphis would raise it. The top of our range (0.287 × 1.3 = 0.373) covers neither the TVA subregion nor a site powered by on-site gas. The revision of the range will have to include them.

On water

We speak of estimated water consumption, never of a "water footprint". A water footprint in the ISO 14046 sense would require impact characterisation (for example AWARE, weighting by local water stress), which this methodology does not do since the location of requests is unknown.

The water figure adds two quantities that are not of the same nature, and we declare it rather than hide it. The equation is water_ml = energy × (WUE + PUE × EWIF). AWS defines its WUE as water withdrawn ("liters of water withdrawn per kilowatt-hour"), whereas WRI-family EWIF factors measure consumption. Adding a withdrawal to a consumption is not homogeneous.

We do not correct it right away: the consumption-to-withdrawal ratio depends on a site's cycles of concentration, which we do not know. What bounds the problem: the on-site term is 2.0% of the millilitres displayed (0.12 out of 5.9454), so the inhomogeneity affects 2% of the figure, not the figure. The remaining 98% is the water consumed to generate electricity, and there the figure is homogeneous: Jegham declares its 5.11 L/kWh as a consumption (the withdrawn share that is then evaporated), derived from the WRI guidance on water embedded in purchased electricity and weighted over the AWS inference regions, a weighting the paper does not publish. That 5.11 looks high next to the 1.8 L/kWh that Grubert and Sanders give for the average US power plant, but the two do not count the same thing: WRI factors include evaporation from hydropower reservoirs (national average 3.1 L/kWh consumed for 43.8 withdrawn, per Li et al., arXiv:2304.03271), while the 1.8 explicitly excludes it. A fleet partly hosted in Oregon, where hydropower dominates, pulls the average up. The gap is an allocation convention, not an error to fix: we keep 5.11 and say so. Checked against the WRI guidance appendices (GaBi modelling, eGRID 2018 mix, gallons converted at 3.785 L): Virginia (SRVC subregion) is at 2.37 L/kWh consumed, Ohio (RFCW) at 2.22, California (CAMX) at 5.19 and the Northwest (NWPP, Oregon) at 9.48; the US average is 3.13 and the global average 4.81. Jegham's 5.11 is reproduced with about 40% Northwest and 60% Virginia, i.e. a fleet split between us-west-2 and us-east-1: plausible, but the exact weighting remains Jegham's, not ours.

Equations

For a session, with energies E_in and E_out in Wh per million tokens (IT energy, server side):

energy_wh = (
    (input_tokens + cache_creation_tokens) * E_in
  + cache_read_tokens * E_in * 0.08
  + output_tokens * E_out
) / 1_000_000

co2_grams = energy_wh * (PUE * CIF + EMB)
water_ml  = energy_wh * (WUE + PUE * EWIF)

With the Anthropic parameters of the next section, the composite constants are:

Embodied carbon represents 13.0% of total CO₂e (0.049 / 0.37618). Total CO₂e is therefore usage CO₂e × 1.1498.

The equation is implemented in lib/co2.ts, function computeImpact, which returns { energyWh, co2Grams, waterMl }. The three values are stored per usage row (energy_wh, co2_grams, water_ml). The USD cost is computed separately (see "USD cost").

Example

A Sonnet session with 50,000 input tokens, 200,000 cache write, 3,000,000 cache read and 30,000 output:

energy_wh = (250_000 * 119 + 3_000_000 * 119 * 0.08 + 30_000 * 2525) / 1e6
          = 134.06 Wh
co2_grams = 134.06 * 0.37618 = 50.43 g   (usage 43.86 g + embodied 6.57 g)
water_ml  = 134.06 * 5.9454  = 797.0 mL

Anthropic parameters

params block of lib/providers/seed/anthropic.json. Since v3.8 this block is composite: PUE and WUE come from a first-party AWS disclosure (2025 vintage), while CIF and EWIF stay pinned to Jegham N. et al. (Jegham N., Abdelatti M., Koh C. Y., Elmoubarki L., Hendawi A.), "How Hungry is AI? Benchmarking Energy, Water, and Carbon Footprint of LLM Inference", arXiv:2505.09598, version v6, Table 1. Embodied carbon is not in that Table 1 (the paper excludes scope 3): it is a TokenClimate constant, derived below, the same for every provider.

Source tiers: T1 = published primary measurement or report, T2 = documented derivation from T1 sources, T3 = engineering estimate.

Tier reclassification in v3.8

Three rows change tier, and no value moves with them.

CIF and EWIF move from T1 to T2. T1 is defined here as "published primary measurement or report". Jegham et al. is a non-peer-reviewed preprint that republishes third-party parameters (Electricity Maps for the CIF) and models the rest: that is a documented derivation, hence T2. PUE and WUE stay T1 because they are now sourced from a disclosure published by the infrastructure operator itself, no longer from the preprint.

cache_read_factor moves from T3 to T2: since May 2026 a direct measurement of the hit/miss ratio exists (see "Cache energy"), which takes it out of engineering-estimate status without making it a measurement of our exact quantity.

The E_in / E_out ratio moves from T2 to T3, and its range widens in the opposite direction from the convention (see "The input/output ratio").

Version pin on the primary source

The CIF changed during the life of the source paper: 0.385 kgCO₂e/kWh up to v4, 0.287 since v5 (sourced from Electricity Maps). The value used here is pinned on v6, Table 1. Note: 0.287 is not "the global electricity mix"; it is a mix computed over the AWS inference regions ("based on the regional distribution of AWS data centers used for inference", §4.1), with unpublished weights.

Energy per model family

Source: lib/providers/seed/anthropic.json, energy block per model. Values in Wh per million tokens, IT energy.

Only one of the four Claude families is estimated directly by the source. Confidence levels track the derivation, not the provider: Sonnet carries the published estimate, Opus and Haiku are single-hop extrapolations from it, Fable is a two-hop extrapolation with no public data on the model at all. These levels appear on every /models sheet and in the hub table, and the v1 API returns them in the co2_confidence field.

No factor in the registry is a measurement, and high does not mean "measured". The primary source records nothing: its section 4.2 is titled "Per-Query Energy Consumption Estimation" and its values come out of a Monte Carlo simulation (10,000 draws, Gaussian copula) over nameplate GPU power, an assumed utilisation rate and a batch size fixed at 8, with Artificial Analysis latency and throughput as the only empirical inputs. This holds for every row of Table 4, Sonnet included. The confidence scale therefore ranks estimates against each other: high = an estimate published for this exact model and fitted on its own points, medium = derived from a fitted model or a partial fit completed by a convention, low = extrapolated from another model or produced by a parametric tool. Until v4.0 the product wrote "direct measurement" in several places, which over-qualified the source.

2026-07 recalibration: the three per-request energies estimated by Jegham v6 for Claude 3.7 Sonnet (0.950 / 2.989 / 5.671 Wh, PUE included) are fitted by OLS regression through the origin, which yields the 39/826 gCO₂e/Mtok usage factors of the OSS plugin; the IT energies above are de-compounded from them (E = factor / (PUE × CIF), rounded to the integer). Haiku is 61 on input rather than 59.5 (0.5 × 119) because the de-compounding starts from the already-rounded OSS factor (20 gCO₂e/Mtok, i.e. 20 / 0.32718 = 61.1), not from the Sonnet energy: a 2.5% rounding gap, kept to stay aligned with the plugin. The previous calibration (tokenclimate-v3-2026-06, Sonnet 580/3480) relied on the pre-v6 composites (190/1140). These energies stay aligned with those of the open source plugin claude-carbon (same author); an automated weekly check verifies consistency to ±0.5%.

The Haiku / Sonnet ratio

The 0.5 has no primary source. It matches the ratio of public prices ($1 / $5 against $2 / $10 per million tokens), which says nothing about energy. Table 4 of Jegham v6 cannot settle it: it estimates Claude 3.5 Haiku above Claude 3.7 Sonnet (0.975 / 4.464 / 8.010 Wh against 0.950 / 2.989 / 5.671), a result produced by its hardware and latency assumptions; model size is published nowhere. The only analogue readable in the same table is at OpenAI: GPT-4.1 mini draws 0.44 to 0.52 times GPT-4.1, GPT-4.1 nano 0.17 to 0.24 times. Nothing published says which of the two Haiku resembles. Sensitivity range: 0.2 to 0.6 times Sonnet. The value stays at 0.5 and the confidence at medium, which denotes a one-hop extrapolation from Sonnet.

Validity date of the energies

These energies are valid as of 2026-07 and go stale mechanically, in the direction of overestimation. On identical hardware, on H100, per-token energy fell by 15 to 41% depending on model size between vLLM 0.5.4 (September 2024) and vLLM 0.11.1 (December 2025), with no model changing: that is the serving stack alone (ML.ENERGY, longitudinal analysis). Our values are a fit on November 2025 estimates. They are renewed at least once a year, and sooner if a pinned source moves.

Tokenizer caveat. Anthropic states that Claude 4.7 and later models, and Claude Mythos, use a newer tokenizer that produces approximately 30% more tokens for the same text (platform.claude.com/docs/en/about-claude/pricing, tokenizer note). The per-token energies above are fitted on Claude 3.7 Sonnet. For the same text, a per-token factor calibrated before 4.7 may therefore overestimate by about 30% on Sonnet 5, Opus 5 and Fable. No correction factor is applied until a measurement supports one; the caveat is published.

Sensitivity note: the overestimation charge

Four signals suggest these energies may be too high. We publish them rather than arbitrate in silence.

Microsoft (arXiv:2509.20241, v2; v1 said 0.34) estimates a median of 0.31 Wh per request for models above 200 billion parameters on H100 nodes, and writes verbatim that "widely cited estimates are overstated by 4-20x". The family of estimates targeted is the one Jegham belongs to, that is, our primary source. Our Sonnet at 2,525 Wh/Mtok gives roughly 1.26 Wh for a 500-token response, about 4 times their median: we would therefore sit at the low end of the alleged overestimation range. Two further signals point the same way. EcoLogits corrected its online calculator in March 2026, whose latency estimate was overstating energy. And the ML.ENERGY leaderboard v3.0 measures Qwen3-235B-A22B in FP8 on 4×B200, at maximum batch, around 111 Wh/Mtok: an open-weight model under optimal throughput conditions, not a proprietary frontier model, but an order of magnitude twenty times below our Sonnet.

The fourth comes from the source itself. Jegham v6 sets the batch at 8 concurrent requests for all its estimates, justifying the choice by latency ("a practical midpoint between common deployment scenarios", §4.3), and its own sensitivity analysis (appendix A, GPT-4o) shows that a batch of 16 lowers energy per request by about 43%. The same paper places flagship models with undisclosed size, Claude 3.7 Sonnet included, in its heaviest class (8 GPUs, "classified as Large"), and counts the node's non-GPU subsystem at a fixed utilisation of 0.5: the host is therefore already in our energies. Microsoft's throughput, for its part, "approximates the throughput of a fully saturated node with high concurrency". No public source says what batch Anthropic runs in production. If it is higher than 8, our energies are high by a factor we cannot quantify.

We are not switching the value. The Microsoft paper is a bottom-up model under deployment assumptions, produced by an interested party, not a measurement of our models. But the conflict exists, it is documented, and a reader who brings it to a meeting should find it here before finding it elsewhere.

The input/output ratio

Since the v6 recalibration, the ratio is no longer an assumption: it is recovered from the fit on the three estimated points, about 21:1 output:input (2525 vs 119 Wh/Mtok for Sonnet). A long context adds little energy compared with the same volume of generated tokens, which a flat low ratio would miss. For non-Anthropic providers whose input energy is not estimated (EcoLogits energies, which only publishes output, or Jegham fits whose input coefficient is forced to 0 by NNLS), the convention E_in = E_out/6 still applies.

That convention is now presented for what it is: a contested assumption, not a consensus value. The defensible range in the literature is far wider than what v3.7 published. It runs from 1/21, our own fit on Jegham v6, to 1.2, that is, an input more costly than an output, a value given by Vartziotis et al. (arXiv:2607.26571, equation 29). Their estimator is analytical, explicitly "compute-dominated" and set in a short-prompt regime: it misses the memory-bandwidth wall that dominates decode, so it is not transposable to our case. But it is published, it points the opposite way from our convention, and staying silent about it would mean publishing a range that does not exist.

The Fable case

No public source documents the size or energy of Fable 5 and 5.1 / Mythos 5 and 5.1. The anchor used is the price proxy: 2x Opus, the ratio of public prices (10/50 vs 5/25). To be revised as soon as an independent estimate is published.

Cache energy (cache_read_factor = 0.08)

A cache_read token is an already-processed context token whose key/value tensors are reused: its prefill compute is avoided. It is not free either.

What the term captures, and what it does not

The equation applies cache_read × E_in × 0.08, that is, a fraction of the energy of an uncached input token. It is therefore a prefill residual: what is still paid at prefill when the prefix is already cached.

Up to v3.7, that same term was justified by the KV re-read residual during decode. These are not the same object, and the second is not linear in cache_read: every generated token re-reads the entire KV cache from HBM, cached tokens included (GreenCache, SIGMETRICS: "caching does not reduce computation in the decode phase"). That cost is bilinear, depending on the product (context size × number of generated tokens). Today it is absorbed into an E_out assumed constant, calibrated at context lengths the source does not publish and which are probably short. The consequence, stated plainly: in a long-context regime, hence in agentic use, our figure underestimates this term.

What the literature measures

A direct measurement of the hit/miss ratio has existed since May 2026. Irminsul (arXiv:2605.05696, Table 1) instruments prefill energy per cache event, NVML hardware counters, at 4,096 prefix tokens (2,048 for DeepSeek-MoE-16B):

Three reservations before drawing a value from this. The measurement is taken at 4,096 tokens of prefix (2,048 on the MHA row), whereas the median Claude Code session step carries 126,180 tokens (TraceLab, arXiv:2606.30560v2, Table 8): at that scale fixed kernel-launch costs amortise and the real ratio falls, which the paper itself acknowledges for its small cells. The two high rows, MLA and MHA, are measured on 16-billion-parameter models, exactly where those fixed costs weigh most. Finally, Claude's attention architecture is not published: nothing says which of the three rows applies.

The value we keep

0.08, unchanged, published range 0.05-0.20. The tier moves from T3 (engineering estimate) to T2: a direct measurement now exists, on an adjacent object and in a different regime from ours, which is a documented derivation rather than a measurement of our quantity.

We did not switch to 0.14 despite Irminsul. Applying a measurement taken at 4K of context to usage that runs at 126K would move the figure of a Claude Code-dominated organisation by 25 to 30%, on a basis we could not defend. The published upper bound does move from 0.15 to 0.20, because two of the three measured architectures sit above the old ceiling: our stated uncertainty was understating the upside risk.

The adjacent measurements behind the original estimate still hold as a bracket: prefill represents at most 3.4% of total inference energy on generation workloads, and a larger KV cache amplifies per-token decode energy by 1.3 to 51.8% (both from Solovyeva & Castor); per-token energy roughly triples between 2K and 10K of context on Llama 3 70B (TokenPowerBench, H100).

The real fix is not a new constant, it is a new equation shape, with a residual prefill term and a decode term as a function of context length. Until we measure that curve ourselves, the constant stays.

This factor is not Anthropic's 0.1x billing ratio. That is a price, not an energy measurement (OpenAI bills the same mechanism at 0.1x on its current range, 0.5x on gpt-4o). Setting cache_read_factor to 0 would be a defensible lower bound, but it would treat a reused 100K-token system prompt as carbon-neutral, ignoring a real memory-bandwidth cost.

Sources: Irminsul (arXiv:2605.05696), GreenCache (arXiv:2505.23970), TokenPowerBench (arXiv:2512.03024), Solovyeva & Castor (arXiv:2602.05712), From Prompts to Power (arXiv:2511.05597), TraceLab (arXiv:2606.30560v2).

The factor lives in lib/providers/seed/anthropic.json (key cacheReadFactor) and is exposed by lib/providers/registry.ts.

Usage profiles of the public calculator

The public calculator (/calculator, /en/calculator) asks for a volume of generated tokens per month. Historically it only counted that volume. Yet generated tokens are only part of what the machine processes: in agentic use, context re-read from cache dominates the volume by far (see the example in the Equations section: 3,000,000 cache reads for 30,000 generated tokens, about 91% of the tokens processed).

A usage profile makes this assumption explicit instead of leaving it implicit. Each profile is a set of reference volumes per token class, stored verbatim from its source in lib/calculator/profiles.ts. Selecting a profile scales these volumes to the entered generated-token volume (rule: factor = entered volume / reference output volume). The default "Output only" profile reproduces the historical behaviour: links already in circulation produce the same figures as before.

The coding-agent profile is given in raw aggregates so it stays literally the source. Scaled to one million generated tokens, that is 4.8 M fresh input tokens, 19.3 M cache write and 269.7 M cache read, i.e. 270 tokens re-read from cache per generated token and 91.5% of total volume actually read from cache.

What changes against v3.7: the profile was 100 re-read tokens per generated token, taken from the worked example of the Equations section and corroborated after the fact. It is now 270, copied from measured aggregates. The figure the calculator shows for this profile is multiplied by roughly 1.78 (4,468.7 to 7,961.1 Wh per million generated tokens on Sonnet). The calculator was understating what an organisation measures on its own data.

Splitting the fresh volume between uncached input and cache write (1:4) is the only derivation left: TraceLab does not separate the two. It has no effect on energy, both classes costing full E_in, and only moves the dollar cost.

An intermediate profile (assistant with cached context) was considered then dropped: no published source breaks that workload down by token class, and the calculator does not display an assumption it cannot source. The manual entry mode covers that case; published cache shares for conversational services range from 30 to 50% depending on capacity (Mooncake trace, arXiv:2407.00079) to 75-95% in production (CharacterAI and Kimi, as cited by TokenLake, arXiv:2508.17219).

Profile sources:

• Splitwise: Patel P. et al., "Splitwise: Efficient Generative LLM Inference Using Phase Splitting", ISCA 2024, arXiv:2311.18677. Azure production traces (November 2023): conversation service, median 1,020 prompt tokens and 129 generated tokens per request. Corroboration on response lengths: WildChat (arXiv:2405.01470, 441 tokens per response on average) and LMSYS-Chat-1M (arXiv:2309.11998, 215).
• TraceLab: Zhu J. et al., "TraceLab: Characterizing Coding Agent Workloads for LLM Serving", arXiv:2606.30560. Trace of 2,676 real Claude Code sessions (37 developers, Claude Code column of Table 1; the paper's 43 is the deduplicated Claude plus Codex total; October 2025 to June 2026): 95.5% of total volume in prefix tokens, of which 91.5% actually re-read from cache, 0.34% in output, prefix cache hit rate 95.8% on the Claude column of Table 11 (95.7% across all columns).
• Bai et al.: "How Do AI Agents Spend Your Money?", arXiv:2604.22750. OpenHands on SWE-bench Verified: average input/output ratio of 153.85 in agentic coding, ~4.17M tokens per task. The agent profile sits at 294, all input tokens (fresh, cache write and cache read) over output tokens: higher, because TraceLab counts the prefix re-read at every step.

Estimation per usage unit (simplified mode)

The calculator asks for a volume of generated tokens per month, and nobody knows that number by heart, nor opens their billing console mid-visit. The simplified mode derives it from three questions: what the visitor hands over to the tool, how many people use it, and how often.

This mode publishes no cadence. That is the difference with the per-task volume table removed in v3.7, judged too imprecise for a public surface. Here the cadence is entered by the visitor and stays editable in the volume field; only the tokens per unit are derived from the source.

The 36,211 tokens per session are derived, never copied: 96,900,000 / 2,676. On the chat side the source unit IS the request, so the 150 reference output tokens are already "per exchange" and there is nothing to divide. Cadence measured by TraceLab, published here as a reference point: 2,676 / 37 / 9 months, that is 1.9 session per developer per week (8.0 per month, at 4.33 weeks per month). The screen no longer shows it since 2026-09-02: the value is entered by the visitor, this document publishes the source's. Splitwise measures no population, so no cadence reference point exists for chat.

output/month = people × cadence × periods per month × tokens per unit, with 4.33 weeks or 21 working days per month depending on the profile.

The measured cadence is not a ceiling, it is a reference point so the visitor can place themselves. TraceLab's 37 developers run at 8.0 sessions per month, which is occasional usage; a team coding with Claude every day sits several times above that.

The result is rounded to two significant digits and presented as T3: the dominant uncertainty comes from the declared cadence, not from the aggregates. Two reservations add to it. The duration of a TraceLab session is not published, and the session a visitor counts is not necessarily the same object. On the chat side, the response length retained (129 tokens, Splitwise 2023 median, rounded to 150) is the lowest of the three cited above: at 215 (LMSYS-Chat-1M) or 441 (WildChat), the same number of exchanges would give a volume up to three times larger.

Delegation levels

A single per-session constant does not describe reality. On a corpus of 184 Claude Code sessions from a single developer (August 2026, measured by claude-carbon), output per session spans a factor of 100 between the first and ninth decile, and 10% of sessions carry 66% of total output. There is no such thing as an average session: what varies is the size of what you hand over. This corpus is not reproducible by a third party: it lives in the author's local carbon.db database, and no script or anonymised export is published as of this version. The percentiles below are therefore a private observation, not a verifiable dataset.

The simplified mode therefore asks what the visitor hands over to AI, and derives the size of a session from it.

This corpus has one developer, against 37 for TraceLab. That is little, and nothing says the distribution holds for another organisation. What justifies publishing it anyway: the corpus median, 36,750, lands within 1.5% of the mean TraceLab measures across 2,676 sessions, 36,211 (96.9 M / 2,676; TraceLab publishes no per-session median). An independent median and an independent mean meet at the centre of the distribution, which lends credit to the spread only the first one documents. Tier T3.

The delegation level only changes the size of a session. It does not touch the profile's context-to-output ratio: on the same corpus that ratio does not track size cleanly (170, 90, 168 then 234 times output, by increasing size quartile).

The conversational level does not come from this corpus: its unit remains the Splitwise median request, 150 output tokens.

Limits

These profiles are orders of magnitude, not measurements. The real ratio between token classes varies strongly from one organisation to another depending on tooling, context sizes and the share of agentic usage. Only a measurement on the organisation's real data gives it.

Dual reporting: location-based and market-based

The CO₂e displayed by default is location-based: the carbon intensity of the real electricity grid of the regions where inference runs. This is the convention adopted by AFNOR Spec 2314 (in a note to §4.3) and the requirement of the SCI, which exclude market instruments (PPAs, RECs, offsets) from the score.

Market-based figures are published for comparison, never as the default:

• Google 2024: 94 gCO₂e/kWh market-based vs 345 location-based (arXiv:2508.15734). The 3.7x gap shows what market instruments mask.
• AWS (TokenClimate's dominant location assumption): claims 100% renewable matching, but Amazon as a whole declares 2.80 MtCO₂e of residual market-based scope 2 in 2024 (a group figure, AWS is not isolated) and AWS publishes no market-based kg/kWh factor. The AWS market-based value is therefore "not published by AWS". We will never write "market-based = 0".

Third-party providers (EcoLogits + Jegham v6)

TokenClimate is built multi-provider (OpenAI, Google, Mistral, DeepSeek, Meta), even though the product sold is Claude-first. Output energies come from three tracks: the EcoLogits parametric model (genai-impact/ecologits repo, release 0.10.2 of 2026-06-04 pinned for Google and Mistral, 0.11.1 for the current OpenAI range), the per-query estimates of Jegham et al. v6, Table 4 (the same primary source as the Anthropic parameters), or the price-proxy rule of the "Models outside the catalogue" section applied by hand. The E_in = E_out/6 ratio and the 0.08 cache_read_factor applied to these providers are TokenClimate extensions, whatever the source of the output energy. A legacy model is retired or being retired by its provider (shutdown date shown on the sheet when it exists): its energies and last public prices are kept to quantify past usage, and it leaves the /models table, the rankings and the comparisons. State per provider as of 2026-09-07.

Google. Infra: PUE 1.09, on-site WUE 1.15 L/kWh and location-based CIF 0.345 kgCO₂e/kWh, Google 2024 disclosures as reported by Elsworth et al. 2025 (arXiv:2508.15734); off-site EWIF 3.13 L/kWh, US average of Appendix 2 of the WRI 2020 guidance, consistent with a mostly US inference fleet. Energies: gemini-2.5-pro and gemini-2.5-flash enter the catalogue on 2026-09-07, proposed by pnpm catalog:propose from EcoLogits 0.10.2 (output energy at the midpoint of the active-parameter range, the convention of the Google and Mistral seeds). 2.5 Pro = mixture of experts with 2,000 billion parameters, 200 to 600 active, 89.6 tokens/s, range 10,347 to 24,924, midpoint 17,636 Wh/Mtok. 2.5 Flash = 440 billion, 44 to 132 active, 64.6 tokens/s, range 1,211 to 2,012, midpoint 1,611 Wh/Mtok. EcoLogits gives 2.5 Flash the same architecture assumptions as 2.0 Flash, so the two sheets carry the same energy: a limit of the source, published as is. E_in = E_out/6, low confidence (architecture not published). Prices read on 2026-09-07 from ai.google.dev/gemini-api/docs/pricing: 2.5 Pro $1.25 / $10 for prompts up to 200k tokens ($2.50 / $15 above, not modelled), cache read 0.125; 2.5 Flash $0.30 / $2.50, cache read 0.03; Google bills cache storage per hour, not cache writes per token. gemini-2.0-flash (shut down 2026-06-01, deprecations page), gemini-1.5-pro and gemini-1.5-flash (absent from the deprecations and pricing pages, already retired, date not shown) are legacy. The gemini-1.5-* family is absent from EcoLogits 0.10.2 and keeps its tokenclimate-manual values at low confidence.

Mistral. Infra: PUE 1.16, the EcoLogits constant for Mistral (EcoLogits localises Mistral in Sweden), not a Mistral disclosure; France CIF 0.056 kgCO₂e/kWh (Ember 2024); on-site WUE 0.18 L/kWh, the AWS 2023 value reused for want of a Mistral disclosure; off-site EWIF 3.67 L/kWh since the water revision of 2026-09-07, the France factor of Appendix 2 of the WRI 2020 guidance (consumption, nuclear and hydropower included), instead of the US average of 3.13 the seed carried by default. Prices read on 2026-09-07 from mistral.ai/pricing/api: mistral-large-latest (Mistral Large 3) $0.5 / $1.5, mistral-medium-latest (Mistral Medium 3.5) 1.5 / 7.5, mistral-small-latest (Mistral Small 4) 0.15 / 0.6; the page shows no per-model cache rate. Energies. mistral-large-latest has served Mistral Large 3 (mistral-large-2512) since December 2025, whose architecture Mistral publishes (huggingface.co/mistralai/Mistral-Large-3-675B-Instruct-2512: 675 billion parameters, 41 active, mixture of experts). EcoLogits 0.10.2 has not updated its entry and keeps the dense 123B of Large 2 for mistral-large-2512: TokenClimate replays the EcoLogits parametric model (whPerMtokOut in scripts/crosscheck-ecologits.mjs) on the published architecture, with the EcoLogits throughput for mistral-large-2512 (41.5 tokens/s): 2,546 Wh/Mtok on output, 424 on input, medium confidence, factorVersion ecologits-0.10.2-replay-2026-09. Five times Large 2 for a model four times cheaper: the EcoLogits model sizes the GPU fleet on the total parameters resident in memory, the price reflects Mistral's margin choices, and this methodology publishes the physics-side estimate. mistral-medium-latest (Medium 3.5, dense 128B published on Hugging Face, EcoLogits entry mistral-medium-3-5, 48.1 tokens/s) enters the catalogue through pnpm catalog:propose: 508 Wh/Mtok on output, 85 on input, medium confidence (architecture published, EcoLogits' only warning: multimodal). mistral-small-latest keeps 35 / 207: the EcoLogits 0.10.2 entry is already Small 4 (mixture of experts, 119 billion of which 8 active, 98.8 tokens/s), replay verified at 206.7. The Mistral Large 2 sheet becomes mistral-large-2411 (legacy, Large 2.1 retired on 2026-05-31 per docs.mistral.ai/models/overview), EcoLogits Large 2 dense 123B energy (86 / 515) and last prices 2 / 6 kept.

Mistral's LCA: first-party, but not decomposable. In July 2025 Mistral published, with Carbone 4 and the support of ADEME (AFNOR "frugal AI" method, ISO 14040/44, GHG Protocol Product Standard), a life-cycle assessment of Mistral Large 2: 20.4 ktCO₂e and 281,000 m³ of water consumed after 18 months of operation, training included, and for a 400-token response on Le Chat, 1.14 gCO₂e and 45 mL of water. It is the only first-party publication on a Mistral model. It provides none of the terms of this methodology: no Wh per request, no PUE, no WUE, no litres per kWh, no data-center location. It therefore cannot feed the seed, and Mistral's energy stays sourced from EcoLogits or replayed on its model. What it does allow us to check is the ratio between water and carbon: 45 mL for 1.14 g, i.e. 39 mL per gram. This methodology's France parameters (EWIF 3.67 L/kWh, CIF 0.056 kgCO₂e/kWh, embodied 49 gCO₂e/kWh) give 39 mL per gram. The gap is 1%, which supports the country factor adopted at that revision. The level, however, does not match. The LCA covers Mistral Large 2, that is, the mistral-large-2411 sheet (86 / 515 Wh/Mtok): for 400 input and 400 output tokens, this methodology gives 0.027 gCO₂e and 1.1 mL of water, forty-two times less than the LCA. On mistral-large-latest (Large 3, 424 / 2,546 Wh/Mtok), the same response is worth 1.19 Wh, i.e. 0.14 gCO₂e, and the gap falls to about 8×. Brought back to our factors, Mistral's figure is worth about 10 Wh per response, i.e. 25,000 Wh per million tokens against 515 for Large 2 in EcoLogits. A gap of that size does not come from the electricity mix. The most likely explanation is a different perimeter: a full LCA counts in principle server manufacturing and the water embedded in electricity generation, and this one, in all likelihood, amortises training over each response, where this methodology excludes training and amortises hardware only. Mistral does not publish the share of training in its per-response figure, and the results announced for ADEME's Base Empreinte database are not readable there in a decomposed form as of this version. Until that decomposition exists, the gap is published here rather than smoothed over, and the Mistral sheets point to it.

OpenAI. Infra: PUE 1.12, CIF 0.35 kgCO₂e/kWh, WUE on-site 0.30 L/kWh, EWIF off-site 4.35 L/kWh (Jegham v6 Table 1, OpenAI/Azure row, verbatim; the embodied 49 is not part of it, it is the TokenClimate constant). This corrects an erroneous citation of that same Table 1 in the previous seed (PUE 1.20, CIF 0.3844, EWIF 3.13: only the on-site WUE was right). Energies: gpt-4o, gpt-4o-mini, gpt-4.1, gpt-4.1-mini and o3-mini remain sourced from EcoLogits 0.10.2 (low confidence, unpublished architectures); o3, o4-mini, gpt-4.1-nano, gpt-4-turbo and o1 take the per-query estimates of Table 4 (3-point OLS fit, same method as the Anthropic seed; the row used for o4-mini is "o4-mini (high)", applied whatever the reasoning effort requested). o3 and gpt-4-turbo have a clean two-coefficient fit (high confidence); o4-mini, gpt-4.1-nano and o1 yield a negative input coefficient under constraint, forced to 0 by NNLS, hence E_in = E_out/6 and medium confidence. 2026-07-19 extension: the current OpenAI range enters the catalogue. gpt-5.5 and the gpt-5.4 family (mini, nano) are sourced from EcoLogits 0.11.1 (tag 0.11.1): output energy at the middle of the estimated active-parameter range, latency 1/tps, batch 64, replay validated by reproducing gpt-4o (1676), gpt-4.1 (1536) and gpt-4o-mini (71 Wh/Mtok) from the 0.10.2 data; E_in = E_out/6, low confidence. The gpt-5.6 family (sol, terra, luna; GA 2026-07-09) is not yet covered by EcoLogits 0.11.1: sol takes the energy of gpt-5.5 and terra that of gpt-5.4, the models they replace at the same price (OpenAI pricing page, retrieved 2026-07-19); since 2026-09-23 luna takes the energy of gpt-5.4-nano, at the same price (see the v4.6 correction). low confidence for all three, to be replaced as soon as EcoLogits covers them. 2026-09-07 extension: gpt-6-astra (announced on 2026-09-03 as a limited preview, API opened in the following days; $10 in and $50 out per Mtok) enters the catalogue, still outside EcoLogits: its energies are those of gpt-5.5, the catalogued model nearest in output price, multiplied by 1.83, the geometric mean of the price ratios (10/5 and 50/30), i.e. the price-proxy rule applied by hand so the model gets a sheet; low confidence. The gpt-5.6 prices are re-read on the same date from the OpenAI pricing page: Sol $4 / $20 (promotional pricing through 21 November 2026), Terra $2 / $12, Luna $0.2 / $1.2, cache writes billed at 1.25× input; the energies of those three models do not move. 2026-09-07 correction on legacy models: with the deprecations and pricing pages re-read, gpt-4o, gpt-4o-mini, gpt-4.1 and gpt-4.1-mini do not appear on the deprecations page (only the old gpt-4o-2024-05-13 snapshot does) and remain on the standard pricing page at their seed prices: they are current again, the 2026-07-19 move to legacy on their absence from the models page was a mistake. Still legacy, with their shutdown date: o1, o3-mini, o4-mini, gpt-4-turbo and gpt-4.1-nano (2026-10-23), o3 (2026-12-11). Cache-read rates added to the seed from the pricing page: gpt-4o-mini 0.075, gpt-4.1 0.5, gpt-4.1-mini 0.1, o3-mini 0.55. Extension 2026-09-23: gpt-6-sol ($2 in, $10 out per Mtok, cache read 0.20, cache write 2.50) and gpt-6-luna ($0.10 / $0.50, cache read 0.01, cache write 0.125), released on 2026-09-22, enter the catalogue. Neither EcoLogits 0.11.1 nor the EcoLogits main branch covers them: same price-proxy rule applied by hand as for Astra, anchor searched among non-legacy models. Sol anchors on gpt-4o ($2.5 / $10, same output price): ratio √(0.8 × 1) = 0.89, i.e. 250 / 1,499 Wh/Mtok. Luna anchors on gpt-4o-mini ($0.15 / $0.6): ratio √(0.667 × 0.833) = 0.75, i.e. 9 / 53 Wh/Mtok. low confidence for both. Astra prices re-read the same day, unchanged. Extension 2026-09-29: gpt-6.1-sol (2 $ / 10 $, cache read 0.1, cache write 2.5), released on 2026-09-29, enters the catalogue outside EcoLogits: same hand-applied price-proxy rule, anchor gpt-6-sol (the non-legacy model nearest in output price), ratio 1.000, i.e. 250 / 1499 Wh/Mtok; confidence low.

DeepSeek. Infra: PUE 1.27, CIF 0.6 kgCO₂e/kWh, WUE on-site 1.20 L/kWh, EWIF off-site 6.016 L/kWh (Table 1, DeepSeek/China row, verbatim), which since 2026-07 replace the old generic "China colo / IEA" figures (PUE 1.30, CIF 0.555, WUE 0.18, EWIF 3.13), whose on-site WUE was underestimated by about 7x. Energies: deepseek-chat and deepseek-reasoner take the Table 4 per-query estimates on the DS rows (China-hosted, the API actually billed by these models), from which we derive 6940 and 17442 Wh/Mtok on output. medium confidence since v4.0: the NNLS fit forces the input coefficient to 0 for both models, and input energy is then set by convention at E_out/6. That is exactly the case which earns the OpenAI models above a medium; v3.2 left these two at high by oversight. Two caveats published rather than settled in silence. DeepSeek is the weakest row of Jegham's panel: hardware inferred from export restrictions, PUE and WUE taken as the average of the thirty most efficient data centers in China, and R1 carries the table's widest dispersion (±9.449 on 19.251, i.e. 49%). And the deepseek-reasoner fit is mis-specified: a reasoning model carries a fixed per-request cost (~16.7 Wh here) on top of a ~8154 Wh/Mtok slope, and a line forced through the origin absorbs that constant into the slope, inflating it by about 2.7x (centred R² -2.76, i.e. worse than the mean of its own three source points). We keep 17442: a Wh/Mtok factor structurally cannot carry a per-request constant, so fixing it needs a different equation shape, not a different constant. 2026-09-07 extension: deepseek-chat and deepseek-reasoner were retired by DeepSeek on 2026-07-24 (api-docs.deepseek.com/news/news260424) and become legacy, energies and last prices kept. deepseek-v4-flash and deepseek-v4-pro (V4 preview of 2026-04-24, served versions V4-Flash-0731 and V4-Pro-0813) enter the catalogue. They are not covered by EcoLogits 0.10.2: the price-proxy rule is applied by hand, anchor = the seeded DeepSeek model nearest in output price, ratio = geometric mean of the input and output price ratios, clamped [0.1; 4]. Anchor prices are the seed prices (DeepSeek list of the V3-0324 / R1-0528 era, the same era as the Table 4 estimates they carry). deepseek-v4-flash ($0.44 / $1.32) anchors on deepseek-chat (0.27 / 1.1): ratio √(1.630 × 1.2) = 1.398, i.e. 1,618 / 9,705 Wh/Mtok. deepseek-v4-pro ($1.32 / $3.96) anchors on deepseek-reasoner (0.55 / 2.19): ratio √(2.4 × 1.808) = 2.083, i.e. 6,056 / 36,335 Wh/Mtok. low confidence for both. Two published caveats: v4-pro inherits the mis-specified R1 fit (slope inflated by about 2.7×), which makes it the most fragile output energy of the catalogue; and DeepSeek publishes the V4 architectures (Pro 1,600 billion parameters of which 49 active, Flash 284 of which 13), so an EcoLogits-style parametric replay would be a better derivation once a tokens/s throughput is available. Prices read on 2026-09-07 from api-docs.deepseek.com/quick_start/pricing, peak rate (off-peak hours at half price, not modelled): v4-flash $0.44 input cache miss / 0.014 cache read / 1.32 output; v4-pro 1.32 / 0.044 / 3.96.

Meta. llama-3.1-8b-instant and llama-3.3-70b-versatile, Table 4 estimates with a clean two-coefficient fit (no E_in = E_out/6 convention here). 2026-09-07 correction: Jegham v6 Table 1 has a Meta/AWS row of its own (PUE 1.14, WUE 0.18, EWIF 5.11 L/kWh, CIF 0.287 kgCO₂e/kWh). The seed said the host was not named and decompounded the Table 4 energies with a generic PUE of 1.2 that was nobody's. The fits (a = 21.5 and b = 151.9 Wh/Mtok with PUE for Llama 3.1 8B; a = 35.2 and b = 729.7 for Llama 3.3 70B) are decompounded at 1.14: 19 / 133 and 31 / 640 Wh/Mtok IT (instead of 18 / 127 and 29 / 608, underestimated by 5%). The service PUE also moves to 1.14: Groq, the billed host, publishes neither PUE nor electricity mix, the AWS row is the only sourced choice, and the CIF, EWIF and WUE (0.12, first-party AWS 2025 vintage) already followed that row. medium confidence unchanged: AWS infra proxied for a Groq service on LPUs, hardware that differs from the GPU infra of Jegham's estimates. Groq retired both models for the free and developer tiers on 2026-08-16 (console.groq.com/docs/deprecations); groq.com/pricing redirects to the homepage and console.groq.com/docs/models lists them as "Enterprise, contact sales": both sheets become legacy, last public prices of 2026-07-03 kept.

USD cost

The cost is the theoretical API value of the usage (what it would cost pay-as-you-go), not the subscription price actually paid. Prices are the public Claude API price list (platform.claude.com/docs/en/about-claude/pricing), re-read on 2026-09-07. The Start, Build and Scale tiers only set rate limits, not prices. Since v4.5 prices are dated: a usage row is billed at the rate in force on the day it happened, and the registry keeps the price periods (pricingHistory in the seeds, pricingAt function in lib/providers/registry.ts). Without a date, as in the public calculator, the current rate applies. Energy, CO₂e and water never depend on the date.

The introductory price of Sonnet 5 ($2 / $10 on 30 June 2026) became permanent: the increase to 3 / 15 scheduled for 1 September was cancelled. Claude Fable 5.1, released on 1 September 2026, bills cache reads at 0.025× input, against 0.1× on the other families.

Price by exact model (since v4.6). The table above prices a row that only carries a family. When the row carries the raw model identifier and that model has its own price, that price applies, whatever the date. Price list re-read on 2026-09-23:

Opus 5 and 4.x, Sonnet 5 and Haiku 4.5 bill at their family price. A dated identifier (claude-opus-5-5-20260922) takes its model's price; claude-opus-5-50 is not Opus 5.5 and stays at the family price. Energy, CO₂e and water do not change: a different price says nothing about the energy used, Opus 5.5 keeps the Opus family energy. These models are not separate public sheets, their sheet stays their family's.

What already carries the raw identifier: the Admin API syncs (usage report and Claude Code Analytics). What does not yet: CLI events. The hook pushes the family of the session's main model, and subagent tokens are folded under that same model. An Opus 5.5 session pushed by the CLI is therefore billed at the Opus family price, and a Sonnet 4.6 session at the Sonnet 5 price, until the CLI version that pushes a per-model breakdown. Opus 4.1 and 4 ($15 / $75, retired) and Haiku 3.5 ($0.8 / $4) still resolve at the price of their current family.

One-hour cache writes are billed at 2× input, against 1.25× for the 5-minute cache. The Admin API usage report splits the two buckets, but the dashboard still counts every write at 1.25× for now. Two sources do not split them at all: Claude Code Analytics, which carries subscription usage (Claude Code writes to the 1-hour cache there, so this cost is underestimated), and the public calculator, which only receives a write volume. Energy does not depend on the cache duration. The cost is an API equivalent at public rates, not the amount actually billed (subscriptions, discounts, commitments).

For a session, with the prices of the period valid at its date:

cost_usd = (
    input_tokens * input_price
  + cache_creation_tokens * cache_write_price
  + cache_read_tokens * cache_read_price
  + output_tokens * output_price
) / 1_000_000

Implemented in lib/co2.ts, function co2ToCostUsd, rounded to 4 decimals. Per-model cache prices are materialised in lib/providers/seed/anthropic.json (cacheWriteUsdPerMtok, cacheReadUsdPerMtok). On deduplicated data, this calculation reconciles within a few percent with ccusage.

Display in euros. The public calculator and the cockpit display the cost in euros: the USD amount is converted at display time at the ECB reference rate carried by lib/currency.ts (EUR_PER_USD, EUR_RATE_ASOF), i.e. 0.8729 as of 2026-06-22 (1 EUR = 1.1456 USD). The rate is refreshed by hand about once a month; amounts are stored in USD, never in euros, so a historical row is never re-converted. The calculator's cost tile interpolates the rate date ("public USD rates, converted at the ECB rate of 22 June 2026").

Token counting and deduplication

Counts come from parsing the JSONL transcripts (message.usage). Assistant messages are deduplicated by (message.id, requestId), keeping the last occurrence, before summing. This is necessary because resumed or compacted sessions replay previous messages in the same file, and because streaming rewrites the same message several times with a growing output_tokens. Without dedup, the raw sum overcounts by about 3x. This behaviour matches the deduplication performed by ccusage.

Source coverage: what the measurement sees, what it does not

We get the question in every conversation: "do you count claude.ai chat? Claude Cowork?". Here is the answer, surface by surface. Two collection paths exist:

• The Anthropic admin key (sk-ant-admin01-...) is created in the console by an administrator of the organisation. It exposes two read-only APIs: the Usage & Cost API (tokens and spend of API usage, per model and per day) and the Claude Code Analytics API (Claude Code usage per user and per day). We keep tokens from this second API for subscription seats only: API-billed Claude Code already arrives through the usage report, on one line per key, without the person. On a Team plan, the presence of these seats in the API has not yet been checked on a real account.
• Continuous tracking adds the TokenClimate CLI installed on workstations, which measures Claude Code sessions locally (section "Token counting and deduplication"). Overlaps between sources are subtracted by reconciliation (day, member, model family): the same token is never counted twice.

The limits, spelled out:

• The claude.ai chat of a Team plan has no API. Anthropic exposes neither tokens nor counters for chat under a Team subscription, and automated access to claude.ai is forbidden by its terms of use. No tool on the market covers this surface. The report declares it out of scope; it does not estimate it.
• Claude Cowork follows the same rule on a Team plan: usage under subscription, no API.
• The Enterprise case is different. Claude Enterprise organisations have an Enterprise Analytics API that exposes chat, Claude Code and Cowork activity per user (data since 2026-01-01). It requires an Analytics key created on claude.ai by the primary owner, distinct from the admin key, and only provides tokens for usage-billed plans: on a seat plan, activity is available, but CO₂e there would be derived from activity counters and not real tokens, hence estimated. We activate this path on request.
• OpenRouter is a gateway, not a provider. Each row is attached to the model's real provider and priced with its factors, on a strict resolution of the identifier: a model missing from the catalogue keeps its tokens and a "not covered" CO₂e. Three limits. Cache writes are not distinguished at the daily grain and are counted as input. A BYOK row (the organisation's own Anthropic or OpenAI key routed through OpenRouter) is skipped when the provider's Usage API already feeds the organisation, so nothing is counted twice. Claude Code or an SDK pointed at OpenRouter are also seen by the CLI or the SDK, with no reconciliation to date.
• Every line of the report carries a label: measured, estimated or declared. What is not measurable is written "not covered". No implicit estimate replaces it.

Team. The dashboard follows the current org chart: a usage row counts in the team the person belongs to today (employees.team_id), whether it comes from the TokenClimate CLI or from an admin key. An API key or a project with no person behind it counts in the team set in its source settings. The ESRS export has no team breakdown: it aggregates by provider and model family, and a team change alters none of its totals.

Keys and projects. The Anthropic API usage report does not identify the person, only the API key and the workspace. Each row pulled from it carries its key (source_scope_id) and lands on a shared line of its own for that key; usage with no key, from the Console or the Workbench, stays on the organisation's shared line. The row's product (Claude Code, chat, Cowork, Office) comes from the key's mapping, failing that from its workspace's, and is claude_code when neither sets one. On the OpenAI side, source_scope_id carries the project, and usage the API does not attribute to any member lands on its project's shared line. A shared line counts neither in headcount nor in team sizes, but its usage counts in every total. The overlap with the CLI is computed per day and model family, then split across the keys pro rata of their API tokens.

Data quality. Every usage row carries a data quality tier (data_quality_tier). Everything stored today, from the APIs, the CLI or the SDK, is measured: tokens counted by the source. Four lower tiers are planned for usage without a key, and no row carries them yet: reconstructed (rebuilt tokens), dollars (an amount converted into tokens), counts (a count of messages or requests) and seat (a seat times a usage profile). The tier changes no calculation to date.

People visibility. Each organisation is in one of two modes. In "aggregates only", the default for every new organisation, the administrator sees the organisation, the models, the projects, the provider keys and projects, and the teams of at least 5 people. The other teams are folded together into "Other teams", with the people who have no team. When the fold contains people, it contains at least 5: the teams under the threshold, the people without a team and, if needed, the smallest of the displayed teams. Without this rule, the organisation's total minus the displayed teams would give the figures of a smaller group. The one exception is an organisation of fewer than 5 people: all its teams are folded and it shows only its total. The same fold applies to the comparison between teams, to a team's page and to team email campaigns. Person pages, the roster and the per-member leaderboard disappear, and no email can target a single person. Shared lines (an API key, a project) stay named: a key is not a person. Each employee sees their own figures on their personal page, and the monthly recap addressed to them continues. In "people visible", the product shows names with no threshold; the organisation switches to it through a dated declaration that employees have been informed (works council consulted, or a small team where everyone is informed and agrees), logged and carried into the exports. Limit: a project's name stays visible in both modes, and a project with a single contributor in a small organisation can point to someone. The CSV export of calls stays available in aggregates mode without the person column; each row keeps its timestamp and its project, the same limit as the project name.

Models outside the catalogue: default estimation

A model absent from the catalogue (lib/providers/seed/*.json) has neither energy nor price in the registry. Up to v4.2 its tokens were counted and its CO₂e shown as "not covered". Since v4.3, two steps.

Step 1, the catalogue. The pnpm catalog:propose script looks the model up in EcoLogits' models.json (pinned release 0.10.2), replays their parametric model on the published architecture assumptions (output energy at the midpoint of the min-max active-parameter range, the convention of the Google and Mistral seeds), sets E_in = E_out / 6, takes the public price from the OpenRouter snapshot and prints a seed entry at low confidence, provenance included. A human validates and pastes it: the model enters the catalogue, with its page. Nothing is written automatically.

Step 2, the price proxy. At ingestion, a model still absent from the catalogue but whose provider is seeded (known infra parameters) and whose public price is in the OpenRouter snapshot (lib/providers/seed/openrouter-prices.json, regenerated by pnpm prices:refresh, stale beyond 120 days) is estimated from the catalogued model of its provider nearest in output price (log distance):

r_in  = price_in(model)  / price_in(anchor)
r_out = price_out(model) / price_out(anchor)
ratio = clamp( sqrt(r_in × r_out), 0.1, 4 )
E_in  = E_in(anchor)  × ratio
E_out = E_out(anchor) × ratio

Both prices come from the same list, the snapshot, the anchor being found through its OpenRouter id or aliases; the seed price is a last resort only. On open-weight models OpenRouter routes to the cheapest host and its price differs from the seed by up to 2.5× (Llama 70B: 0.32 vs 0.79 $ per Mtok output): mixing the two lists would bias every ratio. The [0.1; 4] clamp is a safety net, not the expected result: the anchor being the nearest in price, the ratio is usually close to 1. A zero price (free tier, per-second billing) is no signal: the model stays not covered.

The result carries co2_confidence = low, factor_version = price-proxy-openrouter-<YYYY-MM> (snapshot month) and the anchor's name. It does not enter the public catalogue. ESRS exports list the factor version per line, so the proxy is legible there. Replayable example on the 2026-09-07 snapshot (deepseek-v4-flash, the v4.3 example, has since entered the catalogue): deepseek-v3.2 (0.269 / 0.4 $ per Mtok) anchored on deepseek-chat (0.32 / 0.89 $ on the same list): ratio 0.61, i.e. 711 / 4,266 Wh per Mtok against 1,157 / 6,940 for the anchor. It is pinned in tests/unit/price-proxy.test.ts.

What the proxy does not know. Price reflects margins, loss leaders and commercial choices, not just energy: within the catalogue, Wh per output dollar span a factor of 100 at OpenAI (o3-mini vs gpt-4.1-nano), 6 at Google, 4 at Mistral. That is the proxy's error bar, tier T3. Providers without a seed (xAI, Qwen, Z.ai, MiniMax…) are never estimated: they lack a sourced PUE and grid mix, and a proxy does not invent them. They stay "not covered" and are reported in the sync result.

What changes from v4.2. The family-regex fallback, which took the first entry of a family (a 70B Llama priced as the 8B, a Gemini Pro at the Flash price), is removed for every provider but Anthropic, whose seed is per family. Uncatalogued ids that relied on it move to the proxy when they have a public price, and become not covered otherwise; the recompute (pnpm recompute:co2) lists both.

Excluded models (non-Anthropic)

Claude Code can be pointed at non-Anthropic models (for example a local model behind ANTHROPIC_BASE_URL). Their impact profile is not that of an AWS datacenter: neither the energies nor the API pricing apply. Sessions whose dominant model does not contain claude (including the <synthetic> marker) are not pushed by the CLI.

Displayed equivalences

To make the units tangible, the dashboard, the deck and the emails display equivalences. All are sourced and interpolated from lib/co2-equivalences.ts (re-exported by lib/co2.ts), never copied:

• Water: 5-minute showers, about 60 L. Source ADEME, agirpourlatransition.ademe.fr, page "Astuces pour réduire sa facture d'eau": 35 L for a quick shower under 5 minutes, 100 L for 15 minutes; 60 L is the top of the ADEME range (35 to 60 L) for a common 12 L/min flow over 5 minutes. round(water_ml / 60_000), function waterToShowers; below one shower, no equivalence is displayed.
• CO₂e, car: 142 gCO₂e per kilometre for a combustion-engine car, manufacturing included (111 g/km usage only). Source Impact CO₂ (impactco2.fr/outils/transport/voiturethermique), ADEME, 2025 modelling. car_km = round(co2_grams / 142), function co2ToCarKm. Same factor as the OSS plugin claude-carbon. The former "120 gCO₂e/km, ADEME well-to-wheel factor" matched no ADEME publication and was removed in v4.5; displayed kilometres drop by 15%.
• CO₂e, reference prompt: Google publishes 0.03 gCO₂e market-based for a median Gemini prompt of 0.24 Wh (arXiv:2508.15734). The 0.09 gCO₂e location-based cited by the product is a TokenClimate derivation: 0.24 Wh × 345 gCO₂e/kWh, the 2024 location-based intensity from the same paper.

Deck recommendations

The last slide of the executive deck (PPTX export, lib/exports/deck-layout.ts, thresholds in lib/exports/deck-recommendations.ts) never writes a generic sentence: each card is triggered by a named threshold, quantified over the period, and the points checked without an alert are listed. At most three cards (MAX_RECOS = 3), sorted carbon first, euros second. Euros apply to the metered share of the spend (meteredTotalUsd / apiEquivalentTotalUsd): a seat holder who moves from Opus to Sonnet saves zero euro, while the CO₂e applies to every token. Gains are estimates, never measurements.

Thresholds:

• Opus on short calls: Opus calls under SHORT_OUTPUT_TOKENS output tokens (lib/explorer/signals.ts), shown when they weigh at least 10% of the period's cost (OPUS_SHORT_MIN_COST_SHARE = 0.1). Gain computed on the registry's Opus minus Sonnet factors and prices, at constant volume. Under 10% of the cost the card moves noise; above it, default routing is a tech lead's first decision.
• Cache under-used on the API: cache-read rate on cacheable sources under 30% (CACHE_LOW_RATE = 0.3), gain estimated up to 50% (CACHE_TARGET_RATE = 0.5), only if those rows weigh at least 5% of the cost (CACHE_MIN_COST_SHARE = 0.05). Sonnet basis. 30% is the low point observed on agents with a stable system prompt, 50% a target reachable without rewriting the application.
• A subscription would cost less than usage: metered-only members whose bill over the window exceeds a Max 20x seat (FinOps present).
• Under-used seats: seats whose usage is worth less than 50% of the price (IDLE_SEAT_USAGE_RATIO = 0.5). Under half, the lower plan or pure usage is cheaper at renewal.
• Concentration by project: from 5 active projects on (CONCENTRATION_MIN_PROJECTS = 5), when the top three make at least 60% of the attributed CO₂e (CONCENTRATION_SHARE = 0.6). Governance, no quantified gain.
• Annual projection: only from 14 elapsed days on (PROJECTION_MIN_DAYS = 14), factor 365 / days.

Cache assumption of the "Cache under-used" card: the gain assumes a cache read billed at the registry's cache-read price (0.1× input on Sonnet) and counted at cache_read_factor (0.08) of the input energy, without counting the cache write at 1.25× the input price and at full energy. On a prefix re-read fewer than two times, the write cancels the euro gain; the card therefore overestimates the gain on low-reuse workloads. That is accepted and written on the slide ("Estimated gains, never measured").

Assumptions and uncertainties

The min-best-max ranges per parameter are in the "Anthropic parameters" table. The dominant levers on the final figure, in estimated order of importance:

• cache_read_factor (0.08): cache reads represent more than 90% of tokens in intensive Claude Code usage. Range 0.05-0.20, about -40%/+150% on the cache term.
• Location (±30% on the CIF): AWS/GCP/Azure/Colossus split not published by Anthropic. The range does not cover the TVA subregion of Colossus 1 (0.429 kgCO₂e/kWh in eGRID2024).
• Source batch (8): Jegham v6 estimates everything at 8 concurrent requests; a batch of 16 lowers energy by about 43% in its own appendix A. Direction: possible overestimation, not quantified (see "Sensitivity note").
• Idle capacity (overprovisioning): excluded by Jegham v6 ("We exclude idle power consumption from unutilized GPUs in partially loaded nodes"). Google puts provisioned idle machines at 0.02 Wh out of the 0.24 Wh of a median Gemini prompt, i.e. 10% (Elsworth et al., arXiv:2508.15734). Direction: underestimation of that order, not added for lack of data at Anthropic.
• E_out Fable: price proxy with no published measurement, on the most expensive family of the catalogue.
• E_in = E_out/6 (non-Anthropic providers): published range 1/21 to 1.2 (see "The input/output ratio"), the 1/6 convention sits in the low part of that range. For Anthropic, the ~1/21 ratio is recovered from the v6 fit; it is no longer a free assumption.
• EMB (49): sensitivity 22-66. Since v3.7 this bracket has been presented as an amortisation uncertainty; that is inaccurate, it aggregates several sources of uncertainty, and the "3-6 years" label was removed from the table rather than implying a single cause. At 3 years, the lifetime used by ADEME's LCA, the derivation gives 82 gCO₂e/kWh, outside the range.
• Unknown silicon: the whole hardware chain assumes an NVIDIA fleet. Anthropic also serves on Trainium2 and on TPU, with no published split. Neither the embodied term nor GPU-estimated energies cover that case.
• Constant E_out in long context: per-token decode energy rises from 107 to 242 mJ between 4K and 16K of context on GQA (arXiv:2605.11999), a factor of 2.26, while our E_out is flat. The bias runs toward underestimation in the agentic regime, precisely the Claude Code regime.

Claims that circulate wrong

While verifying our own sources, we ran into six statements that circulate in articles, tender documents and reports, and that are wrong against the text they cite. We publish them because a reader may put them to us, and because nobody else corrects them.

1. "Article 53 of the AI Act requires documenting energy." Article 53(1)(a) requires technical documentation; it is Annex XI, Section 1, point 2(e) that carries the energy obligation. The exact citation to use is "Article 53(1)(a), and Annex XI, Section 1, point 2(e)".
2. "Annex XI covers training energy." The text says "known or estimated energy consumption of the model". It is the preceding point, 2(d), that targets training compute resources.
3. "SCI for AI gives 130 kgCO₂e per billion tokens." That value is marked EXAMPLE in the Green Software Foundation specification, illustrative and non-normative. It is nobody's emission factor. The specification provides no default values at all, no PUE, no grid factor, no amortisation period.
4. The tiers of the Llopis methodology (arXiv:2606.10660) cited in reverse. The paper's order is: Tier 3 = certified supplier carbon reporting, the best; Tier 2a = exact token counts; Tier 2b = estimated tokens; Tier 1 = spend-based, the worst. There is no Tier 4. The paper notes in passing that no major AI provider offered certified carbon reporting as of May 2026.
5. "AWS market-based = 0." AWS claims 100% renewable matching but publishes no market-based kg/kWh factor; Amazon as a whole reported 2.80 MtCO₂e of residual market-based scope 2 in 2024, without isolating AWS. The correct value is "not published by AWS".
6. "Cache is carbon-neutral." No normative framework, SCI for AI included, addresses caching. The absence of a rule is not a rule: see "Cache energy".

Caveats

What we do not measure, and why.

• Order of magnitude only. These figures are structured, sourced estimates, not a regulatory report nor a verified LCA.
• Datacenter third, inference-only scope. Devices (~50% of the digital footprint in France), networks (~4%) and training are excluded (ADEME-Arcep update of January 2025, 2022 data), as are datacenter construction (under 1%) and overprovisioning (around 10%), see "System boundaries".
• The cache term does not have the right shape. It captures a prefill residual; the KV re-read residual during decode, bilinear in (context × generated tokens), is absorbed into a constant E_out. See "Cache energy". It is the most important lever of the final figure.
• Anthropic's real hardware fleet is not published (NVIDIA, Trainium2, TPU). None of our hardware values covers it.
• No ground truth exists on energy. Nothing lets us reconcile our Wh against a measurement. The only available check is on cost, via ccusage, and it does not validate the physics.
• No geo-specific coverage. CIF applied uniformly, ±30% sensitivity to the real location.
• Fable is a price extrapolation. No published measurement, to be revised as soon as an independent one appears (Epoch AI or equivalent).
• Embodied carbon is a derivation, not an end-to-end published figure: ADEME GPU LCA (no use phase) + BoaviztAPI for the host server, amortised over 5 years, sensitivity 22-66 gCO₂e/kWh, 82 at 3 years.
• Water is an estimated consumption, not an ISO 14046 footprint: no weighting by local water stress, and the total adds a withdrawal (WUE) to a consumption (EWIF), see "On water".
• AWS market-based not published. AWS publishes no market-based kg/kWh factor: we write it as such, we never display zero.
• No cancelled sessions. An interrupted session counts the tokens already generated, in line with Anthropic's billed usage.
• Subagents aggregated into the parent. If Claude Code launches subagents during a session, their tokens are summed into the parent session under its dominant model (see cli/scripts/persist-and-push.sh). A small approximation when a subagent runs on another Claude family.
• History before 2026-06-12. Rows ingested before that date carry an input_tokens that includes cache writes, and their co2/cost did not count the cache_read term. They are kept as is (slight underestimation).

How to verify

The TokenClimate CLI exposes a command that shows the local values before push, identical to what will be ingested on the dashboard side:

tokenclimate org status

You will see per session: input_tokens, output_tokens, cache_creation_tokens, cache_read_tokens, detected model, and the computed impact. If you want to audit the calculation end-to-end, compare with the session detail displayed on /employee/[id] of the dashboard.

All energies, all parameters and all prices used are published in this document, with their sources. Test vectors give exact expected values for energy_wh, co2_grams and water_ml, replayed in CI on every change. No value is computed on an opaque client side.

Columns of the ESRS export

The export (lib/exports/esrs-export.ts, standard "ESRS E1, CO₂e, GHG Protocol scope 3 category 1; ESRS E3, water, informative") aggregates usage rows by provider and model family. Each column reads against this document:

No co2_total_kg_min / _max columns: an honest range starts from per-model token counts (the cache_read term is bounded 0.05-0.20 there); the export only carries aggregated energy and CO₂e per line, so the cache bound cannot be computed here. A propagation without the cache term (CIF ±30% and embodied 22-66 only) would give a range too narrow to be honest; adding cache tokens to the export lines remains to be decided.

Recomputability

Each usage_events row keeps its raw components (input, output, cache write, cache read): energy_wh, co2_grams, water_ml and cost_usd remain re-derivable at any time from the current methodology. Every source stores cache-write tokens in the same column, cache_creation_tokens; the SDK route used a separate column, cache_write_tokens, folded into the first and then dropped. After a parameter or pricing change, pnpm recompute:co2 (script scripts/recompute-co2.ts, dry-run by default, --apply to write) recomputes the whole history with the functions of lib/co2.ts and restamps factor_version. Rows whose model does not resolve in the registry keep a null impact, never an invented one.

Versioning

The current version is the one in this document's header. Parameters are renewed at least once a year (AFNOR Spec 2314 requirement), and earlier if a pinned source moves: new version of Jegham et al., EcoLogits release, publication of a Fable measurement, AWS market-based factor. Every evolution produces a new version of this document.

Since v3.8 that promise has a mechanism rather than an intention. Pinned sources live in a versioned registry (data/sources/registry.json) recording, for each one, what we pinned, what it feeds, and when a human last re-read it. A weekly check queries arXiv and upstream releases, and two alerts block CI: a source that moved past what was explicitly acknowledged, and a factor unreviewed for more than twelve months. Deliberate gaps are handled: EcoLogits is pinned at 0.10.2 for Google and Mistral while the current OpenAI range is sourced from 0.11.1, and that is recorded as such rather than raised every week.

The MiNumEco "frugal AI" factsheet of November 2025 cites neither EcoLogits, nor an effective date, nor Article 53 of the AI Act: v3.3 of this document implied it, and that is withdrawn. The wording of our reports points to this section for verification.

History:

• v4.12-methodology-2026-10: overprovisioning is named. The capacity kept in reserve for peaks and failures now appears among the exclusions in "System boundaries", with its order of magnitude (10% of the energy of a median prompt at Google), and the "Idle capacity" assumption carries that name. No figure moves.
• v4.11-methodology-2026-09: gpt-6.1-sol enters the catalogue (2 $ input, 10 $ output per Mtok, cache read 0.1, cache write 2.5), released by OpenAI on 2026-09-29 and not covered by EcoLogits. Energies by the hand-applied price-proxy rule: gpt-6-sol × 1.000 (250 / 1499 Wh/Mtok), confidence low. No other figure moves.
• v4.10-methodology-2026-09: limits of the main source and scope, published. No energy, CO₂e, water or cost figure moves, no calculation range changes. Additions, all re-read at source: the batch of 8 set by Jegham v6 and its effect in its own appendix A (a batch of 16 lowers energy by about 43%), the "Large" hardware class assigned for lack of a published size and the host counted at 0.5, in the sensitivity note; the idle capacity excluded by Jegham, about 10% at Google; the Haiku / Sonnet ratio, whose 0.5 has no primary source (sensitivity range 0.2 to 0.6); the eGRID2024 reference points for the AWS subregions and the TVA (0.429), which the ±30% range does not cover; ADEME's 3-year amortisation (82 gCO₂e/kWh); model development and datacenter construction, excluded, with their order of magnitude. Corrections: the 273 kgCO₂e of ADEME's LCA are manufacturing, distribution and end of life, with no use phase; Jegham's Table 1 cites Electricity Maps as reference [44], with no weighting note, and the quote "mix-weighted across AWS inference regions", absent from v6, is replaced by the text of §4.1. Source coverage: the Anthropic Admin key attributes a person only on subscription seats, API-billed Claude Code stays per key except through the CLI, Team-plan seats remain to be checked on a real account, and the missing OpenAI row is added.
• v4.9-methodology-2026-09: the Bilan IA is retired. This self-serve product, which read an Anthropic admin key and returned a one-off report, is no longer offered. The passages that cited it now speak of the admin key, the report or the dashboard, without changing what they describe. The published uncertainty ranges live in lib/methodology/ranges.ts. No energy, CO₂e or water figure changes.
• v4.8-methodology-2026-09: ADPe annex removed. It only counted electricity, with the US electricity-mix factor from ADEME's Base IMPACTS (2011 vintage), applied without PUE, whereas hardware manufacturing makes up most of this indicator (ADEME GPU LCA, March 2026). The indicator will come back once the manufacturing share can be allocated to usage from a source. The two Sb eq figures quoted from Mistral's LCA are removed with it. No energy, CO₂e or water figure changes.
• v4.7-methodology-2026-09: hardware manufacturing re-sourced. The GPU term of the embodied constant (EMB) moves from the manufacturer's declaration (NVIDIA PCF for the HGX H100 baseboard: 1,312 kgCO₂e for eight GPUs, cradle to gate) to the life-cycle assessment of GPUs published by ADEME in March 2026 (Lees-Perasso et al., Hubblo, TND, TIDE, CNRS and INRIA, Table 44: 273 kgCO₂e per H100 SXM 80 GB, cradle to grave, manufacturing, transport and end of life included), i.e. 2,184 kgCO₂e per node. The host server, the 5-year lifetime, the power and the utilisation rate do not change. EMB goes from 44 to 49 gCO₂e/kWh IT, the published 22-66 range stays the same. For Anthropic, K_co2 goes from 0.37118 to 0.37618 gCO₂e/Wh and the embodied share from 11.9% to 13.0% of total CO₂e. What moves: the CO₂e of every row, by +1.35% on Anthropic and Meta, +1.15% on OpenAI, +1.19% on Google, +0.62% on DeepSeek and +4.6% on Mistral, whose low French grid mix leaves more weight to manufacturing. Production recompute required; the Anthropic factorVersion becomes tokenclimate-v3-2026-09. Energy, water and cost do not move. The cross-check against Mistral's LCA goes from 41 to 39 mL of water per gram of CO₂e, against 39 published by Mistral.
• v4.6-methodology-2026-09: gpt-6-sol ($2 / $10) and gpt-6-luna ($0.10 / $0.50), released by OpenAI on 2026-09-22 and not in EcoLogits, enter the catalogue. Energies by the price-proxy rule applied by hand: gpt-4o × 0.89 for Sol (250 / 1,499 Wh/Mtok), gpt-4o-mini × 0.75 for Luna (9 / 53), low confidence. Astra prices re-read, unchanged. No other figure moves. Price by exact model (same version, 2026-09-23): a row carrying the raw identifier of a model with its own price is billed at that price (Opus 5.5 at $4 / $20, reads $0.20; Fable 5.1 and Mythos 5.1 reads $0.25; Fable 5 and Mythos 5 reads $1; Sonnet 4.6, 4.5, 4, 3.7 and 3.5 at $3 / $15), families keep their dated prices, the energy of these models is their family's. The Admin API syncs now store the raw identifier. CLI events stay at the session's main model. What moves: the cost of the affected raw-identifier rows (recompute required), no energy, no CO₂e, no water. GPT-5.6 Luna correction (same version, 2026-09-23): its energy was extrapolated from gpt-5.4 on a $6 output price read on 2026-07-19 (6/15 = 0.4×, i.e. 118 / 706 Wh/Mtok). The 2026-09-07 price check corrected that price to $0.2 / $1.2 without re-deriving the energy. Luna sits at gpt-5.4-nano's price ($0.2 / $1.25): it takes nano's energy, 24 / 141 Wh/Mtok, as Sol and Terra take the energy of the model at their price. Confidence stays low. GPT-5.6 Luna's CO₂e and water drop by 80%, no other model moves.
• v4.5-methodology-2026-09: published after the content audit of 2026-09-07 (743 claims checked, 142 corrections, every surface). Anthropic prices dated per family (pricingHistory, pricingAt): Sonnet at $2 / $10 since 2026-06-30 (Sonnet 5 introductory price made permanent), Fable cache read at $0.25 since 2026-09-01 (Fable 5.1), $3 / $15 and $1 before; the USD cost of each row is that of its day's rate, at every ingestion point and in recompute:co2; the "tier 1" mention is removed (tiers only set rate limits); declared limit: a family is billed at the price of its current default model, Sonnet 4.6 stays at 3 / 15 at Anthropic and cannot be told apart in the database. The displayed cost is in euros at the dated ECB rate of lib/currency.ts, written in the "USD cost" section and on the calculator tile. Third-party catalogue rewritten provider by provider: Google, gemini-2.5-pro (2,939 / 17,636 Wh/Mtok) and gemini-2.5-flash (269 / 1,611) from EcoLogits 0.10.2, low confidence, gemini-2.0-flash (shut down 2026-06-01) and gemini-1.5-* legacy; DeepSeek, deepseek-chat and deepseek-reasoner legacy (shut down 2026-07-24), deepseek-v4-flash (1,618 / 9,705) and deepseek-v4-pro (6,056 / 36,335) by hand-applied price proxy, low confidence, peak prices of 2026-09-07; Meta, PUE 1.14 (Meta/AWS row of Jegham v6 Table 1) instead of the 1.2 placeholder, Llama energies 19 / 133 and 31 / 640 Wh/Mtok (+5%), CO₂e and water per Wh aligned on the AWS row, both Llama legacy (Groq retirement 2026-08-16); Mistral, prices of 2026-09-07 (Large 3 0.5 / 1.5, Medium 3.5 1.5 / 7.5, Small 4 0.15 / 0.6), mistral-large-latest = Large 3 replayed on the published architecture (424 / 2,546, medium), new mistral-medium-latest sheet (85 / 508), Large 2 kept as legacy under mistral-large-2411 (retired 2026-05-31), LCA paragraph attached to that sheet; OpenAI, gpt-4o, gpt-4o-mini, gpt-4.1 and gpt-4.1-mini are current again (still sold), o1, o3-mini, o4-mini, gpt-4-turbo, gpt-4.1-nano (shutdown 2026-10-23) and o3 (2026-12-11) legacy with a date, cache reads added; legacy now reads "retired or being retired by its provider". Price-proxy example replayed on deepseek-v3.2. Usage profiles: TraceLab counts 37 developers on the Claude Code column (43 was the Claude plus Codex total), cadence 1.9 session per developer per week (8.0 per month) instead of 1.6; profile input/output ratio 294; 95.5% prefix, 91.5% re-read, 95.8% hit rate on the Claude column; the private corpus median is compared to a TraceLab mean; the cadence is no longer shown on screen; the 184-session corpus is declared non-reproducible; three questions in simplified mode. Equivalences: car 142 gCO₂e/km (Impact CO₂, ADEME, 2025 modelling, combustion car manufacturing included, same factor as the OSS plugin) instead of a 120 "ADEME well-to-wheel" that matched no publication, displayed kilometres drop by 15%; shower requalified as "5-minute shower, about 60 L" with the ADEME page cited; the 0.09 gCO₂e of the Gemini prompt is presented as a derivation of the published 0.03 market-based. ESRS export: water split on-site withdrawal / off-site consumption (E3-4), IT and facility energy distinguished, data quality weighted by CO₂e, label without a source list, columns documented here. Deck: new "Deck recommendations" section (thresholds and cache assumption), manufacturing attributed to NVIDIA PCF + BoaviztAPI. Bilan report: cache-read factor range injected from the code (0.05-0.20), "prefill residual", "estimates from measured volumes", bibliography completed (Jegham five authors, AWS 2025, WRI 2020, Irminsul, Impact CO₂). Tokenizer caveat published under "Validity date of the energies": 4.7 and later models produce about 30% more tokens for the same text, a per-token factor calibrated before may overestimate by as much, no correction applied. Sourcing corrected: embodied 44 is attributed to Jegham nowhere and its derivation is published (7,012 kg over 43,800 h at 5.6 kW and 65%); Jegham et al. cited with its five authors; "measurements" becomes "estimates" wherever the source is Table 4; Artificial Analysis provides latency and throughput; Microsoft "estimates" 0.31 Wh (v2), the 111 Wh/Mtok is ML.ENERGY v3.0 on Qwen3-235B on B200, EcoLogits corrected its online calculator; Irminsul, MLA row averaged and MHA measured at 2,048 tokens; 1.3-51.8% from Solovyeva and Castor, 2K→10K tripling on Llama 3 70B; OpenAI bills cache reads at 0.1x on its current range; Mooncake 30 to 50%, 75-95% = CharacterAI and Kimi; 2.80 MtCO₂e = Amazon as a whole, not AWS; Google 0.03 market-based published, 0.09 location-based derived; a single EcoLogits repo name; Google PUE sourced to Elsworth et al.; 50/46/4 split sourced to the ADEME-Arcep update of January 2025; Colossus deal with SpaceX (formerly xAI), 2029 horizon reported by TechCrunch; AFNOR Spec 2314: min-best-max and versioned method requalified as own practices, location-based in a note to §4.3; the MiNumEco factsheet cites neither EcoLogits nor Article 53; gpt-6-astra "announced" on 2026-09-03; hardcoded "v3" removed from the body; Haiku 61 explained (rounded OSS factor); booking link present in both languages. What moves in figures: the cost of Sonnet rows after 30 June 2026 drops by about a third, that of Fable cache reads after 1 September by three quarters (production recompute required); Meta energies rise by 5% (no Meta row in the database); displayed kilometres are divided by 1.18. No Anthropic energy, CO₂e or water figure moves.
• v4.4-methodology-2026-09: gpt-6-astra (announced on 2026-09-03, limited preview then API opened in the following days) enters the catalogue, energies of gpt-5.5 × 1.83 by the price-proxy rule applied by hand, low confidence. gpt-5.6 prices re-read on 2026-09-07 (Sol $4 / $20 promotional, Terra $2 / $12, Luna $0.2 / $1.2, cache writes billed): only the USD costs of those three models change, and no OpenAI row exists in the database. "On water" rewritten: the gap between the 5.11 L/kWh EWIF and the literature's 1.8 L/kWh is an allocation convention (hydropower reservoir evaporation counted by WRI, excluded by Grubert and Sanders), not an error to fix, and 5.11 is indeed a consumption, declared as such by Jegham; the WRI guidance is dated 2020. Mistral's water sources corrected in the seed and on the sheet: the WUE of 0.18 is the AWS 2023 value reused for want of a disclosure (not Jegham's Table 1, which has no Mistral row), and the EWIF moves from 3.13 (US average) to 3.67 L/kWh, the France factor of Appendix 2 of the WRI 2020 guidance: water for Mistral models rises by 16%, and no Mistral row exists in the database. AWS's 5.11 is verified as reproducible on those same appendices (about 40% Northwest at 9.48 and 60% Virginia at 2.37). The calculator shows under water the share of on-site cooling, computed on the mix. New paragraph on Mistral's LCA (July 2025) under "Third-party providers": it provides none of our terms, its water/carbon ratio matches our France parameters within 3%, its per-response level is 44× ours, a perimeter gap published rather than smoothed over. No change to any equation or per-model energy; outside Mistral, not one CO₂e, water or energy figure moves.
• v4.3-methodology-2026-09: new section "Models outside the catalogue: default estimation". Step 1, pnpm catalog:propose proposes a seed entry from EcoLogits 0.10.2 (human validation). Step 2, price proxy at ingestion: energies of the catalogued model of the same provider nearest in price, × the geometric mean of the input and output price ratios, clamped [0.1; 4], prices from the same list (public OpenRouter snapshot, stale at 120 days), co2_confidence = low, factor_version = price-proxy-openrouter-<month>. The family-regex fallback is removed for non-Anthropic providers. New T3 row "E_out price proxy" in the parameters table. No change for catalogued models; uncatalogued rows move from "not covered" to a T3 estimate or stay not covered (unseeded provider, missing or zero price), recompute traced.
• v4.2-methodology-2026-09: added OpenRouter to "Source coverage": management key, one row per day, person and model, attached to the real provider and priced with its factors on a strict resolution of the identifier. Declared limits: cache writes counted as input, BYOK rows skipped when the provider is already measured, no reconciliation with the CLI or the SDK. No change to equations, factors or prices: no existing figure moves.
• v4.1-methodology-2026-09: added the "Estimation per usage unit (simplified mode)" section: output tokens per session (96,900,000 / 2,676) and per exchange (150), plus TraceLab's measured cadence (1.6 session per developer per week) shown as a reference point. No cadence is published, unlike the per-task volume table removed in v3.7: the value is entered by the visitor and stays editable in the volume field, and only the tokens per unit are derived from already-sourced aggregates. The result is rounded to two significant digits and presented as T3, the dominant uncertainty coming from the declared cadence. No change to equations, factors, reference volumes or prices: at equal volume, no displayed figure moves.
• v4.0-methodology-2026-08: source over-qualification corrected. Jegham v6 is not a measurement campaign: its section 4.2, "Per-Query Energy Consumption Estimation", describes a Monte Carlo simulation over nameplate power, an assumed utilisation and a batch size fixed at 8, with Artificial Analysis latency as the only empirical input. Every row of Table 4 is a modelled estimate. The product wrote "direct measurement" on the /models sheets, in the high tier gloss, in the seed notes published as JSON-LD and in the cockpit tooltips: all of that copy is reworded, across the five report locales. The confidence scale is redefined and now ranks estimates against each other. DeepSeek moves from high to medium, its fit being output-only under an NNLS constraint with an input convention, i.e. the case that already earns medium at OpenAI. Two newly published caveats: DeepSeek is the most dispersed row of the panel, and the deepseek-reasoner fit is mis-specified (centred R² -2.76, slope inflated ~2.7x by forcing it through the origin), the figure being kept and tracked rather than silently patched. Embodied 44 gCO₂e/kWh is no longer attributed to Jegham in deepseek.json and meta.json: Table 1 has no embodied column and the paper excludes scope 3, the constant comes from NVIDIA PCF plus BoaviztAPI. Removed the version hardcoded in the body, which announced v3.7 two versions later. No change to any equation, energy, infra parameter or price: not one CO₂e, water or energy figure moves.
• v3.9-methodology-2026-08: Anthropic confidence levels corrected. Opus and Haiku move from high to medium: their energy is extrapolated from Sonnet (×2 and ×0.5), only the Sonnet class is measured, and the registry published them as high purely through its default value, for want of an explicit declaration in the seed. All four families now declare their confidence explicitly (Sonnet high, Opus and Haiku medium, Fable low unchanged). Alongside it, the infra source attribution on the /models sheets is corrected: Anthropic's and Meta's PUE and on-site WUE are credited to the first-party AWS disclosure rather than to Jegham, which v3.8 had already recorded here without propagating it to the public copy. No change to any equation, energy, infra parameter or price: not one CO₂e, water or energy figure moves, only the confidence labels and two sourcing sentences.
• v3.8-methodology-2026-08: on-site WUE 0.18 → 0.12 L/kWh, re-sourced on the first-party AWS disclosure (2025 vintage) instead of the Amazon 2023 report; PUE 1.14 unchanged but re-sourced the same way. The parameter block becomes explicitly composite. Tier reclassification: CIF and EWIF T1 → T2, cache_read_factor T3 → T2, E_in/E_out ratio T2 → T3. Published range of cache_read_factor widened from 0.05-0.15 to 0.05-0.20. "Cache energy" rewritten around the Irminsul measurement, including the finding that the term does not have the right shape. "On water" (withdrawal plus consumption) and "Assumed location" (Colossus 1, Memphis) rewritten. The 5-year amortisation is now sourced. New sections "Validity date of the energies", "Sensitivity note: the overestimation charge" and "Claims that circulate wrong". Three caveats added. No change to the equations, to per-model energies or to prices; CO₂e does not move for any model, water drops 1.0% on the Anthropic side.
• v3.7-methodology-2026-08: removal of the "Use cases (one occurrence)" section and its table on the public calculator: per-task volumes judged too imprecise for a public surface (mostly T3). Usage profiles remain; no change to equations, factors or prices.
• v3.6-methodology-2026-08: added the "Usage profiles of the public calculator" section (reference volumes per token class, token-based use cases, sources and tiers); no change to equations, factors or prices.
• v3.5-methodology-2026-07: added the "Source coverage" section (surfaces measured by the admin key, claude.ai chat and Cowork out of scope on Team plans, Enterprise case); no calculation change.
• v3.4-methodology-2026-07: current OpenAI range enters the catalogue (gpt-5.6, gpt-5.5, gpt-5.4, sourced from EcoLogits 0.11.1 or price-extrapolated with low confidence); the ten previous OpenAI models become legacy, factors kept to quantify past usage.
• v3.3-methodology-2026-07: added a paragraph explicitly linking EcoLogits (pinned release) to the MiNumEco factsheet of November 2025, cited by the AI usage report wording; no methodological change.
• v3.2-methodology-2026-07: DeepSeek recalibration (direct Jegham v6 DS-native measurements) and OpenAI (Table 1 verbatim), Meta provider added.
• v3.1-methodology-2026-07: Anthropic energies recalibrated on the Jegham v6 3-point OLS fit (Sonnet 119/2525 Wh/Mtok, previously 580/3480); the Anthropic input/output ratio becomes a measured value (~1/21) instead of the 1/6 convention; Opus moves from 3x to 2x Sonnet. Prices, infra parameters, cache_read_factor and formulas unchanged.
• v3.0-methodology-2026-06: energy-first switch (Wh/Mtok + infra parameters), water and embodied added.

Contact

You dispute a value, a parameter, an assumption? Write to gaetan.wittebolle@gmail.com or book a call. Substantiated corrections are welcome; the goal is not to defend the figures but to have the best possible estimate with the available data.