Environmental impact

The environment_impact block reports a request's estimated environmental impact. On supported endpoints, the estimate comes back as a JSON field with the inference.

The field

{
  "environment_impact": {
    "energy_kwh": 0.00015,
    "carbon_g_co2": 0.06,
    "water_liters": 0.0002,
    "renewable_percent": 85,
    "pue": 1.18,
    "provider_id": "ovhcloud",
    "location": "FR"
  }
}

Where it appears

Coverage depends on the endpoint and on whether you stream. billing_cost follows the same pattern:

For Chat Completions streams, set stream_options.include_usage to false to opt out. See Streaming.

Images return their own energy_cost / credits_cost fields instead, and audio transcriptions return a plain transcript. Responses and Messages requests are still estimated and recorded — the numbers reach your usage dashboard, not the response.

Provider identity

provider_id is always a public provider ID, never the name of the deployment behind it. On dedicated capacity — hardware reserved for a single customer — provider_id is the public provider the capacity runs under (melious for our own) and location is null, because we don't publish where that hardware sits. Carbon is still calculated from that capacity's grid country.

When it's missing

A response can carry billing_cost without environment_impact:

• The calculation failed. We'd rather send nothing than zeros that read as "no impact".
• We couldn't safely resolve the public identity of the provider that served the request. Rather than risk exposing an internal name, we leave the block out.

Streams have a few more cases, all listed in Streaming.

How we estimate it

None of these numbers is a meter reading. Each request gets the same formula:

energy_kwh   = one GPU's TDP (kW) × request duration (h) × PUE
carbon_g_co2 = energy_kwh × grid carbon intensity (g CO₂ per kWh)
water_liters = energy_kwh × WUE (liters per kWh)

TDP (thermal design power) is the rated power of one GPU of the type the provider runs the model on. Request duration is how long the request took. PUE grosses that up to the whole facility — cooling, power conversion, lighting.

The formula is simple and works the same for every provider, which is why we use it. It's also wrong in two predictable directions:

• It overstates batched serving. A busy GPU works on many requests at once, but the formula books each one a full GPU at full power for its whole duration. On our own GPUs, measured energy in busy hours was a small fraction of what the formula adds up to.
• It leaves out idle power. A GPU that's switched on and waiting still draws power, and no request is booked for it.

Over a day the two errors partly cancel; which one wins depends on how busy the hardware was. We haven't solved this yet. GPUs do report their own measured energy, but no response carries it, and the per-request figure isn't corrected against it — treat environment_impact as a consistent estimate, not a measurement.

The eco flavor

Setting model: "<MODEL_ID>:eco" makes Melious prefer the providers running on greener grids for that model, even if they're not the cheapest or fastest.

It's not magic. Expect latency to tick up under eco — a provider with 95% renewables and 1.15 PUE may be a few hundred kilometers further from your request and a few tokens-per-second slower. This is a real trade-off, not a marketing one. See Routing.

What we don't count

Honest scope:

• Training emissions are not included. Per-request energy is inference only.
• Embodied carbon of the hardware isn't in the number. Some operators publish estimates; we don't surface them yet.
• Network transit — the energy to move your request to the data center and the response back — is negligible at single-request scale and isn't included.

We're aware this isn't a full life-cycle assessment. We picked the subset that's measurable per-request and honest to report.

Using it

A few practical uses:

• Aggregate to a dashboard. Sum carbon_g_co2 over all your traffic to get a real monthly carbon figure for your LLM work.
• Gate on thresholds. renewable_percent is fixed per provider, so a bar you set is really a list of providers you'd rather avoid. Prefer :eco routing over retrying — a retry that lands on the same provider returns the same number.
• Compare providers. provider_id with pue, renewable_percent, and location tells you how each provider's facility and grid compare. Treat energy_kwh per token as a rough signal only: it's request duration times the GPU's rated power times PUE, so a slower provider looks worse on the same hardware.

For responses that carry the field, none of this requires extra requests or a separate API — the estimate is already there. For Responses and Messages, use the usage dashboard instead.

Related

Providers lists who runs what and where. Routing covers routing preferences, including eco. Response shape details per endpoint: Chat completions, Embeddings, Rerank. Reading the fields off a stream: Streaming.