How Headroom makes AI coding more sustainable

How much energy does an AI coding agent use?

No AI lab publishes energy per token for its API, so every figure here is an estimate. The most-cited starting point is Epoch AI's analysis, which puts a typical GPT-4o chat query at about 0.3 Wh and a query with 100k input tokens at almost 40 Wh. Long inputs dominate because processing the prompt (prefill) grows with context length, and attention grows faster than linearly. Google's measured figure for Gemini, 0.24 Wh for the median text prompt, is in the same range for short prompts.

Coding agents are the long-input case. Every turn resends the conversation, including file reads, test logs, and search results from earlier turns. Simon P. Couch applied Epoch's numbers to his own Claude Code logs, splitting energy between token types by Anthropic's price ratios. He estimated about 41 Wh for his median session and about 1,300 Wh for his median working day, roughly an extra dishwasher run. Google's own figure for a web search is 0.3 Wh, so that session equals 137 searches; the figure dates from 2009, and newer estimates of search energy are lower, which would make the ratio larger. Couch's per-token rates for the long-context case are the ones used below:

The cache-read rate matters because most of an agent's input is cache reads: the stable prefix of the conversation, billed at 10% of the base input rate. They're cheap per token but repeated on every turn, so a large prefix read hundreds of times adds up.

How much energy Headroom saves

Headroom is a local proxy that compresses tool output, logs, and other repetitive context before a request leaves the machine. From Monday September 14 through Sunday September 20, 2026, 502 users had it remove 4,758,193,735 input tokens from their Claude Code and Codex requests. That's the same "tokens saved" count the app shows, summed across users from their daily reports.

A removed token saves energy twice: it is never prefilled on the turn it would have appeared, and it's absent from the cached prefix on every later turn. Headroom counts removals per request, so the weekly count mixes first appearances (worth the input rate) with replayed turns (worth the cache-read rate). The two rates bracket the estimate:

Averaged over the 502 users, that's 0.37 to 3.7 kWh per user per week, or 19 to 192 kWh a year: the electricity of 64,000 to 641,000 Google searches at Google's 0.3 Wh figure. Heavy users with long sessions remove more than the average, light users less. For scale, the EIA puts the average US home at 10,791 kWh a year, about 207 kWh a week, so the fleet's removals are the weekly electricity of roughly one to nine homes. Multiplied by 52, the week's removals come to 247,426,074,220 tokens and 9,650 to 96,496 kWh a year at September's pace, a run rate that grows with every install.

We don't convert this to a carbon footprint. The emissions depend on the grid behind whichever data center served the request, which providers don't disclose, and published per-prompt carbon figures differ on whether they net out the lab's renewable energy purchases (Google's does).

What the estimate assumes

Energy isn't priced linearly. The per-token rates assume energy splits between token types in the same ratio as price, which Couch himself calls a rough guess, and they come from GPT-4o-era hardware. Since prefill cost grows faster than linearly with context, agent sessions running at 100k+ tokens probably sit above the 390 Wh rate, not below it. Hardware and serving efficiency are moving fast in the other direction: Google reports a 33x drop in energy per Gemini prompt in one year.

Compression can make the model write more. Output tokens cost about five times as much energy as input tokens, so a compressor that confuses the model into longer answers loses. A 2026 study, The Compression Paradox in LLM Inference, found exactly that: compressing benchmark task prompts to 30% of their length grew one provider's output from 21 to 798 tokens and raised estimated energy by up to 2,140%, while pass rates collapsed. That study cut the task itself: the instructions and the question. Headroom compresses input too, but only the context around the task, such as logs, JSON, and search results. Your own messages are never compressed, the cached prefix is left alone, and the agent can retrieve any original it needs. Headroom also shapes output, steering the model away from padding and repetition, which pushes the other way. Output savings aren't counted in the estimate above, and we don't yet have a measured fleet figure for them, so they're left out rather than guessed.

The compressor uses energy too. Headroom runs on your machine. Most of its transforms are plain text processing, but one is a small ModernBERT-based model running on the CPU. We haven't measured its draw, so the figures above are gross savings, not net. It processes each new piece of content once, while the provider would have processed that content on every later turn with a far larger model.

Freed capacity gets used. On a Claude or ChatGPT subscription, Headroom's savings show up as rate-limit headroom, and most people spend that headroom on more work. That lowers the energy per task, which is the honest claim; total energy only falls if the work stays the same. API users who pay per token are more likely to bank the difference.

The part of AI's footprint you control

Most of AI's energy footprint is decided by the labs: which chips they run, where their data centers sit, and what power they buy. How much context each request carries is decided on your machine. That's the part Headroom shrinks, and it points the same way as your bill and your rate limits: fewer tokens per task means less inference per task.

Related: how Headroom counts the tokens it removes, how savings are measured, and what Headroom is.