Green Observal: a carbon & sustainability layer for AI agents, MCPs, and tools

[Apoorvgarg-creator]

Summary

Observal already traces every agent run, MCP call, and tool invocation. The same telemetry pipeline can power a sustainability layer that turns those traces into carbon, energy, and water-use metrics — so teams can see, attribute, and reduce the environmental cost of running AI.

This issue proposes a "Green Observal" initiative: a first-class layer + dashboard that measures the carbon footprint of every component type in the registry (agents, MCP servers, skills, hooks, evals) and helps the community make AI usage more sustainable.

Motivation

LLM-powered coding agents are becoming the default developer tool, and their environmental cost is largely invisible:

• A single agent session can fan out into dozens of LLM calls, MCP roundtrips, and tool executions — each with non-trivial energy use.
• Carbon intensity varies 10–20× by region and time of day, but no agent stack today exposes this.
• Eval loops and "agent swarms" amplify cost: re-running the same prompt 100× during eval can dwarf a real production run.
• Teams have ESG reporting obligations but no per-agent / per-MCP attribution.

Observal is uniquely positioned to do this because the spans already exist. We just need to enrich them.

Proposal

1. Carbon model layer (backend)

Extend the OTEL collector + worker to compute per-span emissions:

• LLM spans → tokens_in, tokens_out, model → energy estimate via published model cards (e.g. ML.energy leaderboard, EcoLogits, AI Energy Score).
• MCP / tool spans → wall-clock CPU time on the shim → energy via a configurable kWh_per_cpu_hour factor.
• Region awareness → resolve grid carbon intensity from ElectricityMaps / WattTime APIs based on the deployment region (or the user's home region for local IDE runs).
• Emit three new attributes on every span:
  • sustainability.energy_wh
  • sustainability.co2e_g
  • sustainability.water_l (optional)

Backed by a pluggable CarbonEstimator interface so the community can swap in better models as research improves.

2. Registry metadata

Add an optional sustainability: block to the agent/MCP YAML so publishers can declare:

• Default model + expected token budget per task
• Whether the component supports caching / batching
• A "green score" that the registry computes from real telemetry once the component has enough runs

This makes sustainability a first-class signal when discovering components — like stars or downloads.

3. Sustainability dashboard (Grafana + web UI)

A new dashboard with:

• Footprint over time — gCO₂e per session, per agent, per org
• Top emitters — which agents / MCPs / models burn the most
• Region & time-of-day heatmap — when is your usage cleanest?
• Eval cost panel — emissions from eval runs vs. production runs (often shocking)
• Savings recommendations — e.g. "switching agent X from Opus to Haiku for triage saves ~Y kg CO₂e/month at current usage"

4. Eval-aware budgets & policies

Optional guardrails surfaced via hooks:

• "Block this run if it would exceed the org's daily carbon budget"
• "Warn when an eval suite is about to emit > N kg CO₂e"
• "Prefer cached / smaller-model paths during high grid-carbon hours"

These reuse existing hook + policy plumbing — no new enforcement engine needed.

Why this fits Observal specifically

• Not greenwashing — every number is grounded in a real span we already collect.
• Reuses the pipeline — OTEL → ClickHouse → Grafana is already there.
• Community flywheel — registry metadata + real telemetry lets the community converge on genuinely efficient agents and MCPs.
• Differentiator — no other agent observability tool ships this today.

Open questions for the community

1. Estimation methodology — start with EcoLogits / ML.energy, or build our own from first principles?
2. Scope — Scope 2 (electricity) only, or include Scope 3 (embodied hardware, training amortization)?
3. Local vs. hosted models — how do we attribute emissions for self-hosted vLLM / Ollama runs where we have real GPU metrics?
4. Privacy — region/grid lookups can leak coarse location. Opt-in by default?
5. Default unit — gCO₂e per session, per 1k tokens, or per "useful task completed"?

Prior art / references

• ML.energy leaderboard
• EcoLogits (genai-impact)
• AI Energy Score (HuggingFace + Salesforce)
• Green Software Foundation — Software Carbon Intensity (SCI) spec
• ElectricityMaps / WattTime grid APIs

Call for collaborators

Looking for input from:

• Folks running large eval suites (you'll feel this first)
• Anyone with ESG reporting requirements
• Researchers in green AI / sustainable ML
• Maintainers of MCP servers who want to publish a green score

If there's enough interest, the next step is a small RFC PR adding the sustainability.* span attributes and a v0 estimator behind a feature flag.

[dhanpraja231]

This sounds fantastic, I think an observability tool is the best way to calculate this.

Observal is uniquely positioned to handle this.

[Haz3-jolt]

+1 great idea

[ShaanNarendran]

+1 would love to work towards this