DEV Community: gwittebolle

How much CO2 does a Claude Code session actually emit?

gwittebolle — Mon, 20 Jul 2026 07:17:52 +0000

I spend most of my working day inside Claude Code. At some point I started
wondering what that adds up to, physically. I just wanted a number next to
the session cost, something to glance at rather than feel bad about.

There is no official answer. Anthropic, like every frontier lab, does not
publish per-inference energy data. So I built the estimate myself, put it in
my status line, and open-sourced the whole thing as
claude-carbon. This post is
the methodology: where the numbers come from, what I had to estimate, and
where the estimate is weakest.

My own six months, measured by the tool: 893 sessions, roughly 970 kg CO2e.
About one economy seat on a one-way transatlantic flight. The median session
is ~200 g, the distribution has a long tail, and my worst single session was
68 kg. I would not have guessed any of those numbers within a factor of five.

The only measured data point

Everything starts from one paper: Jegham et al. 2025, "How Hungry is AI?"
(arxiv.org/abs/2505.09598). It measures
per-query inference energy for a range of models on AWS. For Claude 3.7
Sonnet it reports three configurations (PUE included):

Input tokens	Output tokens	Energy
100	300	0.950 Wh
1,000	1,000	2.989 Wh
10,000	1,500	5.671 Wh

Three points, two unknowns. Fit an ordinary least-squares regression through
the origin, with one coefficient for input tokens and one for output tokens,
and you get ~1.35e-4 Wh per input token and ~2.88e-3 Wh per output token.
The fit matches the two high-token configurations within 1%, which is the
regime real coding sessions live in.

Convert with the grid: Jegham et al. use the AWS region carbon intensity,
0.287 kgCO2e/kWh, location-based. That yields the two numbers everything
else hangs on:

39 gCO2e per million input tokens
826 gCO2e per million output tokens

The 21:1 ratio falls out of the fit rather than being assumed, though three
measured points give it real uncertainty. The direction, however, is solid.
FLOPs per token are similar in prefill and decode; what differs is hardware
utilization. Prefill processes
the whole prompt in parallel and saturates compute; each decode step
re-reads the weights and KV cache to produce a single token, so it is
memory-bandwidth-bound and burns more energy per token. The exact multiple
depends on batch size and serving stack.

Could this be wrong? I cross-checked against
EcoLogits, which estimates impact by a completely
independent route (parameter counts plus a lifecycle model, no AWS
telemetry). Their Sonnet band is ~565-1385 gCO2e per million output tokens.
826 sits inside it. Two unrelated methods landing in the same range is the
strongest corroboration available today.

Three model families are extrapolated, and here is how fragile that is

Only Sonnet has measured energy data. Everything else is inference from
weak signals, so let me rank the numbers by how much I trust them:

Sonnet: measured. Three points and a fit. The solid ground.
Opus: extrapolated, band 1.7x-5x Sonnet. The two available signals, EcoLogits' parameter assumptions and Anthropic's price ratio, both land around 1.7-2x, and that is where the tool sits (2x). The band stretches to 5x because neither signal is a measurement, so the likely error is upward.
Haiku: the most uncomfortable one. Jegham actually measured Haiku 3.5 higher than Sonnet, which is usually read as a serving artifact (latency-optimized serving, small batches). EcoLogits' modern Haiku reads far lower. The tool uses 0.5x Sonnet. If you instead take the measurement at face value, Haiku lands near Sonnet and most of the "route small tasks to small models" gain evaporates. I chose the reading the physics supports, but you should know the other one exists.
Fable: the least reliable number in the tool. No measurement, no parameter estimate, only the list-price ratio (2x Opus), and price is a poor proxy for energy: providers price on what the market bears, and electricity is a small slice of it.

Why publish point values at all when the bands are this wide? Because a
status line needs one number. The mitigation is structural: the tool stores
raw token counts and derives the grams from them, so the day better data
lands, one script re-prices the entire history.

These are order-of-magnitude estimates and the repo labels them as such. If
you want a tool that pretends to three significant digits, this is not it.

The cache is the hard part

Nobody tells you this before you parse your own transcripts:
87% of my tokens are cache reads. Claude Code re-sends the conversation
prefix on every turn, and prompt caching means those tokens skip prefill
compute. So the factor you assign to a cached token dominates the headline
number more than any per-model factor does.

The tempting shortcut is Anthropic's billing ratio: cache reads cost 0.1x
input. But a price is not an energy measurement (OpenAI prices the identical
mechanism at 0.5x). The honest answer is that no study measures this ratio
directly, so I derived an engineering estimate from adjacent measurements:
prefill accounts for under ~3.4% of total inference energy in generation
workloads, and decode energy per token grows with KV-cache size because
every generated token re-reads the entire cache from HBM. Cached tokens
skip prefill but still pay that decode-phase residual forever.

I use 0.08x with a documented defensible range of 0.05-0.15. It is a
single configurable constant, and it is the biggest lever in the whole
model. Setting it to 0 is a legitimate lower bound, but it declares a reused
100K-token system prompt carbon-free, which a memory bus somewhere would
dispute.

Counting tokens is its own bug hunt

Token counts come from Claude Code's local JSONL transcripts. If you naively
sum message.usage over the lines, you over-count by roughly 3x. Resumed
and compacted sessions replay earlier messages into the same file, and
streaming rewrites the same message id with a growing output count. On my
data, 55% of assistant lines are replays. Deduplicate by
(message.id, requestId), keep the last occurrence, then sum.

One more trap: Claude Code purges transcripts after about 30 days. The tool
captures each session into SQLite when it ends, raw token breakdown
included, so when a factor is revised the entire
history can be re-priced with one script. Emission factors will keep
changing as measurements improve; raw tokens are forever.

Numbers you can't silently break

Every factor and price in the repo is covered by golden vectors: 12
canonical sessions with hand-derived expected outputs, replayed against
data/factors.json in CI on every push. If someone (usually me) tweaks a
factor without updating the vectors and the written derivation in
METHODOLOGY.md, the build fails.

I added this after catching myself unable to reproduce my own earlier
numbers. Fact-checking the arithmetic ten times had not caught it, because
the arithmetic was fine; the derivation had drifted. If your project ships
numbers, put the derivation itself under test.

What it looks like day to day

The status line shows grams next to dollars, live:

claude-carbon ⌥ main | 🟢 Opus 4.7 ▓▓▓░░░░░░░ 35% | $1.72 · 101g CO₂ | Use 21% ↻13:00

The change in my behavior is model routing (my usage certainly did not go
down): the family factors put small models several times below the big ones. I
won't quote a precise ratio, because the inter-family ratios are the
weakest numbers in the model (they are the extrapolations described above).
The direction is robust though, and a visible number at
decision time makes "does this task need the big model?" a real question,
the same way the cost display already does.

Honest limitations

Inference only: no training amortization, no hardware manufacturing, no
water. The carbon intensity is a static grid average for a single region.
The cache-read factor is an engineering derivation with a documented
range. The right way to read any
session figure is "hundreds of grams, not tens of milligrams and not tens of
kilograms."

If you use Claude Code, the install is one line and everything stays local
(SQLite, no telemetry, no account):

npx claude-carbon

Repo and full methodology, sources included:
github.com/gwittebolle/claude-carbon.
If you find a flaw in the derivation, open an issue. The golden vectors make
corrections cheap, and being corrected with sources is the point of
publishing the method.

How I Measured 1 Tonne of CO2 from My AI Coding Sessions

gwittebolle — Tue, 07 Apr 2026 10:04:47 +0000

I work as a carbon consultant for large companies. I also code every day with Claude Code. At some point, these two parts of my life started to feel contradictory, and I needed a number.

So I built claude-carbon - a bash + SQLite tool that hooks into Claude Code's session lifecycle and estimates CO2 emissions per session, live in the status line.

Here's what 4 months of data looks like.

The numbers

367 sessions analyzed
215 kg CO2e measured over 4 months
Projection: 0.9 to 1.5 tonnes/year (roughly a one-way Paris-New York flight)
For context: the average French person emits around 9 tonnes/year total

These numbers cover inference only - the energy consumed when the model processes my prompts and generates responses. Training, hardware manufacturing, cooling, and datacenter construction are not included. The real lifecycle footprint is higher.

Inference alone adds about 10% to my individual carbon budget. Just from coding sessions.

How it works

The tool hooks into Claude Code's Stop event. When a session ends, Claude Code writes a JSONL transcript to ~/.claude/projects/. The hook reads that file, counts tokens by model, applies emission factors, and persists the result to a local SQLite database.

The core formula:

session_co2_g = (input_tokens * input_factor + output_tokens * output_factor) / 1_000_000

The status line shows the running total live:

🟢 Sonnet 4.6 ░░░░ 12% | $1.80 | 38g CO₂ | my-project

Zero npm, zero Python, zero cloud. Just jq and sqlite3, both pre-installed on macOS.

Emission factors

The methodology comes from Jegham et al. 2025 (arxiv 2505.09598), a peer-reviewed study measuring inference energy on AWS infrastructure.

Factors (gCO2e/Mtok):

Opus: input 500, output 3000 (extrapolated 3x Sonnet)
Sonnet: input 190, output 1140 (measured)
Haiku: input 95, output 570 (extrapolated 0.5x Sonnet)

Infrastructure: AWS PUE 1.14, grid average 0.287 kgCO2e/kWh.

Output tokens cost ~6x more than input tokens. During prefill, the model processes all input tokens in parallel. During decoding, each output token requires a full sequential forward pass. That asymmetry is why long verbose responses are expensive.

What this is not

These numbers are estimates, not measurements. Several things make them imprecise:

Anthropic publishes no per-model energy data. Sonnet factors come from the Jegham paper's direct measurements. Opus and Haiku are extrapolated by scaling (3x and 0.5x Sonnet). Actual values depend on hardware configuration and batching strategies we don't have access to.

Prompt cache hits are overestimated. Cache reads consume less energy than fresh compute. The tool counts them at full rate, so numbers skew high.

Static grid average. The carbon intensity factor is a US grid average. It varies by region, datacenter, and time of day. Anthropic's actual energy mix is unknown.

Inference only. Training costs, hardware manufacturing, and cooling water are not included. The true lifecycle number is higher.

Treat these as order-of-magnitude estimates. They're good enough to identify patterns and test reduction levers. They're not suitable for regulatory reporting.

Architecture

Install:

git clone https://github.com/gwittebolle/claude-carbon.git ~/code/claude-carbon
bash ~/code/claude-carbon/scripts/setup.sh

Setup creates the SQLite database, backfills all existing ~/.claude transcripts, and prints your total. Then you add two entries to ~/.claude/settings.json: one for the status line, one for the Stop hook.

The backfill script parses historical JSONL transcripts by walking ~/.claude/projects/. Each transcript contains the full token counts per message, including model name. That's how I got 4 months of data retroactively.

Reducing your footprint

Measuring revealed which levers actually matter.

Right model for the task is the highest-impact lever. Opus costs 3x more per token than Sonnet. Using Haiku for subagents (file exploration, grep, code review) instead of Sonnet cuts those tasks by 80%.

RTK (Rust Token Killer) filters verbose CLI output before it hits the context window. Progress bars, passing test logs, verbose build output - all stripped. 60-90% token reduction on CLI commands, no quality loss.

Cap thinking tokens. Extended thinking can use up to 32k hidden tokens per message. Capping at 10k cuts thinking token usage by ~70% on routine tasks.

Compact earlier. Default autocompact triggers at 95% context usage. Setting it to 50% keeps sessions leaner.

Combined, these reduce total emissions by 50-70%. My projection goes from ~1.2 tonnes/year down to 0.4-0.6 tonnes if I apply all of them consistently.

Why I built this instead of just estimating

Two reasons.

First, the number in your head is always wrong. Before measuring, I assumed my usage was around 50-100 kg/year. It was double that. The discrepancy came from a few long architecture sessions I'd forgotten about, and from not accounting for how expensive Opus is.

Second, I work in carbon. I help large organizations build their emissions inventories. The methodology challenge here - uncertain emission factors, no primary data from the provider, static grid averages - is exactly what we deal with at scale. Working through it on a small personal dataset was useful practice.

What I'd like from Anthropic

One thing would make this significantly better: actual per-model energy data from Anthropic. Right now the Opus and Haiku factors are extrapolations. A single published figure - even a range - would let developers build more accurate tools.

Amazon, Google, and Microsoft publish at least some data center energy metrics. Anthropic publishes none. That's a gap worth closing.