The methodology

Two estimators, each grounded in its own physics

Remote services — by volume exchanged. The energy of a remote inference follows the number of tokens produced, and the bytes received are the best available proxy for it without reading the traffic. A generation stream arrives token by token: the byte rate is the answer rate. For an agent it also follows the number of tokens read, for which bytes sent are the proxy: an agent resends its whole context every turn.

Billing connection time, as the original prototype did, overshoots badly: claude.ai and ChatGPT keep HTTP/2 sockets alive, so an open, idle tab stays established for hours. On a byte delta, it weighs zero.

Local models — by inference time. Here the energy is this machine's: power drawn × duration. The bytes, which travel over the loopback interface, change nothing. The rate used comes from a sensor reading on the machine under load.

Reading is only counted where its bytes-per-token ratio has been measured on real traffic — a single service to date. It is billed at a fraction of the generation rate, and the share re-read from the provider's cache, which is the bulk of an agent's input, at a fraction of that fraction. Elsewhere, bytes sent are not billed: without a measurement, nothing on the wire tells a context from an uploaded file, and a named floor beats an invented figure.

Three guardrails frame the volume

Rate cap. A model does not generate faster than a certain token rate, and billable bytes are capped at the stream rate that represents, per connection and per sample. Without it, loading the claude.ai interface — several megabytes of scripts — would cost more than an hour of conversation. It is a deliberate upper bound, not a sorting of bytes.

Noise floor. Below a threshold per service per sample, the traffic is protocol: keep-alive frames, TLS pings, session renewals. Without that floor, an open application would bill continuously.

Hourly media bound. The rate cap does not suit an image or a video, which arrive in one burst and are the payload themselves. What separates a generation from a false positive is not its rate but its duration: beyond one hundred megabytes per hour per service, the bytes are still recorded and stop being billed. A video call passes that bound within minutes; an hour of intensive generation stays well below it.

What the calculation does

CarboneWatch starts from what the operating system exposes — bytes exchanged with known addresses, or failing that a duration of established connection — and derives a volume of tokens, then an energy, then a carbon figure, using the electrical intensity of the zone where the service computes rather than that of your machine. Manufacturing of the server is added to the carbon without passing through electricity.

Each conversion rests on a coefficient, drawn from a published source or from a measurement made here on real traffic, and each carries an interval. The detail — the values, the measurement protocols, the bounds and what remains unbounded — is in the methodology dossier, available on request. What follows states the boundary, the sources and the limits: enough to judge the figure, and to contradict it.

The electricity counted is the provider's, not yours

Energy is converted to CO₂e using the grid of the region where the service computes, not the user's. Remote inference does not happen here: talking to an American service from France burns American power, at 384 gCO₂e/kWh and not 41.

Every service therefore carries a region in the registry. A missing or unknown region is billed at the world rate, 458 g/kWh — never at the most favourable one. The grid chosen in the settings applies only to local models: they alone draw this machine's power.

Scope: what is counted, what is not

The electricity of inference and, since 0.2.14, the manufacturing of the inference server, amortised over the tokens it serves, from embodied data published by BoaviztAPI and the lifetimes of its own archetypes. This term is a hypothesis under review — a server's throughput and utilisation rate are published nowhere — and it does not depend on the country: negligible against the US mix, it can reach tens of per cent against the French mix. Still excluded: training amortised over requests, the transport network, end of life, and the manufacturing of the terminal.

A full life-cycle analysis, such as the one published by Mistral with Carbone 4 and the French ADEME, typically adds 20 to 40%. That is why one vendor's figure can be thirty times another's without the hardware having anything to do with it: they are not measuring the same thing. These figures now include part of that manufacturing — the inference server, neither training nor the terminal — and are therefore comparable only to figures sharing the boundary set out above.

Data-centre overhead, on the other hand, is counted. The per-token rate is that of the computation; cooling and power losses are added by an overhead factor. It is the operation EcoLogits sets out, with a per-provider figure; since the provider serving a request is unknown from a machine, CarboneWatch takes the top of that range rather than the bottom. Local models are exempt: their consumption is already what is drawn from the wall.

In an organisation's inventory, this figure belongs to purchased services: GHG Protocol scope 3, category 1; item 4.5 of the French BEGES. That is a proposed mapping, for whoever keeps the inventory to confirm. It is given in energy and in carbon, on a location basis. The corporate AI accounting frameworks published in 2026 make the same core choices: electricity reported alongside carbon, training kept out of the main figure.

What this estimate does not know

The ratio between bytes on the wire and tokens produced is the most uncertain parameter in the whole model. It depends not on the provider but on the protocol: the frame wrapping each token weighs far more than the text it carries, and compression, where the server grants it, divides the whole. Between two common protocols the measured gap is a factor of ten. The registry therefore ties each service to a protocol family, measured once for all its members; a measurement specific to one service takes precedence over its family's, and families without a measurement keep an assumed value, named as such in the sensitivity dossier. The upstream ratio depends on the client and is measured for a single one.

On Windows, the system exposes byte counts to no application without administrator rights. The estimate there falls back on established connection time — an open tab counts as if it were working. Figures are upper bounds, the application says so in its interface, and the shared footprint counts them separately.

Factors are the same on every installation and cannot be changed. These are orders of magnitude, not measurements — an estimator, not a meter.

Detection works on addresses, and several AI services are served by shared infrastructure — Cloudflare, CloudFront, Azure Front Door — whose addresses also carry unrelated traffic. False positives are therefore possible. The registry admits a shared domain only if its type is capped by the hour, and a service caught out is retired with its history erased. A video call was nonetheless counted as image generation before the domain responsible was retired: that false positive is what made the cap get written.

Reading the context rests on two hypotheses with no measurement at the provider: the energy of a token read relative to a generated one comes from a regression on three published points, and the cost of a token re-read from cache from a measurement on prefixes of a few thousand tokens, far from an agentic context. Nothing on the wire says whether a token is re-read or recomputed: the cache share comes from a single machine's token counts. That last parameter alone moves the reading term by a factor of seven. And for every service without a measured upstream ratio — all but Claude Code to date — reading is not counted at all: those usages remain understated, and it is said rather than guessed.

What is never read

No content is read, no connection is decrypted, no certificate is installed. Detection works by address and by process name, never by hostname nor by inspecting traffic. No administrator rights, no network extension, no account, no telemetry — and nothing leaves the machine until sharing to the shared footprint has been turned on, which it is not by default.