Environmental impact
What the environment_impact block on every response actually means
Every Melious response includes an environment_impact block. It's a JSON field, not a dashboard tile — the measurement comes back 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"
}
}| Field | Unit | Meaning |
|---|---|---|
energy_kwh | kilowatt-hours | Electricity consumed by the compute that served this request, grossed up by the provider's PUE. |
carbon_g_co2 | grams CO₂ | energy_kwh multiplied by the grid's carbon intensity at the provider's location at request time. |
water_liters | liters | Cooling water consumed — provider-reported, prorated per kWh. |
renewable_percent | 0–100 | Share of the provider's grid mix that's renewable right now. |
pue | ratio, ≥ 1.0 | The provider's Power Usage Effectiveness. Lower is better. |
provider_id | string | Which provider in our network actually served this request. |
location | ISO-3166 | Country code where the inference ran. |
Present on chat completions, messages, embeddings, reranks, images, audio, and streaming (in the final chunk).
How the numbers are computed
Per request, we measure: input tokens, output tokens, the model's measured energy-per-token at the serving provider, and the provider's PUE. Multiplied, that gives energy_kwh. Carbon is energy_kwh × grid_intensity_g_per_kWh where grid_intensity_g_per_kWh is fetched from electricity-map data for the provider's country at the time of the request. Water is the provider's reported cooling-water factor, prorated.
These are estimates. Energy-per-token is measured but varies with batch size and model state; grid carbon intensity is a national average for the hour, not a live reading at the data center's substation. We'd rather publish a calibrated estimate than nothing.
We don't add padding, round up, or pick the flattering provider — the numbers match what we use internally for billing energy. If a provider's PUE improves, the number on your responses drops the next day.
The eco flavor
Setting model: "glm-4.7:eco" (or preset: "eco") tilts routing 60% toward the environment dimension, 20% each to price and speed. In practice that means: among eligible providers for the requested model, we prefer the ones running on greener grids, 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_co2over all your traffic to get a real monthly carbon figure for your LLM work. - Gate on thresholds. Reject or retry if
renewable_percentdrops below a bar you've set internally. - Compare providers. Over a representative sample,
provider_idplusenergy_kwhper token tells you which partners are cleanest for the model you're running.
None of this requires extra requests or a separate API — the data is already in the response you asked for.
Related
Providers lists who runs what and where. Routing covers flavors and filters, including eco and max_carbon_intensity. Response shape details per endpoint: Chat completions, Messages, Embeddings.