AI is now part of everyday software development. Developers use large language models to write code, debug, explore ideas, and ship AI-powered features. What’s still missing is a view of the emissions tied to that usage.
At the same time, scrutiny is rising. Energy, water, and carbon impacts are under the lens from regulators and teams inside tech. Organisations are being asked to understand — and report on — the footprint of the tools they adopt. Measurement is still messy because providers disclose different data, systems vary by model and infrastructure, and the energy mix changes by location.
At the end of 2025, we started where we had a signal. In collaboration with the University of Bristol, we built PRISM, a prototype that estimates development-time operational emissions from AI use.
Where this started
This project began with a simple exercise. As part of our sustainability work, we were calculating the carbon footprint of one of our AI-powered products, and when we ran the numbers, the result was hard to ignore. The emissions associated with AI were far higher than we had anticipated, accounting for more than 99% of the product's total footprint. By comparison, AWS infrastructure and network activity contributed only a tiny fraction. In addition, the same activities driving those emissions were also increasing compute demand and infrastructure costs. Neither of these insights was entirely new and organisations across the industry are starting to see the same patterns emerge. Yet something still felt missing:
Developers are used to working with feedback loops. Performance, latency, memory, and spend are visible and therefore optimisable. With AI, much of the work happens out of sight and the environmental impact disappears with it.
Turning a question into a tool
Working with our Tech Director Nick Hegarty and AI Director Nayan Jain, we developed a brief built around an idea:
We were curious about both the technology, and the human side of it too, particularly how people interact with AI when they understand its impact. Does making that impact visible change the choices they make? And could it encourage teams to build AI products in a more thoughtful way?
From early on, we also decided the work should be open source. If we are serious about understanding the environmental impact of AI, we need more people comparing methods and improving what good looks like.
When the University of Bristol took on the brief for an academic term, five students took on the build. We knew we wanted to explore whether token usage could be translated into carbon estimates and surfaced in the development environment. They challenged assumptions and tested different approaches when building the prototype itself before passing it back to us. We’ve been refining it while keeping the methodology and limitations open to scrutiny.
PRISM is still an early prototype. The methodology and limitations are all available to explore in the repository, alongside the underlying approach and implementation work.
Starting with what we can estimate
PRISM tracks AI usage during development and translates token activity into estimated energy consumption and carbon emissions using a token-to-energy-to-carbon approach.
When an AI request is made, PRISM captures the model used and the number of tokens processed, then applies model-specific conversion factors to estimate the associated environmental impact. The methodology draws on Green Software Foundation principles and recent academic research, including How Hungry is AI? (tool here).
It is important to be clear about what PRISM is and is not. It is not an exact meter, and it does not claim precision that the underlying data cannot support. Providers share different levels of information, models run on different infrastructure, and the carbon intensity of electricity varies by place and time. PRISM aims to provide transparent estimates based on the best information currently available, with assumptions that can be inspected and improved. Even when imperfect, that signal is useful because it lets teams weigh environmental impact alongside things like cost and performance.
From measurement to awareness
One of PRISM’s core features is Relative Impact Classification. Rather than relying on fixed carbon thresholds, PRISM compares requests against other AI interactions recorded within the same project and assigns a simple visual indicator.
| Classification | Percentile Range | Description |
|---|---|---|
| Green | Below the 50th percentile | Lower relative impact |
| Amber | Between the 50th and 90th percentile | Moderate relative impact |
| Red | Above the 90th percentile | Higher relative impact |
The intent is to help developers spot unusually resource-intensive interactions and understand how usage patterns change over time, without turning it into a morality badge. A lower-impact marker does not mean good, and a higher-impact marker does not mean bad. It simply makes differences visible, so teams can ask better questions with context.
Why visibility matters
In engineering, visibility drives optimisation.
We have seen this before. Energy use in buildings fell once smart meters gave people insight into their consumption. Driving habits changed when fuel efficiency became easier to track. Even data centres became more efficient once metrics like PUE were measured and monitored.
AI tools are designed to remove friction. They make it easy to generate and iterate. Due to its speed, it’s easier to act without reflecting on what sits behind each interaction. By surfacing impact in real time, the plug-in adds another layer of information (and quality?) into the development workflow. Over time, that can shape behaviour by making different choices easier to see.
We are only at the beginning
Trying to solve everything at once usually leads nowhere, so we’ve started small and built from there. Development-time operational emissions are one part of the picture. Beyond that sit production emissions associated with inference and infrastructure, and then the wider system-level outcomes that emerge when AI changes behaviour at scale. Trying to tackle everything at once is a good way to get stuck, so we started where we had the most visibility and control.
Our hope is that making impact visible at the development stage becomes a foundation for better understanding further down the chain. It won’t stop with developers either – designers, product teams, and researchers would benefit from a plug-in such as PRISM as well.
Today, teams optimise for speed, cost, and performance because those are the signals they see. If carbon becomes visible alongside them, even imperfectly, it adds another dimension of quality to the conversation. Visibility is the first step, and better judgement is what comes next.
You can access PRISM here.
If you work in AI, sustainability, developer tooling, or green software, we'd love your feedback, especially the critical kind. Get in touch at prism-feedback@ustwo.com.