The AI boom is transforming countless sectors, but hardly any as dramatically as software development. Tools such as Claude Code or Google’s Antigravity make it possible for individuals to develop programmes that would previously have required huge teams. As with the generation of images, music and videos, ‘vibe coding’ lowers the barrier to entry. In other words: anyone without coding skills can generate their own programmes or websites.
However, these new possibilities come at a price. As the coding assistants use generative AI, their development and operation come with massive environmental costs. We’ve already reported on the energy consumption, rising water demand and human costs of AI chatbots.
French developer Gaëtan Wittebolle has created a tool called “Claude Carbon” to calculate the CO2 emissions of his own use of Claude Code. We spoke to Gaëtan about exactly how it works, and how it has enabled him to reduce his own carbon footprint.
Gaëtan, how has Claude Code changed your working day? And what are the benefits of coding with generative AI?
It collapsed the time between idea and prototype. I run a carbon consulting practice, build a freelance community and ship SaaS products as a solo developer, which wouldn’t be possible without it.
The advantage isn’t typing speed. Typing was never the bottleneck. What changed is being able to test a product hypothesis in hours instead of weeks, before it has time to turn into technical and financial debt. One caveat I keep in mind: more code is not better code.
Why did you develop Claude Carbon?
I work as a carbon consultant for large companies and code every day with Claude Code. At some point these two parts of my life felt contradictory, and I needed a number rather than a feeling.
Existing CO2 trackers focus on web traffic or cloud workloads. None of them measured what an AI assistant actually consumes inside an IDE during a real coding session. So I built one, open source under MIT, with the emission factors readable in a 30-second JSON file.
And how does Claude work? Does Anthropic, the developer of Claude, provide the necessary energy consumption data?
Short answer: Anthropic doesn’t publish emissions data. No PUE for their data centres, no real-time grid intensity, no Scope 1/2/3 disclosure per model. So Claude Carbon derives everything from two ingredients.
First, token counts, which are factual. Claude Code writes every session to a JSONL transcript on local disk.
Second, emission factors from Jegham et al. 2025, a peer-reviewed paper measuring LLM inference on AWS. Sonnet was measured directly at 190 gCO2e per million input tokens and 1140 per million output. Opus and Haiku are extrapolated by parameter ratio. The math is trivial: (input × factor_in + output × factor_out) / 1_000_000 = grams CO2. No ML, no calibration, no black box.
One nuance worth flagging in the article: Jegham measured AWS infrastructure, not Anthropic’s actual hardware. The numbers are a defensible upper bound from published research, not a direct meter on Anthropic’s GPUs.
And how did you manage to reduce your emissions by almost 50 per cent afterwards?
Important caveat first: the 50-70% figure is a projection, not a post-implementation re-measurement. I measured my baseline (215 kg CO2e over 4 months, projecting to 0.9-1.5 tonnes/year), then identified four levers that stack to a 50-70% reduction if applied consistently. I’m still gathering enough data to confirm the actual post-optimisation figure. However, the four levers are: using the right model, limiting the ‘Advanced Thinking’ function, filtering prompts and contexts and compacting contexts earlier.
Four ways to reduce your Claude code emissions
Gaëtan has outlined four ways in which he was able to reduce the carbon footprint of Vibe-Coding using Claude Code:
- Right model per task. I was defaulting to Sonnet or Opus on tasks Haiku handles fine (file reads, exploration, reviews). Highest-impact lever I identified.
- Filter the context. I use RTK (Rust Token Killer), a CLI proxy that strips noise from shell outputs (
git log,find, test runners) before they reach the model. - Cap extended thinking. Claude’s extended thinking can burn 32k hidden tokens per turn. For routine work that’s wasted compute.
MAX_THINKING_TOKENS=10000cuts thinking ~70% without measurable quality loss. - Compact earlier. Default behavior compacts context at 95%.
CLAUDE_AUTOCOMPACT_PCT_keeps sessions lean.OVERRIDE=50
Stacked, those four project a 50-70% reduction, taking my annual footprint from ~1.2 tonnes CO2e down to 0.4-0.6 tonnes if applied consistently.
Max Westing told us in an interview that generative AI also has potential for energy-efficient code optimisation. What are your thoughts on that?
Westing’s actual position is more nuanced. His experiment showed AI agents could optimise simple code “in a way that worked”, but he also flags that there’s no comprehensive lifecycle analysis comparing human vs. AI code efficiency, and that AI systems themselves consume a great deal of energy.
He raises the rebound effect question explicitly: if developers gain efficiency from AI tools, does that offset the cost of training and running them?
My read is that for now, no. The narrow optimisation angle is real, but it gets drowned out by what happens around it.
GenAI coding lowers the cost of producing code, and when you lower the cost of something, you get more of it: this is a classic rebound effect.
With vibe coding, developers often generate code without reading it. They accept it without questioning it and enter new prompts instead of debugging the generated code. Every cycle consumes resources and produces code that is subsequently executed. This leads to an excessive generation of lines of code. In the process, functions are delivered that nobody asked for, dependencies are added that nobody checks, and abstractions are created for problems that do not yet exist.
If the output quality is poor, developers generate the code from scratch. I like to call these post-processing cycles, which lead to increased computational overhead. After all, every rejected and revised version must first be generated. And that is pure waste.
I’ll call the final factor ‘maintenance debt’. Statistically speaking, AI-generated code is more verbose, complex and disjointed. These lines of code then survive in products for years on end.
So yes, the function you explicitly ask Claude to optimise will be more efficient. But the project as a whole tends to be larger and more bloated than what a human would have shipped alone. The micro gain doesn’t offset the macro inflation.
The real lever, in my view, is using these tools to write less code, not more code faster. That conversation isn’t happening yet.
