Carbon Accounting for Software and AI

Carbon accounting software turns invisible digital activity into numbers you can manage. Every API call, database query, and model inference consumes electricity, and that electricity carries a carbon cost that most teams never see. Making it visible is the first step to reducing it.

This article explains the software carbon intensity idea, shows how to measure emissions at the level of a single request, and reviews the methods and tools available. AI is the fastest-growing part of many software footprints, so we give it particular attention.

The software carbon intensity concept

Software carbon intensity expresses emissions per unit of useful work rather than as one lump total. For a web service that might be grams of CO2 per thousand requests; for AI it might be grams per million tokens. Framing it this way lets you compare efficiency across features and track whether each unit of work is getting cleaner over time.

The appeal of intensity is that it separates growth from efficiency. Your total footprint can rise because you serve more users while your per-request intensity falls. Both facts are true and both matter, and a good carbon accounting approach keeps them distinct.

Measuring emissions per request

For AI specifically, the cleanest measurement point is the request itself. Each call has a token count, and tokens map to energy by model class: roughly 0.0008 Wh per token for small models, 0.0015 Wh for mid-sized, 0.0038 Wh for frontier, and 0.0040 Wh for reasoning models. Image generations sit around 2.0 to 3.5 Wh each.

From energy you reach carbon by applying a data center overhead factor near 1.56 and a grid emission factor such as 0.395 kg CO2 per kWh. Water follows using roughly 3.4 litres per kWh. The full chain is described in the guide on how to measure AI carbon emissions, and a carbon-tracked API can attach these figures to every call automatically.

Methods: measured, modeled, and market-based

There are three broad ways to account for software carbon. Measured accounting reads real energy or usage data, which is the most accurate but needs instrumentation. Modeled accounting estimates from activity data and published factors, which is practical when direct measurement is unavailable. Market-based accounting adjusts for renewable energy purchases tied to the workload.

Most teams blend these. You might model your AI footprint from token counts while using market-based factors where a provider runs on renewable energy. The important discipline is documenting which method applies where, so the totals stay auditable.

Tools that make it practical

Cloud providers now expose carbon dashboards for infrastructure, and open frameworks exist for estimating software emissions from utilisation data. For AI, the most useful tools measure at the request level and report energy, carbon, and water together rather than leaving you to reconstruct them later.

Ecoia takes this approach by measuring each request and going a step further, offsetting beyond 200% of the measured impact so the net result is carbon negative. You can see the mechanics in how it works and compare options in the roundup of best green AI tools for developers.

Putting it into practice

Start small. Pick one high-traffic feature, instrument its usage, and compute an intensity figure. Once you trust that number, extend the method to other services and set a baseline you can track quarter over quarter.

Pair measurement with action. Choosing efficient models, trimming wasted tokens, and scheduling heavy jobs for cleaner grid hours all lower real emissions. The practices in how to reduce your AI carbon footprint turn accounting from a reporting chore into an engineering habit.