Understand
The questions that keep coming up about the estimate, privacy, and what the figures are worth. Every answer stands on its own.
A 500-token answer — about 350 words — costs roughly 1.2 Wh of electricity under the CarboneWatch model, data-centre overhead included. That is 0.461 gCO₂e if the service computes in the United States, 0.049 g if it computes in France, 0.63 g in China: the gap comes from the electricity grid, not from the model. For comparison, one kilometre in a petrol car emits about 120.
Not necessarily, and CarboneWatch does not settle it: it counts both separately. A local model is billed on inference time, at the power drawn — using the carbon intensity of your own grid. A laptop is far less efficient per token than a data-centre accelerator serving dozens of requests in parallel; on the other hand it may run on cleaner power, and there is no network trip. Both totals are shown side by side, with no winner declared.
No. No content is read, no connection is decrypted, no certificate is installed. The application observes the volume of bytes per connection and the remote address, which it compares with the addresses of known services — never the hostname, never the payload. It requires no administrator rights, no network extension, no account.
Nothing leaves the machine until sharing to the shared footprint has been turned on, and it is off by default. Once on, what is sent is, per hour and per service: estimated energy, CO₂e, estimated tokens, service type, electricity grid code and application version. Never sent: IP address, machine name, process names, visited addresses, content. The installation identifier derives from a secret drawn at random on the machine and changes every month. The application displays these identifiers: erasure is requested in writing to clement@nucom.fr, quoting them.
Because Google serves its AI from the same addresses as Drive, Gmail and Cloud Storage: detecting them would amount to billing a photo backup as inference. The entry was removed after measurement. The shared footprint therefore undercounts, by an amount nobody can quantify — which is stated on the page about absent services.
Because they do not measure the same thing. CarboneWatch counts the electricity of inference and, since 0.2.14, the manufacturing of the server producing it — a bounded assumption. A full life-cycle analysis, such as the one published by Mistral with Carbone 4 and the French ADEME, adds amortised training and the rest of the infrastructure. Two figures are comparable only if they share the same scope.
Image, audio and video generation is not counted in tokens: what arrives is the media itself, and the volume received is the basis. A 2 MB image costs on the order of 1.84 gCO₂e on an American service. The rate cap that bounds text does not apply here — the media is the payload, and a generation arrives in one burst. A volume bound does exist since 0.2.20: beyond one hundred megabytes per hour per service, the bytes are still recorded but stop being billed. It targets the false positive that lasts, a video call for instance, without crushing a generation.
Far more, and this is no small matter: a ten-second high-definition clip weighs about 5.7 MB and comes to some 549 gCO₂e on an American service, on the order of 298 times the image above. The reason is physical — a video is denoised frame by frame, hundreds of times over, where an image is denoised once through. Video services with a published estimate are therefore billed at their own rate rather than the general media rate; those with nothing published stay on the common rate, and are underestimated. The site does not hide this gap: it is the main remaining imprecision on this kind of service.
Because it is all a workstation can observe, and it is a weakness we would rather state. Two clips generated the same day by the same service, of the same length and definition, can weigh twice as much one as the other depending on the encoding bitrate chosen — for a comparable generation energy. Counting generations rather than bytes would be fairer; that requires seeing the full address of each request, which only a browser allows. The extension sees that address, but it still counts bytes, like the application.
No, and it is written all over this site: it is an estimator, not a meter. The real energy of an inference is known only to the provider. CarboneWatch starts from the volume of bytes exchanged, derives a number of tokens produced — and read, where the ratio is measured —, applies a rate per service type and a carbon intensity per region. Each of those steps is an order of magnitude, and the ratio between bytes and tokens is the most uncertain.
On Linux, yes, just as on macOS: the volume exchanged is read per connection, with no special rights. On Windows, the system exposes that volume to no application without administrator rights; the estimate there falls back on established connection time, which makes an idle open tab weigh. Figures are upper bounds, the application says so, and the shared footprint counts them separately.
The application is free, with no account, no advertising and no telemetry. It resells nothing because it collects nothing: by default, no data leaves the machine. The only possible upload is sharing to the shared footprint — voluntary, revocable, and carrying nothing that identifies the machine or the person.
