Research edition: 6 November 2026 · Batch 2, energy-efficiency research · DN worksheet v0.1
What Matters
For an AI agent, the useful energy question is not simply what one prompt consumes. Count the electricity used across the declared workflow boundary, including failed attempts and retries, then divide by tasks that meet a fixed acceptance rubric. Keep measured readings, modeled estimates and unknown services distinct. Lower energy per query does not automatically mean lower energy per useful outcome.
An agent can answer cheaply and still spend the next hour calling tools, retrying a rejected action and asking another model to check its work. A per-prompt figure describes only one possible part of that operation.
The same problem appears in a different form when a company compares a GPU-only benchmark with a provider’s facility-inclusive estimate. Both numbers may be honestly reported. They still do not describe the same boundary.
Decentralised News’s contribution is a practical energy-to-value ledger: record the workload, count accepted results, retain the energy scope and show the arithmetic. This initial release is a calculator, three illustrative scenarios and a blank measurement template. It is not a measured model leaderboard.
- Reviewed: 6 November 2026. Primary materials from Hugging Face, CodeCarbon, EcoLogits, Google and the Green Software Foundation.
- Original work: outcome-based arithmetic, calculator, three teaching scenarios and a reusable measurement-record template.
- Not performed: no GPU experiment, facility-meter audit, provider-energy authentication or lifecycle assessment.
- Important boundary: all example energy, acceptance, PUE, grid and tariff inputs are invented. They are not observed vendor results or geographic defaults.
The Signal: Energy Numbers Need a Scope Before They Need a Ranking
| Evidence | Useful for | Does not establish |
|---|---|---|
| Hugging Face AI Energy Score | Controlled task and hardware comparisons for model inference | Your complete agent’s energy per accepted business result |
| CodeCarbon | Tracking or estimating energy for supported local compute components | Unobserved remote API hardware energy |
| EcoLogits | Inference-impact estimates with explicit assumptions and approximation intervals | A direct reading from a provider’s electricity meter |
| Google’s 2025 disclosure | Understanding its stated serving-system boundary and reported median prompt | A universal constant for every current API call or agent |
| SCI for AI | Framing functional units and explicit system boundaries | That this simplified DN worksheet is a conforming SCI assessment |
Hugging Face’s methodology makes task and hardware context central to comparison and advises considering performance alongside energy. Its v2 release on 4 December 2025 added reasoning evaluation. That is a reason to record reasoning settings in an experiment, not a license to apply one published multiplier to all reasoning workloads.
Google’s 21 August 2025 analysis reported (see also the authors’ technical paper) an estimated median Gemini Apps text prompt at 0.24 Wh under its comprehensive serving boundary, compared with 0.10 Wh under an active-accelerator-only approach. The contrast illustrates the importance of scope. Neither value should be pasted into a 2026 agent spreadsheet as a universal per-call input.
DN Alpha Thesis: Optimize the Task, Preserve the Denominator
DN’s proposed functional unit is one task accepted against a recorded rubric. For example, that might be a research brief with verified sources, an invoice reconciled against the authoritative ledger, or a support case resolved without reopening inside a predefined review window.
Define that outcome before testing. Otherwise an apparently efficient configuration can win by returning shorter, easier or incomplete work. A task that merely produces text is not equivalent to one that meets the specified business requirement.
For the same cohort, use:
Wh per accepted task = in-boundary batch energy (Wh) / accepted tasks
The numerator includes unsuccessful work in that cohort. Do not count only the electricity used during successful attempts while discarding retries, graders or aborted runs that were inside the declared scope. Keep a unique workflow count separate from the number of model calls or attempts.
For acceptance design, use DN’s AI Agent Acceptance Tests. For denominator manipulation and hidden assistance, see AI Agent Benchmark Integrity. Here, the additional question is physical resource consumption, rather than the price of the service.
The Reversal: More Total Energy, Less Energy per Accepted Task
The following is an invented teaching comparison. Assume the same 100-workflow cohort, rubric and IT boundary, with PUE 1.2 applied once.
| Scenario | IT energy | Adjusted energy | Accepted tasks | Wh per accepted task |
|---|---|---|---|---|
| A | 100 Wh | 120 Wh | 50 | 2.4 Wh |
| B | 150 Wh | 180 Wh | 90 | 2.0 Wh |
| Zero accepted | 100 Wh | 120 Wh | 0 | Undefined |
Scenario B uses 50% more total energy but produces 80% more accepted results. Its energy per accepted task is therefore about 16.7% lower. That does not establish that B is always preferable: total energy, delivered volume, quality, latency and constraints still matter.
This is a denominator effect demonstrated by arithmetic, not proof that extra reasoning or a larger model creates that improvement in practice. A real comparison requires repeated, comparable runs and uncertainty reporting.
Calculate Your Declared Boundary
DN Energy per Accepted Task Calculator v0.1
Illustrative inputs, not measured results. Enter energy for the same workload window as the workflow counts. Include retries and failed attempts within your stated boundary. Unknown remote services remain excluded.
Calculator activates on the live DN site. Static example A: 100 Wh × 1.2 = 120 Wh; 120 Wh / 50 accepted tasks = 2.4 Wh per accepted task. Downloads and formulas remain available without JavaScript.
Calculated in your browser. This worksheet does not submit your scenario or measure hardware. It excludes embodied emissions, training allocation, water and any unknown services. Electricity cost is not your API invoice.
Scenario JSON · Scenario CSV · Blank measurement template · Dated source review · Methodology and limits
Three Boundaries That Should Stay Separate
1. Compute you control
CodeCarbon’s documentation distinguishes hardware counters from fallback power models. It also explains that CPU and RAM process attribution differs from device-wide GPU tracking. On shared hardware, record who else was using it and how energy was allocated.
A software tool’s output can combine measured and modeled components. Keep those labels in the record. Do not describe an entire workload as directly metered because one GPU counter was available.
2. Facility or supporting infrastructure
CodeCarbon’s accuracy boundary does not automatically include every peripheral or lifecycle component. Its methodology also says configured PUE is already folded into reported energy. Applying the same overhead again would double-count it.
A wall meter may already include the GPU, CPU, memory and power-supply losses. Adding their readings to the wall measurement counts overlapping electricity. Choose a consistent top-level boundary or non-overlapping components and document it.
3. Remote services you cannot meter
Measuring the laptop that calls a hosted model does not measure the provider’s servers. EcoLogits uses modeled inference-impact assessment with explicit assumptions and approximation intervals. Such estimates may support a scenario, but they should remain identified as estimates.
For a mixed workflow, retain separate rows for local compute, remote model calls and external tools. If a material component is unknown, report a partial boundary rather than silently assigning it zero. Do not describe that partial number as the complete agent footprint.
Energy, Carbon and Price Answer Different Questions
Watt-hours describe energy. Operational emissions additionally require an intensity factor for the electricity associated with the declared boundary:
operational gCO2e = Wh / 1,000 × gCO2e per kWh
Record the intensity’s source, geography, time basis and whether it matches the accounting question. The calculator does not discover those inputs. A cleaner electricity assumption can reduce modeled operational emissions without reducing energy use.
The Software Carbon Intensity specification includes operational and allocated embodied emissions per functional unit. Its AI extension discusses workflow execution for agentic systems and material multi-call operations. DN’s accepted-task denominator is an editorial choice for this worksheet; this simplified operational calculation does not establish SCI conformance.
Electricity cost is a third quantity. Even a correctly calculated energy charge excludes model-provider pricing, tools, hosting margins, storage and human review. Use The Agent Cost Stack to model the wider commercial budget. A low API price is not an energy measurement.
A Practical Pilot Before You Make an Efficiency Claim
- Freeze the workload and rubric. Record the task set, versions and review window. Count rejections and unresolved results explicitly.
- Draw the boundary. List models, orchestrator, graders, retrieval, tools and relevant overhead. Identify missing or overlapping measurements.
- Label the evidence. Distinguish hardware readings, allocation estimates, provider disclosures and assumed inputs. Retain the original reference.
- Run matched repetitions. Keep relevant settings, workload mix and concurrency comparable. Record latency and acceptance alongside energy.
- Calculate both totals and intensities. Publish total Wh, submitted workflows, accepted tasks and Wh per accepted task. Keep zero-denominator results undefined.
- Preserve uncertainty and changes. Report sampling, allocation and estimate limitations. Revisit the claim after changes to models, hardware, harnesses, rubric or workload.
For a solo builder, start with a controlled local workflow and a clearly scoped reading. For a small team using hosted APIs, prioritize reliable workflow counts and explicit estimates rather than pretending to have a full meter. For an enterprise, involve infrastructure, procurement and sustainability owners before turning a pilot into a public claim.
Build the record before buying another dashboard
A simple CSV or your existing database may be enough. If you need no-code event collection, Make documents a Webhooks-to-Google-Sheets integration. A proposed workflow is to store a run ID, rubric version, acceptance state and a reference to the separate energy record.
Explore Make for event-to-sheet automation (affiliate link). This is optional orchestration, not a meter, model-efficiency endorsement or implementation DN has tested for this article. It cannot supply unknown provider energy. Protect webhook endpoints and avoid placing sensitive task content in a public sheet.
For a scoped comparison of deployment evidence and unresolved measurement boundaries, request a paid DN Research Desk brief. Agree the deliverable and scope first; this is research, not a sustainability certification.
Methodology, Limits and Corrections
Evidence cut-off: 6 November 2026. This article reviews current official documentation and dated disclosures. Its original dataset consists of three invented arithmetic scenarios and a blank recording template. No provider or hardware system was tested or ranked.
Calculation scope: batch energy divided by the accepted count. IT-only inputs receive the user’s PUE once; facility-inclusive and partial inputs do not. Optional intensity and tariff are arithmetic assumptions. Missing optional values remain unknown. The worksheet excludes embodied impacts, training allocation, water and omitted services and does not compute a lifecycle or regulatory inventory.
Falsification: a unit error, duplicated overhead, mismatch between the visible example and downloadable data, or excluded attempt inside the claimed cohort would undermine the result. Acceptance quality must be independently checked; internally correct arithmetic cannot authenticate its inputs.
Updating: v0.1 is the initial 6 November 2026 release. Material formula, scenario or boundary changes require a new version. Recheck primary documentation before using it for procurement. Send a correction with the source and affected claim.
Commercial disclosure: DN may earn commission through the marked Make link. Make’s integration is publicly documented as live; DN has not verified reader-specific eligibility, pricing or deployment fit. Affiliate availability did not determine the methodology or examples. Research Desk is DN’s paid service. Original DN data files are CC BY 4.0; external materials retain their own terms.
Primary Sources
- Hugging Face AI Energy Score. Controlled model/task energy benchmark; not a complete agent-workflow measurement.
- AI Energy Score v2. Published 4 December 2025; reasoning benchmark context, not a universal reasoning multiplier.
- Google inference measurement. Published 21 August 2025; provider-reported median Gemini Apps text-prompt estimate for its stated scope, not a current universal API constant.
- CodeCarbon methodology. Hardware readings and fallback estimates have different provenance; configured PUE is already included in reported energy.
- CodeCarbon accuracy boundary. Component tracking is not automatically a whole-facility or lifecycle footprint.
- Software Carbon Intensity specification. Includes operational and allocated embodied emissions per functional unit; DN calculator is not an SCI assessment.
- SCI for AI specification. Discusses agentic workflow functional units and explicit system/persona boundaries.
- EcoLogits methodology. Modeled inference impacts with assumptions and approximation intervals; not direct provider metering.
- Make Webhooks and Google Sheets integration. Optional event-to-sheet orchestration; not an energy meter or hosted-model energy disclosure.
Frequently Asked Questions
How much electricity does an AI agent use?
There is no single universal figure. It depends on the workload, models, hardware, tool calls, retries, acceptance criteria and accounting boundary. Measure or estimate a defined batch and divide by accepted tasks; disclose unknown components.
Is Google’s 0.24 Wh figure an agent-workflow estimate?
No. Google reported that estimate for its median Gemini Apps text prompt in its 2025 analysis. It is not a universal or current energy constant for every agent, API request or multi-step workflow.
Does CodeCarbon on my laptop measure a hosted API’s servers?
No. Local component readings do not reveal a remote provider’s hardware consumption. API-oriented estimation tools use assumptions and should be labeled as estimates, with their scope and uncertainty.
Should I multiply a CodeCarbon export by PUE again?
Not if its energy already includes the configured PUE. Confirm the tool version and settings. In the DN calculator, facility-inclusive and partial inputs are never multiplied by PUE.
What happens if no task is accepted?
Energy can still have been consumed, but energy per accepted task is undefined. DN does not display zero intensity or pretend the work was efficient when the denominator is zero.
Is operational carbon the same as energy?
No. Watt-hours measure energy. Operational emissions additionally depend on the electricity’s carbon intensity. A fuller carbon assessment also addresses its other applicable boundaries and lifecycle components.
Can the calculator rank models or certify an SCI score?
No. Its inputs are user-entered scenarios. It does not test models, validate acceptance, meter hardware, calculate embodied impacts or establish SCI or ISO conformance.
Why can a higher-energy workflow be more efficient per outcome?
If the extra energy produces sufficiently more accepted tasks under the same rubric and boundary, energy per accepted task can be lower. Compare total consumption and outcome intensity together; the illustrative examples are not evidence of actual vendor performance.
Can an electricity-cost estimate replace my API bill?
No. The electricity-only calculation excludes model pricing, tools, hosting margins, storage, human review, setup and other operating costs. Use the DN Agent Cost Stack for the broader budget.
What if some services are unknown?
Keep the result labeled partial. Do not fill missing energy with zero, combine overlapping meters or compare a partial GPU-only number with a facility-inclusive footprint as though they cover the same system.
DN Agent Energy Worksheet v0.1 · Published 6 November 2026 · All numerical scenarios illustrative.
