Where the inputs come from
The estimate is driven by three fields you declare per model, in the Metrics section of the model declaration form (Governe → Models → Add/Edit model → Advanced):
Prisme.ai publishes recommended values for these fields per model in its reference catalogue, and can apply them to your models in bulk.
Calculation
For a call within input tokens and out output tokens, and a model whose declared energy per token is ept:
1. GPU energy
Input tokens (encoding) are counted at ~33% of an output token’s energy:2. Server overhead
A fixed server draw of 0.1 kW over an estimated 0.02 s of processing per token:3. Datacenter efficiency (PUE)
The raw energy is scaled by the Power Usage Effectiveness of the datacenter:4. CO₂eq emissions
The energy is converted with the grid emission factor of the region the model runs in:Setting the region
The region only sets the emission factor above; it has no effect on routing. By default a model takes it from the provider entry that serves it, resolved at every call, so moving a model to another provider entry or region updates its footprint immediately:- a provider entry can declare its region in Govern → Providers (
carbon_region) — set it for providers without a region of their own (OpenAI, Azure OpenAI, Anthropic, OpenAI-compatible); - otherwise, for AWS Bedrock:
- a cross-region inference profile (model id starting with
global.,eu.,us.,us-gov.,apac.,jp.,au.) can run in any region of its geography, whatever the entry’s region:global.→world,eu.→eu-west,us.andus-gov.→us-east,apac.,jp.andau.→asia. The prefix is read on the id actually sent to AWS, so a model declared under an alias (model_aliases) follows its target; - any other model id uses the entry’s AWS region:
eu-north-*→eu-north; any othereu-*→eu-west;us-east-*andca-*→us-east;us-west-*→us-west;ap-*→asia; anything else →world;
- a cross-region inference profile (model id starting with
- for Vertex AI, the location of the entry’s host (
europe-west9-aiplatform.googleapis.com→europe-west9; no prefix meansglobal):europe-north1/europe-north2→eu-north; any othereurope-*→eu-west;us-west*→us-west;us-central1,us-east*,us-south1andnorthamerica-*→us-east;asia-*andaustralia-*→asia;globaland anything else →world; - with nothing from the provider, the region is
world.
region on POST /v1/models and PATCH /v1/models/{model_id} is optional: null or absent means “from the provider”, one of the six ids is an override, and any other value is refused with 400 INVALID_REGION. GET /v1/models/regions?model_id=… returns the six regions, the default (world) and what the provider gives that model (suggested, source).
5. Uncertainty range
Both energy and emissions are reported with a ±20% band (min = value × 0.8, max = value × 1.2).
Condensed formula
Worked example
A short call of 51 input + 18 output tokens on a model declared atept = 0.0000103 kWh/token, average PUE, us-west:
gpu_energy= (51 × 0.0000103 × 0.33) + (18 × 0.0000103) ≈ 0.000359 kWhserver_energy= 0.1 × (69 × 0.02) / 3600 ≈ 0.0000038 kWhtotal_energy= (0.000359 + 0.0000038) × 1.58 ≈ 0.000573 kWhgwp= 0.000573 × 0.352 ≈ 0.0002 kg CO₂eq (~0.2 g CO₂eq)
Result shape
Each call returns:The constants (0.33 input factor, 0.1 kW server draw, 0.02 s/token, PUE multipliers and regional emission factors, ±20% band) are fixed in the gateway. Only
energy_per_token and pue_profile are per-model, plus the optional region override; the region otherwise comes from the provider entry. A model with no energy_per_token reports pricing only and no footprint.details.region_source tells which rule picked the region: model (the model’s override), provider (the provider entry’s carbon region), bedrock-profile:<prefix> (a Bedrock cross-region profile such as eu.), bedrock:<AWS region>, vertex:<location>, or default (world). The same object is returned in usage.carbon of the chat completion and sent with the analytics.llm.completion event (carbon), so you can check which region each call was counted in.
Related
- Observability — where the aggregated Carbon (kg CO₂eq) card is surfaced
- Available Models — the governed model catalog
- Model Governance — access, routing and failover controls