Estimate the emissions of third-party AI API calls from model and request characteristics when the hardware is not accessible
#00166
When a generative model is called through a provider's API, hardware cannot be metered. Estimate per-request energy and CO2 from model size, token counts, and data-centre assumptions using a life-cycle method, giving API consumers an impact figure they otherwise cannot obtain.
Parent issue
#00164 The carbon footprint of software and AI compute is rarely measured, so it cannot be managed
Sustainable Development Goals
Location
Description
The proposal
Patch the provider's client library so each request is wrapped with an impact calculation derived from the chosen model, input/output token counts, and request latency, returning the estimate attached to the response.
Why it works
API consumers have no hardware access, so direct measurement is impossible and a model-based estimate is the only route to a per-request figure. A bottom-up life-cycle approach can cover both usage (energy) and embodied (hardware manufacturing) impacts, and is sufficient for comparing models, prompts, and providers relatively.
Where it fits
Applications built on hosted LLM or generative APIs (chatbots, retrieval-augmented generation, agents) where the team wants a footprint per call rather than an after-the-fact org-level estimate.
Trade-offs and limitations
Estimation carries large uncertainty because providers rarely disclose model size, hardware, or data-centre efficiency, so architectures are assumed when undisclosed and a fixed worldwide-average electricity mix is often used. The method typically excludes model training, data collection, networking, and end-user devices, and is usually scoped to text-to-text generation. Absolute numbers are weaker than the relative comparisons the method supports.
Sub-issues
0Case studies
1