tokenneutral.ai

NN · Methodology · WAIE v1.0.0

How we estimate AI impact

We estimate operational AI impact using the best available usage data, adjust for workload shape and model class, show uncertainty clearly, recommend reductions first and only then suggest contributions aligned to the remaining estimated impact.

What this is — and what it is not

This is not direct measurement of provider-side infrastructure impact unless a provider supplies that data. Most estimates are inferred from usage metadata, published research and transparent assumptions.

Every estimate is a range with a confidence level, never a single exact number. We do not claim carbon neutrality, exact footprints or one-to-one offsetting. Where we suggest a contribution, it is aligned to the estimated impact range — nothing stronger.

Included in this estimate

  • Operational energy of model inference, estimated from usage shape
  • Datacentre overhead (cooling, networking) via a PUE-style factor
  • Grid carbon intensity conversion (configurable, region-adjusted where known)

Excluded from this estimate

  • Model training and fine-tuning impact
  • Hardware manufacturing and embodied carbon
  • Provider-side idle capacity and redundancy
  • End-user device energy
  • Water impact (shown separately as indicative only)

Workload-Adjusted Inference Estimation (WAIE)

Token counts alone are a poor proxy for impact: a token generated by a small drafting model and a token generated by an agentic pipeline over a huge context are very different things. WAIE starts from a Standard Interaction Equivalent (SIE) — a reference text interaction on a mainstream interactive model with moderate context, short output and no heavy reasoning — and adjusts it for the shape of your usage:

Adjusted SIE = Base Activity × Model Class × Workload × Context × Output × Reasoning × Overhead × EfficiencyEnergy = Adjusted SIE × Wh per SIECarbon = Energy × (Grid Intensity × Region)

Adjusted SIE converts to energy using three calibration anchors — 0.24 Wh (low) · 0.34 Wh (central) · 0.67 Wh (high) per SIE. These anchors are calibration values informed by published research, not universal constants; they are versioned with the methodology and will be revised as better evidence emerges. Energy converts to carbon using a configurable grid intensity (default 0.14396 kg CO₂e/kWh, UK-style), adjusted by region where you know it.

Region adjusts carbon, not consumption. Region factors are grid carbon-intensity ratios, so they are applied when energy converts to carbon — never to the energy itself. Running a workload on a dirtier grid does not make the hardware draw more electricity; it makes each kWh carry more CO₂e. This is why the kWh we report for a given workload is the same in every region, while the CO₂e is not. Water, which derives from energy, is likewise region-independent.

Water is shown as indicative only (1.8 L/kWh) and is never used to size contributions.

The token path (provider connections)

When usage comes directly from a provider's usage API (confidence Level 4), we estimate from measured token counts instead of interaction assumptions. Input, cached-input and output tokens are weighted (×1 / ×0.1 / ×4 — output/decode dominates energy, cache reads skip prefill) and converted at 2,000 weighted token units per SIE. Because tokens already measure context length, output length and reasoning effort, those multipliers are not applied on this path — applying them would double-count. Model class and overhead still apply, and region still adjusts carbon on the conversion step. Provider model names map to model classes through a published, versioned mapping table.

Factors that are mutually exclusive

Some of these factors describe the same property of the same work. Where two of them overlap, only one is allowed to fire — otherwise a single piece of usage is counted twice and swamps everything around it. The rules are deliberate and listed here in full:

  • Measured tokens replace the shape factors. When usage comes from measured token counts, the workload, context, output and reasoning multipliers collapse to 1. The tokens already measure what those factors approximate.
  • An agentic workload replaces reasoning intensity. The Agentic coding multiplier (×6) already prices in planning, tool loops and retries, so the reasoning-intensity factor collapses to 1 on that workload. Selecting an agentic workload and agentic reasoning intensity states one fact twice; before WAIE v1.0.0 the two compounded with the reasoning model class for a 192× chain on a single entry.
  • Your own grid intensity replaces the region factor. If you set a grid intensity in settings, that figure describes your actual electricity and region — a coarse proxy for the same thing — is not applied on top.
  • Modality has no separate multiplier. Image, audio and video model classes and workloads already carry modality cost.

Confidence levels

Every estimate carries the confidence of the weakest data behind it. Better data narrows the range — it never silently changes the claim.

  1. 1

    Self-reported usage estimatelive

    You tell us roughly how often you use AI, with which tools and what workload mix. Widest uncertainty.

  2. 2

    Spend-based estimatelive

    Monthly AI spend, seats and approximate workload mix. Spend is converted to activity using published, per-tool assumptions.

  3. 3

    Message or request count estimatelive

    Message counts, request counts or usage logs without full provider detail. Activity is no longer assumed — only its shape is.

  4. 4

    Provider or API usage exportcoming later

    CSV or API exports from providers confirm counts, models and token volumes.

  5. 5

    Enterprise telemetry or admin integrationcoming later

    Admin, observability or product telemetry integrations — the highest confidence.

Factor tables

All factors are published, versioned and stored in a single methodology configuration — changing them never requires changing calculation logic. Current values for WAIE v1.0.0:

Workload types

BandMultiplierDescription
Light chat & drafting×0.75Short conversational exchanges, quick drafts, rewording and simple Q&A.
Research & summarisation×1.25Searching, synthesising and summarising sources or notes.
Document analysis×1.75Analysing long documents, contracts, reports or datasets in context.
Image generation×8Generating or editing images from prompts.
Audio transcription×1.5Transcribing or translating speech to text.
Video generation×50Generating video from prompts or images.
Coding assistance×2Autocomplete, code chat, explaining and refactoring code.
Agentic coding×6Multi-step autonomous coding agents that plan, edit, run and retry.
Long-context reasoning×5Reasoning over very large contexts — codebases, books, case files.
Batch processing×1.2Non-interactive bulk jobs — classification, enrichment, generation at scale.
Evaluation & testing pipelines×3.5Automated eval suites, regression tests and LLM-as-judge pipelines.
Embedded AI features×2.5AI features inside your own product, serving your users.

Model classes

BandMultiplierDescription
Small / mini model×0.4Lightweight models optimised for speed and cost.
Standard model×1Mainstream interactive models — the SIE reference class.
Frontier model×2Largest general-purpose models.
Reasoning model×4Models that generate extended hidden reasoning before answering.
Multimodal model×3Models processing images, audio or documents alongside text.
Image model×8Dedicated image generation models.
Audio model×1.5Speech-to-text and text-to-speech models.
Video model×50Video generation models.
Unknown model×1.5Model class not known — a conservative middle assumption is applied.

Context length

BandMultiplierDescription
Short context×0.75A few messages or a short prompt.
Medium context×1A typical working conversation or a few pages of material.
Long context×2.5Long documents or extended conversations.
Very long context×6Very large contexts — whole codebases or books.
Unknown context×1.5Context length not known.

Output length

BandMultiplierDescription
Short output×0.75A sentence to a paragraph.
Medium output×1Several paragraphs.
Long output×1.75Pages of output or large code changes.
Very long output×3Very large generated outputs.
Unknown output×1.25Output length not known.

Reasoning / agentic intensity

BandMultiplierDescription
None / low×1Direct responses without extended reasoning.
Moderate×1.75Some step-by-step reasoning or tool use.
Heavy reasoning×4Extended reasoning chains on hard problems.
Agentic multi-step×8Autonomous multi-step agents with retries and tool loops.
Unknown×1.5Reasoning intensity not known.

Region adjustment

BandMultiplierDescription
Unknown region×1No regional adjustment applied.
United Kingdom×1UK grid — close to the default grid factor.
EU North (Nordics)×0.55Low-carbon Nordic grids.
EU West×1.55Western European grid mix.
US East×2.5US eastern grid mix.
US West×1.8US western grid mix.
Asia Pacific×3.05Typical APAC grid mix.

Efficiency behaviours

Reported optimisation behaviours reduce the estimate, capped at 35% in total because savings overlap:

  • Prompt caching10%
  • Batch processing8%
  • Reused context7%
  • Low retry rate5%
  • Human review checkpoints5%

Contribution logic

Reduction comes first: we surface avoidable waste before suggesting any contribution. Where impact remains, we suggest a monthly contribution as the higher of a tier minimum, a share of known monthly AI spend, or a rate per adjusted SIE. Two tiers are offered — Starter (1% of spend or £0.0005/SIE) and High Integrity (2.5% of spend or £0.0015/SIE) — with published portfolio splits weighted towards reduction enablement and durable carbon removal respectively.

Your contribution is aligned to the estimated impact range. It does not prove exact one-to-one offsetting.

Uncertainty, versioning and limitations

Uncertainty. Ranges reflect calibration uncertainty (the low/central/high anchors) but not classification error — if usage is misclassified, the true range may sit outside the shown one. Workload multipliers for media generation carry the widest uncertainty.

Versioning. Every estimate records the methodology version that produced it (WAIE v1.0.0, published 2026-07-28). When factors change, historical estimates keep their version — ranges may widen as well as narrow.

Limitations. We cannot observe provider infrastructure. Spend-to-activity assumptions are coarse. Region factors are directional. Training, embodied hardware and idle capacity are excluded. If any of these matter for your reporting, treat these figures as a screening estimate, not an audit.

Provenance. The source or stated assumption behind every calibration anchor and factor is documented in the project's calibration notes, which change in lockstep with this configuration.

Changelog

  • WAIE v1.0.0 · 2026-07-28 — Platform freeze. No factor value changed from v0.4.0; what changed is governance. Each methodology version is now published as an immutable, content-hashed record that can never be silently edited, every estimate permanently names the version that produced it, and a golden-file test suite locks the engine's output byte-for-byte — any drift fails our build unless a new version declares the change and says why.
  • WAIE v0.4.0 · 2026-07-28 — Two double-counts removed. Region factors moved out of the SIE chain and onto the energy→carbon step, where grid carbon-intensity ratios belong: reported kWh (and indicative water) are no longer inflated by up to 2.5× for high-carbon regions, and carbon is unchanged. Reasoning intensity now collapses to 1 on agentic workloads, whose multiplier already prices in multi-step reasoning. A grid intensity you set yourself suppresses the region factor rather than compounding with it. Totals for agentic-heavy usage fall substantially; the shape of the breakdown changes.
  • WAIE v0.3.0 · 2026-07-27 — Grid intensity set to the DESNZ 2026 UK "electricity consumed" factor (0.14396 kg CO₂e/kWh), region multipliers rescaled against it so each region's implied absolute intensity is unchanged. The settings value became an override of this published factor rather than a copy of it, so the number shown here is always the number used.
  • WAIE v0.2.0 · 2026-07-04 — Added the token→SIE path for direct provider connections (Level 4): weighted token conversion, cache-read discounting, model-name→class mapping table. Shape multipliers collapse on measured usage to avoid double-counting. Interaction-path estimates are unchanged.
  • WAIE v0.1.0 · 2026-07-01 — Initial methodology: SIE calibration anchors, workload/model/context/output/reasoning factor tables, confidence levels 1–5, efficiency behaviours, contribution tiers.

Questions about the methodology, or data that would improve it? See the live factor configuration.