Green Pipeline Optimizer

Inspiration

Every day, millions of CI/CD pipelines run across the software industry - and nobody thinks about the electricity they consume. We ran the numbers: a mid-size team running 50 pipelines a day on US East runners generates roughly 200 kg of CO2 per year just from CI/CD. That's the equivalent of driving 500 miles. Multiply that across thousands of GitLab teams and it adds up fast.

The frustrating part? Most of that energy is wasted - duplicate dependency installs, oversized runners for simple lint jobs, test suites that run on documentation-only changes. These are easy fixes, but teams don't make them because the waste is invisible.

We wanted to make it visible.

What it does

Green Pipeline Optimizer is a flow of two AI agents on the GitLab Duo Agent Platform that automatically analyzes your CI/CD pipelines and produces a sustainability report with actionable recommendations.

Agent 1 - Pipeline Carbon Analyzer calculates per-job carbon emissions using the Green Software Foundation's Software Carbon Intensity (SCI) methodology, now an ISO standard (ISO/IEC 21031:2024):

$$SCI = \frac{(E \times I) + M}{R}$$

Where $E$ is energy consumption in kWh, $I$ is the carbon intensity of the electricity grid (gCO₂eq/kWh), $M$ is embodied carbon from hardware manufacturing, and $R$ is the functional unit (one pipeline run).

Energy per job is estimated as:

$$E_{job} = \frac{(P_{cpu} \times t + RAM_{GB} \times 0.392 \times t) \times PUE}{1000}$$

Agent 2 - Green Optimization Advisor reads the carbon report alongside your .gitlab-ci.yml and produces ranked recommendations - each with an estimated CO₂ savings and a ready-to-paste code snippet. Recommendations span six categories: region selection (up to 86% reduction), dependency caching, conditional execution, runner right-sizing, pipeline restructuring, and schedule optimization.

The flow orchestrates both agents and posts a combined Green Pipeline Report as an issue comment after each pipeline run, complete with a per-job breakdown table and a sustainability grade (A through F).

Agent 3 - MR Carbon Diff monitors merge requests for CI/CD configuration changes. When a developer modifies .gitlab-ci.yml, this agent compares the before and after states, estimates the carbon impact of each change (new jobs added, runner sizes changed, caching added/removed), and posts a carbon diff table on the MR - showing the net CO₂ impact and projected sustainability grade. Think of it as a code review, but for your pipeline's carbon footprint.

How we built it

We started by researching the SCI specification and real-world carbon intensity data from Electricity Maps, Google Cloud Carbon Data, and AWS reports. We built a Python reference implementation of the calculator to validate our energy estimates against known benchmarks like the Eco-CI project.

From there, we designed two specialized agents with carefully crafted system prompts - one focused purely on measurement (with lookup tables for runner power draw, regional grid intensity, and embodied carbon coefficients), and one focused on optimization (with deep knowledge of GitLab CI/CD configuration patterns and their energy implications).

The agents are orchestrated as a GitLab Flow, triggered on pipeline completion events. We intentionally created an example .gitlab-ci.yml with common inefficiencies - no caching, duplicate npm install calls, oversized runners, lint in the wrong stage - so the optimizer has real problems to catch during demos.

Everything runs on Anthropic's Claude through GitLab Duo, which handles the reasoning needed to map raw pipeline metrics to meaningful sustainability insights.

Challenges we ran into

Estimating energy consumption without direct hardware telemetry is inherently approximate. CI/CD runners don't expose wattage or CPU utilization metrics through the GitLab API, so we had to build a model based on runner size (vCPU count), job duration, and reasonable power draw assumptions derived from SPECpower benchmarks and cloud provider disclosures.

Balancing accuracy with usefulness was another challenge. We could have added dozens of parameters for users to configure, but that would kill adoption. Instead, we chose sensible defaults (1.2 PUE, 400 gCO₂eq/kWh for unknown regions) that produce directionally correct estimates - the goal is to show relative differences between jobs and highlight optimization opportunities, not to produce audit-grade carbon accounting.

What we learned

The single biggest lever for reducing CI/CD carbon isn't code optimization - it's region selection. Running the same pipeline in Stockholm (13 gCO₂eq/kWh) vs. Virginia (400 gCO₂eq/kWh) cuts emissions by 86%. Most teams pick their runner region for latency reasons and never reconsider it, even for jobs like nightly builds where latency doesn't matter.

We also learned that the GitLab Duo Agent Platform is surprisingly well-suited for this kind of "observe and advise" pattern - agents that watch for events, analyze data, and surface insights without requiring manual invocation.

What's next

We'd like to add historical trending - tracking SCI scores across pipeline runs and showing a carbon-over-time chart. Integration with the Electricity Maps API for real-time grid intensity (instead of static defaults) would improve accuracy significantly. And we'd love to see a "carbon budget" feature where teams can set a gCO₂eq threshold and the agent warns them when a pipeline exceeds it.

Built With

• anthropic-claude-(sonnet-4.6)
• carbon
• cloud
• electricity-maps
• gitlab-ci/cd
• gitlab-duo-agent-platform
• gitlab-rest-api
• green-software-foundation-sci-(iso/iec-21031:2024)
• python
• yaml