LowRouter

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 for that version.
  3. Apply the formula on the methodology page 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.