CarbonWatch
CarbonWatch estimates the energy and carbon footprint of AI service usage from the volume of bytes received, without reading a single byte of content and without administrator rights. Here is the whole calculation, its factors, and what it does not say.
Two estimators, each grounded in its own physics
Remote services — by volume received. 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.
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 is 0.75 Wh per minute, about 45 W of machine under load.
Two guardrails frame the volume
Rate cap. A model does not produce faster than ~120 tokens per second, or about 3,000 bytes per second of stream. Billable bytes are capped at that rate, 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 200 bytes per service per sample, the traffic is protocol: keep-alive frames, TLS pings, session renewals. Without that floor, an open application would bill continuously.
From volume to carbon, in three conversions
Each step has its factor, and every factor is adjustable in the application. Here is the full chain on one example.
- Bytes received → tokens: divide by 25 bytes per token.
- Tokens → energy: multiply by the rate for the service type, in watt-hours per thousand tokens.
- Energy → CO₂e: multiply by the carbon intensity of the electricity grid in the region where the service computes, in grams per kilowatt-hour.
The example used everywhere on this site
A 500-token answer — about 350 words — on a chat service. On the wire: 12,500 bytes received. Divided by 25, that is 500 tokens, half a thousand; at 2 Wh per thousand, 1 Wh. That watt-hour becomes 0.38 gCO₂e on a service hosted in the United States, and 0.05 g on one hosted in France. Same model, same exchange, and a factor of eight between them.
The energy rate, by service type
EcoLogits-style orders of magnitude, for a large model served at scale. Coding costs more than chat: answers are longer and models bigger.
| Type | The energy rate, by service type |
|---|---|
| Chat | 2 Wh per thousand tokens |
| Coding | 3 Wh per thousand tokens |
| Search | 2.5 Wh per thousand tokens |
| Image, audio, video | 2 Wh per megabyte received |
| Local models | 0.75 Wh per minute |
Carbon intensity, by electricity grid
Location-based values — the real grid mix of the area — not market-based, which nets off the renewable certificates bought by the operator. The first is the only one that stays comparable between providers: nobody can lower their number by buying paper.
| Electricity grid | Code | Intensity |
|---|---|---|
| Switzerland | CH | 40 gCO₂e/kWh |
| France | FR | 50 gCO₂e/kWh |
| European Union | EU | 250 gCO₂e/kWh |
| United States | US | 380 gCO₂e/kWh |
| World | WORLD | 480 gCO₂e/kWh |
| China | CN | 580 gCO₂e/kWh |
| Missing or unknown region | — | 480 gCO₂e/kWh |
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 380 gCO₂e/kWh and not 50.
Every service therefore carries a region in the registry. A missing or unknown region is billed at the world rate, 480 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: operational only
The electricity of inference, and nothing else: not the manufacturing of the servers, not the training amortised over requests, not the transport network, not end of life.
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 are comparable only to other operational figures.
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. 25 bytes per token holds for a stream that wraps each token in a JSON frame; a different encapsulation would give a different number, and the registry allows correcting it service by service.
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 global total counts them separately.
Two installations may estimate the same usage differently: every factor is adjustable. These are orders of magnitude, not measurements — an estimator, not a meter.
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 global total has been turned on, which it is not by default.