How EcoRouter measures AI efficiency
EcoRouter measures what it can observe directly, calculates comparisons from those measurements, and clearly labels estimates where direct measurement is not possible. This page explains which is which.
Use only as much AI as you need
EcoRouter analyses each request and routes it to an appropriately capable model rather than automatically using the largest one available. Most questions do not need a frontier model; some do. The judgement is which.
Efficiency does not mean deliberately choosing a model that fails the task. A route that produces an inadequate answer has not saved anything — it has moved the cost onto the person who has to ask again.
Measured, calculated, estimated
Not everything EcoRouter reports is the same kind of fact. Three categories, always distinguished:
Measured
Directly observed from the real provider interaction.
- Selected model and provider
- Input tokens
- Billable output tokens
- Latency
- Number of attempts
- Underlying inference cost
Calculated
Derived arithmetically from measurements and configured reference data.
- Configured baseline cost
- Estimated cost saving
- Routing distribution
Estimated
Requires assumptions, not just observation. Labelled wherever it appears.
- Estimated relative compute reduction
An EcoReceipt marks each figure with its category. If something is an estimate, it says so where you read it — not in a footnote.
The configured frontier baseline
Savings are expressed against a configured frontier baseline: a representative frontier model, chosen in advance and versioned, used as a consistent comparison point.
What it is not, stated explicitly:
- Not necessarily the most expensive model available.
- Not a claim that every other AI product would have used that model for your question.
- Not selected after seeing the result. The baseline is fixed before the request is routed, so it cannot be chosen to flatter the outcome.
That last point is the one that matters. A baseline picked after the fact can produce any saving you like.
Why we say relative compute, not kilowatt-hours
EcoRouter reports an estimated relative compute reduction rather than energy, carbon or water. That is a deliberate limit, not a gap we intend to paper over.
Providers do not publish per-request energy draw, the hardware a request landed on, the utilisation of that hardware, or the carbon intensity of the grid supplying it at that moment. Without those, a figure in kWh or grams of CO₂ would be a number with a unit attached — not a measurement.
So EcoRouter says the narrower thing it can actually support: a comparative estimate of how much less computational work the selected route likely represents against the configured baseline. It is directional. It is not a physical measurement, and we do not present it as one.
Cost
Underlying inference cost is calculated from provider-reported usage and configured provider pricing. Because provider pricing changes, the pricing assumptions are versioned — so an old EcoReceipt can still be read against the prices that applied when it was issued.
Underlying inference cost and any future customer billable price are separate figures and will stay separate. EcoRouter’s commercial margin must never contaminate the efficiency measurement, because a saving measured against our own pricing would not be a measurement of anything.
The EcoReceipt
An EcoReceipt is the user-facing record of one routing decision. Depending on what the provider reported, it can show the routing tier, tokens in and out, underlying inference cost, the configured baseline, estimated savings, estimated relative compute reduction, and a short explanation of why that route was selected.
The point is to make normally invisible infrastructure legible. What it does not show is the internal scoring — the capability scores and routing weights are how EcoRouter works, not what it measured.
Routing modes
- Eco — prioritises finding a lower-resource option expected to be adequate.
- Balanced — weighs efficiency and capability together. The default.
- Max — places greater weight on capability strength.
Max does not mean “use the most expensive model”. It shifts how much capability headroom EcoRouter insists on; if a mid-tier model clears that bar comfortably, Max will still choose it.
Limitations
Where this methodology is weak, in our own words rather than someone else’s:
- Providers report usage differently, and some fields are absent entirely. A missing figure is recorded as unknown, never as zero.
- Model pricing changes, sometimes without notice. Figures are only as current as the pricing version they were issued under.
- Model characteristics evolve. A model that cleared a capability bar last month may behave differently after an update.
- Environmental estimates rest on assumptions about relative computational intensity, which are not directly observable.
- Request-level physical infrastructure telemetry does not exist at the provider layer.
- Routing is an engineering judgement. Two models will not produce identical output, and a smaller model is sometimes wrong where a larger one would not have been.
Versioning
EcoRouter versions the assumptions an EcoReceipt depends on: the model registry, provider pricing, the routing policy, the configured baseline, and the estimation methodology. Each receipt is stamped with the versions in force when it was issued.
This is what makes a historical receipt interpretable. A price change tomorrow must not silently rewrite what an answer cost today.

Efficiency in AI is not only about making models more efficient. It is also about becoming more intelligent about when — and how much — generation is necessary.
Try EcoRouter