# Limits and what we don't claim

A defensible number needs a clear scope. This page is the scope.

## What the numbers cover

- **Inference compute energy** for the model that served the request,
  using the EcoLogits v0.4 formula and the active-parameter count.
- **Grid carbon intensity** of the region the upstream served from,
  using IEA annual averages.
- **One step of the response.** A single request, end-to-end.

That's it.

## What the numbers do not cover

### Training emissions

We report inference only. Training a frontier model has a much
larger and harder-to-attribute footprint, and folding a "share of
training" into per-request numbers depends on assumptions (how many
requests will the model serve in its lifetime?) that are
unverifiable. We'd rather under-report inclusively than make up a
number.

### Hardware manufacturing

GPUs have an embodied carbon footprint from manufacturing. There is
not yet a defensible way to allocate it per token. Some
methodologies amortise it across the GPU's expected lifetime; the
amortisation depends on assumptions we don't have.

### Real-time grid mix

We use annual averages by region. Live carbon-aware routing — picking
the region whose grid is currently cleanest — is a roadmap feature,
not a current one.

### Embedding workloads

The EcoLogits formula was derived for decoder-only autoregressive
models. Encoder-only embedding models have a meaningfully different
compute profile. We currently *do not* report eco numbers for
embedding requests; the response carries no `eco` block. Modelling
embeddings properly is on the roadmap.

### Tool-call orchestration

When a single user-facing operation requires multiple LLM calls
(e.g. an agent that thinks-then-acts-then-thinks), each call gets
its own number. The aggregate footprint of a multi-step operation is
the sum of those numbers. We do not do that aggregation
automatically; that is your application's job.

### Browser, mobile, and on-device inference

Inference that doesn't go through the gateway doesn't appear in the
dashboard. The numbers describe what we measure, not the totality of
your AI footprint.

## What the numbers are *estimates of*

- An estimate, not a measurement. We do not have a wattmeter on the
  upstream provider's GPU.
- A model-class estimate, not a per-request measurement. Two requests
  for the same model with the same token count get the same number.
- An average over hardware, not a number specific to the GPU
  generation that served your request. Newer hardware is generally
  more efficient; the formula does not yet reflect generation.

## What we explicitly will not say

- "X grams CO₂e saved by using LowRouter."
  - We don't know what your counterfactual is. The eco-impact widget
    on the dashboard offers a comparison against a *baseline you
    choose*. That comparison is what it claims to be — a comparison
    against your chosen baseline.
- "Carbon-neutral", "net-zero", or "sustainable" applied to any
  individual request.
  - The numbers we publish exist in service of *better-informed
    decisions*, not certifications. Certifications require an audit
    we are not the right party to perform.
- "Independently verified" beyond what is true.
  - The EcoLogits methodology is published; the IEA data is
    published. Our application of them is auditable from the source
    code. There is no third-party certification of the per-request
    numbers themselves.

## How to read the numbers

- For ranking: comparing requests within a single
  `methodology_version` and `accuracy` band is meaningful.
- For absolute claims: take the band into account. A `gross` number
  is right within a factor of two; quoting it to three significant
  figures is a category error.
- For reporting: the numbers are appropriate for an internal
  dashboard or a "best-effort estimate" line in a sustainability
  report. They are not appropriate as the basis for a public
  emissions disclosure without acknowledging the methodology and its
  uncertainty.

## Reproducibility

Every estimate can be reproduced from public inputs:

1. Get `resolved_model`, `region`, `total_tokens`, and
   `methodology_version` from the generation record.
2. Look up the model's active parameter count in the
   [EcoLogits registry](https://ecologits.ai) for that version.
3. Apply the formula on the [methodology page](methodology) with the
   coefficients of that version.
4. Look up the grid intensity for that region in the IEA dataset
   referenced by the version.
5. The result should match the stored `eco.carbon_g` to within
   floating-point rounding.

If your reproduction diverges, that's a bug — please
[file an issue](https://github.com/carbonifer/lowrouter/issues).