Our Journey to Measuring our AI Usage Emissions

‍

”How should we account for emissions from our AI usage?” 

That’s an increasingly common question we’re hearing from customers. At CNaught, we're also using AI more every day, and as a Climate Label company, we measure and offset our own emissions. So we set out to measure our own AI footprint and share our experience.

‍

We are a relatively simple case: a small team, and we scoped this to focus on our largest provider by far, Anthropic's suite of Claude tools. While we knew going in that any figure would be a best estimate, since Anthropic and other providers don't publish emissions factors, we expected that the process itself would be relatively straightforward. What we didn't expect was how messy and incomplete the underlying usage data would turn out to be.

‍

Key Takeaways

‍

• The usage data required to do this accurately is incomplete. The usage data we can pull on our own AI activity is partial and lacks the granularity needed to draw accurate conclusions. More details would allow us to draw real insights about how to change our usage and optimize for sustainability.
• Providers need to disclose their environmental metrics. Even with granular usage data, we are missing the data we need - particularly energy consumption and data center routing - to accurately convert that usage into emissions.
• Our AI emissions account for about 2.5% of our total footprint, a relatively small proportion today. AI isn't currently a material driver of our emissions, and it's a number we can take responsibility for. However, as team members scale usage, this number can grow quickly and for large organizations, this usage can scale rapidly.

Our AI-Usage Emissions

Our total organizational emissions in 2025 came to 111 tonnes of CO₂e. We estimate that our AI usage accounts for approximately 2.8t* a year (annualized), or about 2.5% of our total footprint.

‍

For a high-level look at our team’s numbers:

‍

‍

While Product and Engineering teams currently account for the largest share of our AI emissions, as new tools like Claude Cowork make coding workflows accessible to teams beyond developers, usage in non-technical departments is rising and will continue driving emissions up. And that share can scale quickly: if every employee used AI as heavily as our single biggest user does today, our AI emissions would nearly 4x to roughly 9% of our total footprint.

Our Process

Our plan was relatively simple: 

‍

1. Download our usage data from Claude for all products
2. Apply our emissions methodology (see full methodology for a detailed breakdown)

‍

However, we quickly realized that it wouldn't be that easy.

‍

When we first downloaded our data, it was largely incomplete, with multiple team members missing from the export entirely. By May, the picture improved: Anthropic updated their exports and we were able to pull cumulative monthly usage across tools, models, and individual team members.

‍

Yet, we still ran into several data limitations:

‍

• Usage is designed to break down by month. There is an ability to export a single day, but it’s manual and tedious. There's no hourly or daily granularity, so any analysis of when usage spikes, or how it maps to specific projects, is off the table.
• We can only download the trailing 90 days of data. Building a longer baseline or tracking year-over-year trends is impossible without manually exporting every month.
• There's no location information for where the compute actually ran, which we could use to factor in the carbon emissions of specific power grids. 

Challenges

The data limits were the first obstacle, but we also ran across a few others throughout the process: 

‍

• Model-specific energy consumption is a black box. Providers don't publish how much energy a given model consumes per query or per token, which means we can't simply look up a factor and multiply. To get to our number, we had to lean on assumptions and apply the Jegham et al. methodology, currently the best available public framework for estimating LLM inference energy. It's a reasonable approach, but it's an estimate built on external modeling, not on data from the provider itself.
• Aggregated data means that we can't dig in and ask questions that would actually help us improve, like which workflows are the most energy-intensive, or whether usage clusters in ways we could optimize.
• AI usage that’s baked into other software doesn't get counted at all. Our estimate covers our direct Claude usage. It does not capture the growing list of software tools that now embed AI features under the hood, the assistants, summarizers, and copilots layered into platforms we use every day. While that number is small right now, it could compound over time and it's effectively invisible to anyone trying to account for it and we wanted to point that out.

What Providers Need to Release

We're calling on providers to be more transparent about their products, so that companies can take responsibility for their emissions. For providers taking these concerns seriously, here's what would actually help companies do this work responsibly:

‍

• Time-based usage data (at hourly or daily resolution): Monthly summaries can’t tell you when compute happened, which means they can’t be matched to how clean the grid was at the time. This will only grow more important as the GHG Protocol considers a shift to hourly matching for Scope 2 accounting.
• Grid routing & location data: Without knowing where the compute ran, every emissions estimate has to assume an average that may be far from the actual number, based on where the queries are processed. This data doesn’t need to be precise data center locations - just precise enough to match grid intensity maps.
• Model specific energy consumption information: This is the single biggest gap - if providers disclose their energy per query or per token by model, customers could replace assumptions with actual factors. Model providers already release model cards with AI performance benchmarks. They should include energy efficiency alongside these metrics.

What You Can Do Today

The encouraging news is that even with these limitations, we arrived at a reasonable estimate using the information available. And some companies are starting to publish the data that makes this work possible: Salesforce has begun adding environmental metrics to its AI model cards. Hugging Face's AI Energy Score Leaderboard rates models on energy efficiency, giving teams an independent way to compare options before they deploy. Newer services like GreenPT are building sustainability considerations into AI usage from the start. Our team released Carbonlog to help you track emissions from your Claude Code usage, and we’ll keep refining our methodology as more data becomes available. If you’re thinking through how to do this at your own company, our team can help you get started. 

‍

Our single most practical recommendation: Start now, and download your organization-wide AI usage data every month. Given the three-month download limit, capturing it as you go is the only way to build a usable history. As providers hopefully make this data more granular and comprehensive, you'll be ready to turn it into genuinely informed decisions about your usage. The sooner you understand your emissions, the sooner you can start to minimize them, and maybe bring costs down at the same time.

‍

Keep an eye out for our next post, where we'll dig into how to use AI tools more sustainably, and what becomes possible once we have more of the information we've been asking for. If you have feedback on our approach or questions about how we can help your organization do the same, reach out to us here.

‍

*2.8t is 0.7t for a single quarter annualized at a 0% growth rate, likely a highly conservative estimate given that AI usage is expected to continue to rise across the organization.