मुख्य सामग्री पर जाएँ

The energy footprint of a generation

A real number, a published method, and the honesty to say what we can't measure.

What we can state with certainty

Every Blueprint Maker generation consumes a bounded, known-in-advance number of AI tokens: which is exactly why the credit cost is published before you launch a generation, rather than discovered after usage.

  • Sketch: 5,500 to 8,500 tokens (Claude Haiku) to design the specification.
  • Craft and Masterpiece: 6,000 to 8,500 tokens (Claude Sonnet) to design the specification.
  • The application's foundation — database schema, API routes, forms, navigation, page structure — is then produced by deterministic builders: programs, not a language model.
  • Some screen blocks, however, are written by a model: the dashboard, the list summary zones, the sample data, and the signature views at Masterpiece level. Those passes consume additional tokens. The number of calls is bounded in advance and retries are capped — this is not an open-ended correction loop — and every block must pass compilation and runtime validation, or it is replaced by its deterministic version.

What that means in energy: an estimate, not a measurement

Published academic literature on the energy cost of large language model inference places it between 0.0001 and 0.002 Wh per output token, depending on model size: a wide range, given the lack of public per-model figures from providers (Anthropic doesn't publish this data for Claude, like most labs).

Applied to the volumes above, the specification step falls in a range of 0.55 Wh to 17 Wh. For comparison, the same literature places a single large language model query at 0.3 to 1 Wh.

The screen-writing passes that follow add tokens we don't yet measure generation by generation. So we don't publish a total, for exactly the reason set out in the next section: a total obtained by adding a measurement to a guess is still a guess.

Why we don't publish a CO2 or water figure

Converting this energy into CO2 emissions or water consumption requires knowing the carbon intensity of the electrical grid and the efficiency (PUE for energy, WUE for water) of the datacenter actually running the inference: data Anthropic doesn't publicly disclose by region.

Any figure we displayed would be a guess dressed up as a fact. We'd rather publish nothing than invent a precision we don't have. The conversion method exists and is documented in the sources below, for anyone who wants to redo it with their own infrastructure assumptions.

What structurally changes elsewhere

Consumption becomes hard to bound as soon as a language model writes the code itself and has to fix it afterward: publicly documented cases report over 20 million tokens consumed to fix a single authentication bug at a competing generator, and up to half of tokens spent on correction loops rather than construction.

This isn't a numeric comparison: we have no visibility into their real average consumption, and we don't claim to. It's a structural contrast, and it doesn't rest on the idea that no model writes any code here — we just said the opposite. It rests on what bounds the spending: the foundation is produced by programs, the model passes cover delimited blocks, their call count is fixed and their retries are capped. An architecture where the model writes the whole application and reviews itself can, by nature, loop on its own mistakes; an architecture where every pass has a ceiling and a compiler for a judge cannot.

Sources and method

  • LLM Inference: Energy, Water & Carbon Footprint: emergentmind.com/papers/2505.09598
  • Quantifying the Energy Consumption and Carbon Emissions of LLM Inference via Simulations: arxiv.org/pdf/2507.11417
  • From Prompts to Power: Measuring the Energy Footprint of LLM Inference: arxiv.org/html/2511.05597
  • Making AI Less « Thirsty »: Uncovering and Addressing the Secret Water Footprint of AI Models: arxiv.org/pdf/2304.03271
  • LLMCO2: Advancing Accurate Carbon Footprint Prediction for LLM Inferences: arxiv.org/pdf/2410.02950