Measuring software carbon intensity for AI

Cloud and AI have become the default way to build, and the big providers have all made public carbon commitments. Reading those commitments, I kept asking a product question: if I ship an AI feature, how would I know what it costs the climate per use?

The closest thing to an answer I found is the Software Carbon Intensity (SCI) specification from the Green Software Foundation, since adopted as ISO/IEC 21031. It is a rate, not a total, which is what makes it useful to a product manager.

The formula, in plain words

SCI = ((E × I) + M) per R.

• E is the energy the software uses, in kWh.
• I is the carbon intensity of the grid that energy came from, in gCO2e per kWh.
• M is the embodied emissions of the hardware, the share of manufacturing a server or GPU that this workload "uses up".
• R is the functional unit: per API call, per user, per query, per document processed.

The functional unit is the part that matters most for product work. It is the same idea an LCA uses, and it is where product judgment comes in. Choosing "per successful answer" instead of "per request" changes what the team optimizes.

Why a rate changes behaviour

A total footprint goes up whenever a product grows, which makes it hard to tell good work from bad. A rate tells you whether each unit of value got cheaper for the planet. That is a metric you can put next to latency and cost per request.

Product strategies that move the number

• Choose cloud regions with cleaner grids for workloads that are not latency sensitive. Tools like Electricity Maps show live grid intensity.
• Shift flexible jobs such as batch inference, retraining and reports to cleaner hours with the Carbon Aware SDK.
• Right-size models. A smaller or distilled model that meets the quality bar is usually the biggest single lever.
• Cache aggressively and avoid regenerating the same answer.
• Extend hardware life where you control it, since embodied emissions are spread over useful years.

For measurement, Cloud Carbon Footprint and CodeCarbon are honest starting points, and Boavizta publishes open data on hardware's embodied impact.

If you cannot name the functional unit, you are not ready to measure the footprint.

This was one of the first pieces I wrote while learning. It set up most of what came later: the infrastructure iceberg behind AI agents and the case for carbon as a product metric.