This IDE Plugin Shows the Energy Cost of Your AI Prompts

That question led Nayan Jain, Executive Director of AI at ustwo, to start looking for tools that could help developers see the environmental cost of their AI usage while they worked.

Having found no real tools for this, ustwo and the University of Bristol built one: PRISM. It launched last week, and we sat down with Nayan to talk about how it works and what it aims to change.

PRISM uses AI token activity to estimate energy use and emissions

The tools that were available mostly focused on data centers or broad “big picture” ideas, but none catered to the developers actually using AI tools.

That gap led Nayan to think about ways to connect AI usage to real-world energy:

I quickly ran into a challenge that still exists today: a lack of transparent data from model providers. Without reliable information on energy consumption and infrastructure, it is difficult to build and validate a model with confidence.

Working around that, he decided to rely on tokens, a visible and relatively accurate measure of AI spend.

The idea was to use token activity as a proxy for compute demand and estimate energy use and emissions using published research and carbon accounting principles, including the Green Software Foundation’s Software Carbon Intensity framework.

He brought the idea to ustwo Tech Director Nick Hegarty, who helped narrow the focus: could they help developers understand the environmental impact of their AI use while they worked? That made the project possible.

From idea to IDE

The answer was to create an in-editor tool, where the developer could see an estimation of their token costs and impact on energy consumption in real time.

The theory here is that, with this data, engineers can see their habits and perhaps be more conscious about their usage:

Our theory is that making this visible can guide engineers into more mindful habits around their AI consumption in the moment. Because AI providers don’t publish complete energy or emissions data, PRISM acts as a proxy for energy consumption by surfacing an estimate rather than an exact measurement.

PRISM directly monitors token usage, the model being used, and the provider. For other tools, like GitHub Copilot, PRISM reads local activity logs. AI requests made by an application at runtime are captured through a local interceptor.

The app then combines input and output tokens into an estimate. Nayan notes that these will be separated “as soon as robust factors exist”.

How red was that prompt?

In practice, PRISM is more of a subtle indicator than a big flashing number that appears after every call. Nayan explained how it feels to use it:

In the editor, a status indicator reflects your most recent call, colour coded. The headline feature is Relative Impact Classification, where each interaction is rated Green, Amber, or Red based on where it sits compared with the other requests in the same project.

Nayan continued to explain the colors:

Green is below the median, Amber sits between the 50th and 90th percentile, and Red is the top tenth. A few requests need to accumulate before the colours become meaningful, because the whole point is comparison within your own project rather than against an arbitrary threshold.

Clicking around the dashboard more, users can get information broken down by model usage, as well as other interesting metrics:

• Timeline of estimated carbon over the course of development
• Heatmap that shades from green through amber to red
• Breakdowns by branch and other visualisations.

However, Nayan explains that a relative, percentile-based design was chosen due to the inability of estimates to present absolute carbon figures. The goal of the tool is to explain and raise awareness more, and hopefully educate engineers on how their usage looks like from the eco standpoint.

The impact is awareness, not less AI use

Ustwo has tested PRISM with UOB students and across the company’s engineering team, and the results have been positive so far:

Several users said that seeing estimated emissions made them more deliberate with AI tools.

Nayan added that engineers, having seen the data for their usage, tried to make adjustments to their style and became a bit more conscious of how they refine requests.

Some wrote shorter, more precise prompts instead of using multiple iterations, and others paid closer attention to model selection after seeing how much environmental impact different models could have for similar tasks.

But as Nayan said, what interested them the most wasn’t that developers used AI less, but that they became more aware of how they were using it. “Once the data was visible, users started noticing things they hadn’t considered before.”

PRISM won’t solve AI’s environmental impact, but it makes it more visible

Right now, PRISM can provide data and insights for cloud and assistant-based models by identifying them, capturing token usage, and calculating the energy factor from a list of supported models. Locally run models are not yet supported, but might be in the future.

As the tool grows, ustwo sees its ideal outcome at three levels.

For engineers, the goal is awareness: giving users more information about their environmental impact during their work. Nayan says this is not about telling people what to do, but showing them a fuller picture of the tools they’re using. For organisations, the goal is to create a shared picture and open up more conversations about sustainability, governance, and responsible AI.

Beyond those, ustwo is positive about the potential of collaboration in the field of environmental impact of AI. He concluded:

PRISM won’t solve the environmental impact of AI on its own, but if it helps make that impact a little more visible, and sparks better conversations and behaviours as a result, then we’ve achieved something worthwhile.