ragornot

How we calculate this

Methodology

Every environmental number on ragornot — in the Benchmark impact section, the decision tool, and the digest — comes from the cited coefficients below. This page is the whole recipe: the figures, their sources, the formulas, and the caveats.

Read this first: these are estimates, not measurements

  • Every derived figure is an order-of-magnitude estimate. It tells you the shape of a tradeoff, not a certified measurement.
  • ragornot itself runs Claude Haiku on Amazon Bedrock over a small demo corpus. The frontier-model energy and water figures below are literature-derived proxies applied to the modes— they are not direct measurements of ragornot's own Bedrock calls. We use published figures because they're the most defensible numbers available, and we'd rather show them honestly than invent our own.
  • Water is always split into scope-1 (on-site cooling only) and full-scope (including the water used to generate the electricity). We never conflate the two.
  • No cross-user averages. Anything session-based (the self-consumption meter) is labelled as a this-session estimate that resets on refresh.

Measured vs modeled

Two very different kinds of number appear on the benchmark, and we badge each one so you never confuse them:

  • Measured — latency, token counts, and cost per query come straight from the Amazon Bedrock API response (token billing). These are real numbers from your run.
  • Modeled— energy, water, and CO₂ are computed from the literature coefficients below. They are order-of-magnitude estimates, not measurements, and are tagged “modeled — estimate” wherever they appear.

Retrieval relevance is a proxy, not answer correctness.The “Relevance %” column is a BM25 / query-term retrieval-confidence score — how lexically relevant the retrieved chunks are — not whether the final answer is correct. End-answer evaluation (correctness, faithfulness, citation quality) against a golden set is a planned future metric. LLM-only has no retrieval step, so it shows N/A.

The order-of-magnitude that matters

Retrieval ≈ 0.3 Wh  vs  long-context ≈ 40 Wh — ~100× the energy

A retrieval-grounded answer uses about 0.3 watt-hours; attaching a roughly 100,000-token document to the query uses about 40 watt-hours — around 133 times more energy.

Retrieval sends the model only what's relevant, so each answer stays near a short-query energy budgetsource: Epoch AI, "How much energy does ChatGPT use?" (Feb 2025) (opens in a new tab). Attaching a large document to every prompt pays the full long-context tax on every callsource: Epoch AI, "How much energy does ChatGPT use?" (Feb 2025) (opens in a new tab). Same answer, ~100× the energy — the whole reason to ask “RAG or not?” before reaching for a giant context window. Order-of-magnitude estimate, not a measurement.

Energy per query

Electricity per query for modern models, from Epoch AI's analysis. A short chat query is the baseline a retrieval-grounded answer looks like; long-context stuffing is the expensive alternative.

FigureValueWhat it meansSource
Typical short chat query (GPT-4o-class)0.1–0.6 WhVaries with response length. This is the baseline a retrieval-grounded answer looks like.Epoch AI, "How much energy does ChatGPT use?" (Feb 2025)
Reasoning-heavy query (o3-class)3.9 WhExtended chain-of-thought / test-time compute pushes energy up ~10× over a short chat query.Epoch AI, "How much energy does ChatGPT use?" (Feb 2025)
Long-context query (~100k-token document stuffed into context)40 WhAttaching a large document to every query is the expensive alternative to retrieving only what's relevant.Epoch AI, "How much energy does ChatGPT use?" (Feb 2025)

Water per query

Scope-1 counts only the water evaporated by on-site data-center cooling — the figure vendors disclose. Full-scope adds the water consumed generating the electricity, which is roughly 4× larger. The Benchmark charts show full-scope and say so; here are both.

FigureValueWhat it meansSource
OpenAI, per query — on-site coolingscope-1 (on-site cooling only)0.32 mLWater evaporated by data-center cooling for the compute — excludes water used to generate the electricity.OpenAI (vendor-disclosed)
Google Gemini, median per query — on-site coolingscope-1 (on-site cooling only)0.26 mLVendor median for a text prompt; on-site cooling only.Google (vendor-disclosed, median)
GPT-4o short query — full scopefull-scope (incl. electricity generation)1–1.3 mLAdds the water consumed generating the electricity to the on-site cooling water — roughly ~4× the scope-1 figure. Range from the scope-1 vendor spread (0.26–0.32 mL) scaled to full-scope.Jegham et al., "How Hungry is AI?" (arXiv, May 2025)
Estimated global AI water use, 2025full-scope, global aggregate312–764 billion LData-center cooling is ~30–40% of a data center's energy draw.de Vries, Patterns (Dec 2025)

Carbon

Carbon is computed from energy and the carbon intensity of the grid, which you can change in the Benchmark impact section. The assumption is always shown, never buried.

gCO₂ = energy(kWh) × grid intensity (gCO₂/kWh)
FigureValueWhat it meansSource
Grid carbon intensity (configurable)50–480 gCO₂/kWhCO₂ = energy(kWh) × grid intensity. The default is US-ish; the global average is higher (~480).Ember / IEA grid-intensity averages
Grid presetgCO₂/kWhNote
US grid (default)400Roughly the US average carbon intensity.
Global average480Global average is higher than the US.
EU average250More renewables and nuclear than the US average.
Low-carbon region50Hydro / nuclear-heavy grids (e.g. Nordics, Québec).

RAG vs long-context (cost & tokens)

The energy contrast has a cost twin: stuffing documents into every prompt bills for those tokens on every call, while retrieval pays only for the slice it fetches.

FigureValueWhat it meansSource
Long-context is this much more expensive than RAG20–24 ×Stuffing documents into every prompt bills for those tokens on every call; RAG pays only for the retrieved slice.arXiv, "The Token Tax" (2026)
RAG is this much cheaper in tokens for typical workloads8–82 ×Range depends on corpus size and query pattern; retrieval keeps the prompt small.RAG 2025 review (RAGFlow)

The exact formulas

We translate a query's token count into energy — more defensible than deriving from dollar cost — anchored to the Epoch short-query figure. Water and CO₂ then follow from that energy, so every number moves together.

# anchor: a typical short query ≈ 500 tokens ≈ 0.3 Wh

energy_Wh_per_1k_tokens = 0.3 / (500 / 1000) = 0.6 Wh

energy_Wh = (total_tokens / 1000) × 0.6

effective_Wh = energy_Wh × (PUE / 1.2) # PUE overhead, default 1.2

co2_g = (effective_Wh / 1000) × grid_gCO2_per_kWh

water_full = (effective_Wh / 0.3) × 1.2 mL # full-scope

water_scope1 = (effective_Wh / 0.3) × 0.32 mL # on-site cooling

# uncertainty band: scale effective_Wh by 0.33× (low) to 2.00× (high)

# from Epoch's 0.10.6 Wh short-query range around the 0.3 Wh mid

# Flat / Hierarchical make no LLM call → ~0 marginal energy, water, CO₂

# Live LLM/RAG runs derive energy from the run's own token count, same anchor

Uncertainty & sensitivity

Modeled figures are shown as mid (low–high), never a single false-precision point. The energy band comes from Epoch AI's short-query range (0.10.6 Wh around the 0.3 Wh mid); CO₂ and water inherit that band. Other ranged coefficients: full-scope water 1–1.3 mL, grid intensity 50–480 gCO₂/kWh, long-context cost 20–24×, and RAG token savings 8–82× — each traced to its source in the tables above.

The Benchmark impact panel exposes three sensitivity controls — grid intensity, PUE (data-center overhead), and per-token energy (efficient / typical / conservative, mapping to the low / mid / high energy) — and every modeled figure recomputes live as you change them.

effective_energy = token→Wh × (PUE / 1.2)
FigureValueWhat it meansSource
Data-center PUE (Power Usage Effectiveness)1.1–1.58 ×Overhead multiplier on IT energy for cooling and power delivery. Effective energy = base × (PUE / baseline 1.2).Uptime Institute Global Data Center Survey / IEA
PUE presetValueNote
Hyperscaler best1.1×Best-in-class hyperscaler data center.
Typical hyperscaler1.2×Typical hyperscaler — assumed in the base figure.
Average data center1.4×Average enterprise / colocation data center.
Global average1.58×Global data-center average.

Statistical limitations

  • A standard run is n = 7 queries. The Step 2 aggregate reports min / median / max / standard deviation per mode — descriptive statistics only, not a statistically powered comparison.
  • There is no significance testing and no golden set. A 50–100 question benchmark with expected sources (to score answer correctness and citation quality, not just retrieval relevance) is the planned next step.
  • Relevance is a lexical retrieval proxy, not answer correctness (see “Measured vs modeled”).

Everyday equivalents

The car-km and phone-charge comparisons are rough conversion factors for intuition only — not a claim about any specific vehicle or phone.

FigureValueWhat it meansSource
Passenger car tailpipe emissions200 gCO₂/kmRough conversion factor for intuition, not a claim about any specific vehicle.EPA / EEA typical passenger-car average
Smartphone full charge8 gCO₂Rough conversion factor for intuition only.EPA equivalencies (approx.)

All sources

Spotted an error or a better source? ragornot is open source — open an issue.