AI subscriptions: spend-based estimates are 30x too low
One heavily used Claude Max 20x seat emits about 310 kg CO2e a month from inference. A spend-based estimate of its EUR 180 fee gives 10 kg.
Robin Dierckx4 min read
Key finding. A Claude Max 20x seat used for full-time agentic coding emits about 310 kg CO2e a month from inference alone. A spend-based estimate of the same seat, its EUR 180 fee times the EXIOBASE factor for computer services, gives 10 kg: 30 times less. Most companies account for AI subscriptions the second way today.
What is a spend-based estimate? It turns money into emissions: what you paid, times an average emission factor per euro for the sector you bought from. It is the default for software subscriptions, because the invoice is often the only data an accounting team has. Spend-based vs activity-based factors, explained.
The test: one seat-month, two methods#
- We took one Claude Max 20x seat (EUR 180 a month) used for agentic coding in Claude Code over 30 days: long sessions, subagents and multi-agent workflow runs, mostly on Opus. That is the use the top tier is priced for.
- Token-based. We counted every token the seat processed and multiplied it by a per-token emission factor per model, following the open-source claude-carbon method.
- Spend-based. We multiplied the fee by the EXIOBASE factor for "Computer and related services", the closest sector to an AI subscription.
The results: 310 kg against 10 kg#
| Method | Activity data | Factor | kg CO2e per seat-month |
|---|---|---|---|
| Token-based | 16.1 billion tokens | 78 to 1,652 g CO2e per million tokens (Opus) | 310 |
| Spend-based, US factor | EUR 180 | 0.0569 kg CO2e per EUR | 10 (1/30) |
| Spend-based, Irish factor | EUR 180 | 0.1187 kg CO2e per EUR | 21 (1/14) |
The US factor is the natural pick: the supplier is a US company on US data centres. An EU buyer invoiced from Ireland may pick the Irish one, which halves the gap and still leaves it at 14 times.
Where the 310 kg comes from. Opus factors are 78 g per million input tokens and 1,652 g per million output tokens. A cache read, a token the model has seen before and reuses, is charged at 8% of the input factor.
| Token type | Tokens per month | Calculation | kg CO2e |
|---|---|---|---|
| Cache reads | 15.35 billion | 15,350 M x 78 g x 0.08 | 96 |
| Fresh input | 665 million | 665 M x 78 g | 52 |
| Output | 100 million | 100 M x 1,652 g | 166 |
| Total | 16.1 billion | 314, about 310 with the small Sonnet and Haiku share |
Output is under 1% of the tokens and over half of the emissions: generating a token costs about 20 times the energy of reading one. Cache reads are 95% of the tokens, because an agent re-reads its whole context on every step.
Why the gap is so large#
- A flat fee is decoupled from use. Spend-based assumes emissions grow with euros. The same EUR 180 covers a seat used an hour a week and a seat running agents all day, so the invoice says nothing about the compute behind it. The gap widens as agents run longer at the same price.
- The sector average is the wrong technology. "Computer and related services" averages consulting, software development and IT outsourcing, which is mostly labour. GPU inference at scale is energy-intensive and barely existed in the 2019 economy the table describes.
- The intensity says it all. 310 kg for EUR 180 is 1.72 kg CO2e per euro: the intensity of heavy industry, not of a service.
Our method is imperfect, because AI providers do not report#
No AI provider publishes the energy or the emissions per token, per request or per seat. Every token-based figure, ours included, is therefore modelled from public benchmarks rather than measured.
- The factors are estimates. The Sonnet factor is fitted on the inference energy benchmarks of Jegham et al. (2025), 1.35 x 10^-4 Wh per input token and 2.88 x 10^-3 Wh per output token, data-centre overhead included, at 0.287 kg CO2e per kWh. Opus is assumed to cost twice Sonnet: no measurement of it has been published.
- Inference only. Model training, the embodied emissions of the hardware and the user's own device are left out, so the figure is a floor.
- Location-based only. A market-based figure would need the provider's renewable electricity purchases per region, which are not public.
- One usage profile. A Max 20x seat used mostly for chat processes far fewer tokens and sits closer to the spend-based figure.
None of these closes the gap. For the two methods to agree, the per-token factors would have to be 30 times too high, and most of the open questions (long-context decoding, grid intensity, embodied hardware) push the figure up, not down. Supplier-reported data would settle it, and is what AI providers should publish.
How to report AI subscriptions#
- Scope 3, Category 1 (purchased goods and services), with tokens times per-model factors as the number. In the GHG Protocol's terms that is the average-data method, which ranks above spend-based.
- Take the activity data from usage logs, not from the invoice: tokens per model and per token type, from an admin usage export or the tool's own logs.
- Disclose the boundary and the factor source, and keep the spend-based figure beside it as a cross-check. A 30 times gap tells your reader why you did not use the default.
For 50 such seats, that is about 180 t CO2e a year that a spend-based inventory leaves out.
Credits#
The per-token method and the token counts come from claude-carbon by Gaëtan Wittebolle (MIT licence), an open-source tool that reads Claude Code transcripts and estimates their inference emissions. Its methodology documents every factor. We added the multi-agent workflow runs, which the tool does not count yet; without them the seat-month is about 240 kg, still 24 times the spend-based figure.