Skip to content

Plan usage board shows energy, in kitchen terms - #6

Open
debtn wants to merge 1 commit into
mainfrom
claude/steward-energy-board
Open

Plan usage board shows energy, in kitchen terms#6
debtn wants to merge 1 commit into
mainfrom
claude/steward-energy-board

Conversation

@debtn

@debtn debtn commented Sep 2, 2026

Copy link
Copy Markdown

Adds estimated watt-hours and a household comparison to the steward Plan usage tab — per builder, and for the network as a whole. Follows from the energy design exploration.

Why this was cheap

The board already knew everything it needed. The proxy records input, output, cache-write and cache-read separately, per person per day per model, and the model recorded is the one that actually served — so outage fallbacks attribute correctly. Energy is a coefficient on top of that, accumulating through the same path as cost and landing beside it. No schema change, no new tracking.

How the number is built

Output tokens dominate: generating is sequential, one forward pass per token, memory-bandwidth-bound. Prefill runs in parallel and is far cheaper per token, and a cache read skips recomputation almost entirely — so the classes are weighted 1 / 0.15 / 0.15 / 0.05, the way the price weights already mirror billing.

Per-model scaling comes from each model's output price relative to Opus. Price is a proxy for serving compute rather than a measurement of it, but treating a day on Haiku like a day on Fable would be more wrong than this is, and the scalar only moves things 0.2–2×, well inside the band.

Two things the display is deliberate about

It always shows a band. The absolute coefficient is inferred, not published: from hardware it lands near 0.04–0.15 mWh per output token; from labs' per-prompt figures nearer 0.8–1.1 mWh. That's a spread of roughly twentyfold, and nothing outside a datacenter closes it. A single confident figure would read as a measurement. The token counts underneath are exact and stay separable from the coefficient, so it can be revised later without the history becoming a lie.

It compares to appliances, not vehicles. A whole project works out to about 376 feet of driving — which reads as "this is nothing", and inflating it to avoid that would be worse. A kettle, a phone charge, a day of the fridge sit at the same order of magnitude as the real number, so the comparison informs rather than dismisses. The anchor ladder climbs with the amount:

Scale Reads as
One chat turn less than a phone charge
One full build about 1 phone charge
A builder, one day about 1 kettle boiled
A builder, all time about 1.3 loads of laundry
Whole network, all time about 14 days of running a fridge

The note above the board says plainly that it's an estimate, and that builders on their own API key aren't counted at all — every metering call in llm-proxy is gated on community membership.

Files

File
src/lib/energy.ts new — band multipliers, formatWh, the household anchor ladder, and the reasoning behind both
supabase/functions/admin-requests/index.ts energy coefficients and energyUsage() beside the existing rates; wh accumulates through members, network totals and the 14-day series
src/cloud/community-usage.ts wh on UsageTotals and the daily series
src/components/StewardPage.tsx energy line under each headline tile and each builder row; the 14-day bar tooltips carry it too

Verification

Rendered the real UsageTab in a browser against the dev server with a stubbed report, and checked the strings across five orders of magnitude — from a single chat turn to the network's all-time total — to confirm the anchors ladder sensibly and nothing reads as "about 4,000 kettles". Two phrasings were wrong on the first pass and are fixed: about 0 phone charges for tiny amounts (now less than a phone charge) and ~<1 Wh–9.5 Wh (now under 9.5 Wh).

tsc -b and vite build clean; npm run lint unchanged at the 21 pre-existing problems.

Deploying

admin-requests is an edge function, so merging alone won't populate the numbers — it needs a deploy (per CLAUDE.md, via the Management API). Until then the board degrades gracefully: wh is absent, the guard suppresses the line, and everything else renders exactly as before.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RFnFvBZPsVQjc5Xwj7H9nZ


Generated by Claude Code

The board already knew everything it needed: the proxy records input,
output, cache-write and cache-read separately, per person per day per
model, and the model recorded is the one that actually served. Energy is a
coefficient on top of that, so it accumulates through the same path as cost
and lands beside it.

Output tokens dominate -- generating is sequential, one forward pass per
token -- while prefill runs in parallel and a cache read skips recomputation
almost entirely, so the classes are weighted 1 / 0.15 / 0.15 / 0.05 the way
the price weights mirror billing. Per-model scaling comes from each model's
output price relative to Opus: price is a proxy for serving compute rather
than a measurement of it, but treating a day on Haiku like a day on Fable
would be more wrong than this is, and the scalar only moves things 0.2-2x.

Two things the display is deliberate about, because the number invites
overclaiming in both directions.

It always shows a band. The absolute coefficient is inferred, not
published: from hardware it lands near 0.04-0.15 mWh per output token, and
from labs' per-prompt figures nearer 0.8-1.1 mWh, a spread of roughly
twentyfold that nothing outside a datacenter closes. A single confident
figure would read as a measurement. The token counts underneath are exact,
and stay separable from the coefficient so it can be revised later without
the history becoming a lie.

And it compares to appliances, not vehicles. A whole project works out to
about 376 feet of driving, which reads as "this is nothing" -- and
inflating it to avoid that would be worse. A kettle, a phone charge, a day
of the fridge sit at the same order of magnitude as the real number, so the
comparison informs instead of dismissing. The anchor ladder climbs with the
amount, so a person-day reads in kettles and the network's all-time total
reads in fridge-days rather than four thousand phone charges.

The note above the board says plainly that it's an estimate, and that
builders on their own API key aren't counted at all -- every metering call
in the proxy is gated on community membership.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RFnFvBZPsVQjc5Xwj7H9nZ
@vercel

vercel Bot commented Sep 2, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
relational-builder Ready Ready Preview Sep 2, 2026 7:07am UTC

Request Review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants