amadan
Carbon · build estimate
20 entries across this repo's ledger branches could not be parsed and are not included below.
12100 g CO2e
published range: 3120 g – 193000 g — a single band spanning 62× (from 0.2591× to 16.03× the central figure — see Methodology below)
1393827669 tokens counted — 2584427 output, 1375900181 cache read, 15334575 cache write, 8486 fresh input
capturing since 2026-08-31
100% of counted tokens (1393827669 of 1393827669) were priced using the single shared default row, not a model-specific figure — see the "Where these figures came from" table below.
2490 g CO2e (288256669 tokens) of the total above is not attributed to any commit — work that produced no commit, not tokens that went missing. This is usage recorded before a branch's first commit-marker, or on a branch with no commits at all.
Accrued over time
Per session
| Session | Branch | Model | Output | Cache read | Cache write | Input | CO2e |
|---|---|---|---|---|---|---|---|
0d65d16b-81b0-4a8b-a06f-e0bf5bce089e |
diagnose | claude-opus-5 | 649482 | 407474511 | 2528643 | 2004 | 3360 g |
4a30c557-129a-4e57-8aa3-0c7518c36cf1 |
flash-stale-paint | claude-opus-5 | 421748 | 337070772 | 4802440 | 1550 | 3000 g |
8c293727-d922-4f5a-bfde-9457b649670f |
formatting-and-export | claude-opus-5 | 469230 | 335682659 | 2425647 | 1316 | 2790 g |
4831640d-80a1-45ea-828c-336ad36a8cca |
agents-config-lock | claude-opus-5 | 184102 | 79431460 | 1048236 | 712 | 718 g |
7925695a-b185-431d-9d20-42b4dfbeb800 |
worktree-tighten-chrome | claude-opus-5 | 134098 | 52066793 | 808075 | 474 | 485 g |
48ea084f-0296-4b0a-9104-dba9bbd5928c |
worktree-impeccable-init | claude-opus-5 | 136146 | 49218791 | 585998 | 488 | 444 g |
b67dca22-59bf-4290-8b46-545183f24ea9 |
worktree-paste-fidelity | claude-opus-5 | 187221 | 36360473 | 589303 | 460 | 360 g |
f51dc426-0d05-413b-a979-c81d95ac5994 |
worktree-import-documents | claude-opus-5 | 166161 | 31028012 | 474092 | 308 | 306 g |
dda3c5a8-1e06-4d4c-86ca-35135ab3464f |
main | claude-opus-5 | 86526 | 21441553 | 830929 | 334 | 252 g |
e1e74ec8-0576-474e-8564-a71365101816 |
list-thumbnails | claude-opus-5 | 83443 | 24853954 | 472229 | 252 | 243 g |
864a6877-4e1e-4c69-ba9f-bbdf98f53cb3 |
overnight-content-sealing | claude-fable-5-1 | 34119 | 704811 | 350594 | 260 | 44.5 g |
8aa40554-38b1-4597-9cb8-439ab594e268 |
overnight-content-sealing | claude-fable-5-1 | 22864 | 417302 | 361360 | 198 | 41.0 g |
45ec9f47-f7b4-44d1-b2d5-9b318fe74d91 |
fix/signin-visible-label | claude-fable-5-1 | 9287 | 149090 | 57029 | 130 | 8.29 g |
Factor table v1 · 2026-08-30
This figure is produced by factor table v1 (published 2026-08-30). It assumes a grid intensity of roughly 350 g CO2e/kWh and is never rendered at its source constant's full precision — that precision exists for traceability against the cited source, not because the grid intensity is known that exactly.
Where these figures came from
| Model | Row used | Citation |
|---|---|---|
| claude-fable-5-1 | default (fallback) | Energy: Epoch AI, Josh You, "How much energy does ChatGPT use?", 2025-02-07 (https://epoch.ai/gradient-updates/how-much-energy-does-chatgpt-use) — 0.3 Wh for a typical GPT-4o query of 500 output tokens, and, in the appendix, 2.4 Wh for 10,000 input plus 500 output tokens. Take the appendix figure, not the 2.5 Wh the body quotes first and twice: the body states no output-token count, so only the appendix figure can be differenced against the 500-output-token baseline to isolate the input cost. Cache classes: no published energy study separates cached from fresh input, so these use Anthropic's published price multipliers as a proxy — cache read 0.1x and 5-minute cache write 1.25x base input price (Anthropic, "Pricing", https://platform.claude.com/docs/en/about-claude/pricing). Corroboration that the low end of the band is not absurd, though not the bound itself: Vartziotis et al., "From Tokens to Watt-hours", arXiv:2607.26571, Table 3 (https://arxiv.org/abs/2607.26571) gives 218.400 mJ per output token for Llama 3.3 70B = 60.7 Wh/Mtok, about a tenth of the figure above — but that model is accelerator-only, excluding cooling, host, networking, storage and PUE, so it bounds GPU silicon rather than the delivered CO2e this page publishes. Grid: US EPA, eGRID2023 Summary Data (https://www.epa.gov/egrid/summary-data). |
| claude-opus-5 | default (fallback) | Energy: Epoch AI, Josh You, "How much energy does ChatGPT use?", 2025-02-07 (https://epoch.ai/gradient-updates/how-much-energy-does-chatgpt-use) — 0.3 Wh for a typical GPT-4o query of 500 output tokens, and, in the appendix, 2.4 Wh for 10,000 input plus 500 output tokens. Take the appendix figure, not the 2.5 Wh the body quotes first and twice: the body states no output-token count, so only the appendix figure can be differenced against the 500-output-token baseline to isolate the input cost. Cache classes: no published energy study separates cached from fresh input, so these use Anthropic's published price multipliers as a proxy — cache read 0.1x and 5-minute cache write 1.25x base input price (Anthropic, "Pricing", https://platform.claude.com/docs/en/about-claude/pricing). Corroboration that the low end of the band is not absurd, though not the bound itself: Vartziotis et al., "From Tokens to Watt-hours", arXiv:2607.26571, Table 3 (https://arxiv.org/abs/2607.26571) gives 218.400 mJ per output token for Llama 3.3 70B = 60.7 Wh/Mtok, about a tenth of the figure above — but that model is accelerator-only, excluding cooling, host, networking, storage and PUE, so it bounds GPU silicon rather than the delivered CO2e this page publishes. Grid: US EPA, eGRID2023 Summary Data (https://www.epa.gov/egrid/summary-data). |
Methodology
Grams are derived, not asserted, from two separately-arguable
unknowns: watt-hours per million tokens per token class (energy),
and grams CO2e per kWh for the grid inference is assumed
to run on (grid) — grams = (Wh / 1000) × grid.
The published range (3120 g – 193000 g) is one multiplicative band applied to the total, built from two sources answering the same question at each end: the energy term uses Epoch AI's own stated 0.1–4 Wh uncertainty around its 0.3 Wh baseline query; the grid term uses the EPA eGRID2023 subregions that actually host large cloud/inference capacity — RFCE (Northern Virginia / PJM East, the cleaner end) through MROW (Upper Midwest, the dirtier end) — rather than every eGRID subregion that exists.
The result spans a factor of 62×. That is narrower than the mixed-criteria alternative it replaces, which is not why it was chosen: it is the only span where both ends answer the same question, and the ruling would stand if consistency had widened it instead.
That envelope is an assumption about where inference runs, and it is the assumption a reader is most likely to want to reject. It has a real, named failure mode: inference actually running on a grid dirtier than MROW or cleaner than RFCE puts the true figure outside the published band entirely. The band is a stated assumption, not a guarantee.
Nor is the central figure itself conservative. The "floor" language elsewhere on this page is a claim about token coverage — tokens this page cannot see are missing, never double-counted — not a claim about these factors. The factors lean high in several places at once: the grid figure is the US national average against the roughly 272–288 g/kWh where inference actually runs (RFCE 271.8, NWPP 288.2 — the same eGRID2023 table cited above), all of a baseline query's energy is attributed to its output tokens, and cache writes are priced at 1.25× base input price — a proxy for renting five minutes of KV cache residency, not for the compute a cache write performs. A figure that is high on factors and low on coverage is not a bound in either direction.
What this number excludes
- Subagent work is invisible. The capture hook only ever reads the main session's transcript; Task-tool subagents write their own session files that nothing here syncs. For any workflow leaning on subagents — this repo's does — a large fraction of real spend never reaches this number.
- Coverage window. Usage capture on this repo began recently relative to its full history, and backfilling older sessions is not done automatically. "Capturing since" above is the honest bound on how far back this figure actually reaches — not the project's start date, and, under truncation, not even necessarily when capture itself began (it is the earliest entry this page could still read).
- Plaintext-tier force push. On a plaintext-tier remote, ledger chains diverged across two machines resolve by force-overwrite, and one side's usage entries can vanish.
- Contention drops. A token delta can be warned-and-dropped under parallel sessions writing the same branch; a lost sync bookmark can duplicate one instead.
- Interrupted turns. A session abandoned mid-turn leaves a tail nothing later picks up.
- Session working-directory drift. A session that moves between repos books its tokens to whichever repo it was in when it last synced.
Every one of these undercounts except the bookmark-regression case above — so on token coverage, this figure is a floor far more often than a ceiling. That is a separate claim from the factor bias described in Methodology, and neither one cancels the other.