DEV Community

Mohd Altamish
Mohd Altamish

Posted on

How I Built Carbon Tracker — An AI Agent That Calculates CO2 Emissions from CI/CD Pipelines (Won GitLab AI Hackathon)

I just won an Honorable Mention at the **GitLab Duo Agent Platform

Hackathon 2026** — a global competition with 6,971 participants and

which has a total $65,000 prize pool — with a project called Carbon Tracker I won in Sustainable Agent Category

Built it solo. In 5 days. With zero prior GitLab experience.

This is the full story — what I built, why, how it works, and
everything I learned.


🌍 The Problem Nobody Is Talking About

I was reviewing a failed CI/CD pipeline when a thought hit me:

This pipeline just retried 3 times. How much electricity did that waste?

I searched for a tool that could answer that. Nothing existed.
No GitLab feature. No third-party plugin. No open source project.

Developers obsess over pipeline speed, test coverage, and code quality —
but the carbon footprint of their CI/CD infrastructure is completely
invisible.

Here's the scale of the problem:

  • The software industry contributes 2–3% of global carbon emissions
  • A team of 10 developers running 20 pipelines/day emits close to 1 tonne of CO2 per year — just from pipelines
  • A single flaky test retrying twice, running 20x/day = 440 kg CO2 per year — from one test

Nobody knows. Nobody tracks it. No tool exists for it.

Until now.


🌱 What Is Carbon Tracker?

Carbon Tracker is a 3-agent AI flow built on the
GitLab Duo Agent Platform that:

  • 🔁 Triggers when you mention it in any GitLab Issue or MR
  • 📊 Calculates CO2 emissions per job using a physics-based energy model
  • 🤖 Uses Claude (Anthropic) to detect waste patterns and generate tips
  • 💬 Posts a full sustainability report as an MR/Issue comment automatically

The entire project is 2 YAML files.
No servers. No databases. No infrastructure to maintain.


⚙️ Architecture — How the 3 Agents Work Together

User mentions @ai-carbon-tracker-flow in an Issue or MR

Agent 1: pipeline_fetcher
Tools: get_merge_request, list_merge_requests
→ Fetches job names, durations, statuses

Agent 2: carbon_calculator
→ Applies energy model
→ Detects waste patterns
→ Generates full markdown report

Agent 3: report_publisher
Tools: create_merge_request_note, create_issue_note
→ Posts report as MR/Issue comment

Report Live ✅

Each agent has one job. Output passes to the next via
from/as bindings in the flow definition.

This is genuine multi-agent orchestration — not a chatbot.


🔬 The Carbon Model — Simple Math, Real Impact

The core logic in one sentence:

Servers use electricity. Electricity produces CO2.
We know how long each job ran. So we can calculate the CO2.

Step 1 — Energy consumed per job:
E(kWh) = (duration_seconds / 3600) × (150W / 1000)

Step 2 — CO2 emitted per job:
CO2(g) = E(kWh) × 475

Step 3 — Waste multiplier for retried jobs:
CO2_total = CO2_job × (1 + N_retries)

Constants used:


| Parameter | Value | Source |
|-----------|-------|--------|
| Runner wattage | 150W | Typical shared GitLab runner |
| Carbon intensity | 475 gCO2/kWh | IEA Global Average 2024 |
| Km equivalent | CO2g ÷ 150 | Average car: 150gCO2/km |
Enter fullscreen mode Exit fullscreen mode

Real example:
test:unit ran 45 minutes
45 ÷ 60 = 0.75 hours
0.75 × 150W = 112.5 Wh
112.5 ÷ 1000 = 0.1125 kWh
0.1125 × 475 = 53.4g CO2
= Driving 0.35 km in a car
From one job. One pipeline. One day.


📊 Real Output From a Real Pipeline

This is an actual report Carbon Tracker auto-posted on my MR
during development:

Pipeline #2405610327 — Live Report

⚡ Energy 💨 CO₂ 🚗 Equivalent
0.0034 kWh 1.62g ~0.011 km driven

📋 Job Breakdown

Job Duration Energy (kWh) CO₂ (g) Status
unit-test-job ~63s 0.002625 1.247g
lint-test-job ~13s 0.000542 0.257g
build-job ~3s 0.000125 0.059g
deploy-job ~3s 0.000125 0.059g

📊 CO₂ Distribution

Job Share %
unit-test-job 🟧🟧🟧🟧🟧🟧🟧🟧 77%
lint-test-job 🟧🟧 16%
build-job 🟨 4%
deploy-job 🟨 4%

🔥 Waste Patterns Detected:

Artificial sleep in unit-test-job → 77% of total CO₂
Config-only change triggered full pipeline → wasted 1.56g
Deploy ran on non-production branch unnecessarily

💡 Optimization Tips:

Replace sleep with real tests → saves ~96% emissions
Add path rules for config changes → saves 1.56g/run
Restrict deploy to main branch → saves 0.059g/push

🏅 Sustainability Score: B+
🤖 Carbon Tracker · GitLab Duo + Claude (Anthropic)

Claude identified that a sleep 60 command was responsible for
77% of the pipeline's total CO2. That's the kind of specific,
actionable insight that makes this tool genuinely useful —
not just a novelty.


🛠️ The Code — How It's Built

flow.yml — The 3-Agent Orchestration

name: "Carbon Tracker Flow"
description: "Calculates CO2 emissions per CI/CD pipeline job."
public: true
definition:
  version: v1
  environment: ambient
  components:
    - name: "pipeline_fetcher"
      type: AgentComponent
      prompt_id: "fetch_prompt"
      inputs:
        - from: "context:goal"
          as: "goal"
      toolset:
        - "get_merge_request"
        - "list_merge_requests"
      ui_log_events:
        - on_agent_final_answer

    - name: "carbon_calculator"
      type: AgentComponent
      prompt_id: "calculate_prompt"
      inputs:
        - from: "context:goal"
          as: "goal"
        - from: "pipeline_fetcher:output"
          as: "pipeline_data"
      ui_log_events:
        - on_agent_final_answer

    - name: "report_publisher"
      type: AgentComponent
      prompt_id: "publish_prompt"
      inputs:
        - from: "context:goal"
          as: "goal"
        - from: "carbon_calculator:output"
          as: "carbon_report"
      toolset:
        - "create_merge_request_note"
        - "create_issue_note"
      ui_log_events:
        - on_agent_final_answer

  routers:
    - from: "pipeline_fetcher"
      to: "carbon_calculator"
    - from: "carbon_calculator"
      to: "report_publisher"
    - from: "report_publisher"
      to: "end"

  flow:
    entry_point: "pipeline_fetcher"
Enter fullscreen mode Exit fullscreen mode

agent.yml — The Standalone Agent

yaml
name: "Carbon Tracker Agent"
description: "Calculates CO2 emissions for CI/CD pipeline jobs."
public: true
system_prompt: |
  You are the Carbon Tracker Agent running inside GitLab Duo.
  Calculate CO2 per job:
    energy_kwh = (duration_seconds / 3600) * 150 / 1000
    co2_grams  = energy_kwh * 475
  Generate a markdown report with job breakdown and tips.
  End with: "🤖 Carbon Tracker · GitLab Duo + Claude (Anthropic)"
Enter fullscreen mode Exit fullscreen mode

Why 3 Agents Instead of 1?

Approach Problem
Single agent Gets confused doing fetch + calculate + publish
3 agents Each has one job — focused, debuggable, reliable

Separating concerns across agents produces dramatically better
output quality
from Claude. Each prompt is laser-focused on
one task, which means each agent does it exceptionally well.


🚧 Challenges I Ran Into

1. Learning GitLab Duo From Zero

I had never used GitLab before this hackathon.

Learning the Agent Platform, Flow schema, YAML configuration,
CI/CD variables, and the tool system — simultaneously — under
a 5-day deadline was the steepest part of the entire build.

2. YAML Schema Validation Hell

The toolset format for flow components was completely
undocumented for custom flows. I went through this loop:

# Attempt 1 — Failed ❌
toolset:
  - get_merge_request

# Attempt 2 — Failed ❌
toolset:
  - tool_name: get_merge_request

# Attempt 3 — Failed ❌
toolset:
  - tool_name: "get_merge_request"

# Final — Passed ✅
toolset:
  - "get_merge_request"
Enter fullscreen mode Exit fullscreen mode

Each attempt was a full commit → CI pipeline → read error → fix
cycle. That loop taught me more about the platform than any
documentation could have.

3. No Official Runner Energy Data

GitLab's API doesn't expose runner power consumption anywhere.

I researched cloud compute energy benchmarks from AWS, GCP,
and Azure instance specs and settled on 150W as a
physically grounded constant — accurate enough to be meaningful
without overclaiming false precision.

4. Prompt Engineering for Consistent Output

Getting Claude to produce a clean, consistently formatted
markdown table on every single run — with specific actionable
tips referencing actual job names, not generic advice — required
significant iteration across all 3 agent system prompts.

The key insight: shorter, more focused prompts per agent
outperform a single long prompt trying to do everything.


✅ Accomplishments

  • ✅ Built a fully working multi-agent flow on GitLab Duo with zero prior GitLab experience
  • ✅ Designed a physics-based carbon model grounded in real IEA 2024 energy data
  • ✅ Created what is (to my knowledge) the first per-job CO2 breakdown tool for GitLab CI/CD pipelines
  • ✅ Implemented genuine 3-agent orchestration — not a chatbot, a real automated multi-step workflow
  • ✅ Made sustainability completely frictionless — developers get carbon data without changing their workflow
  • ✅ Shipped from zero GitLab knowledge to a validated, catalog-published flow in 5 days

🧠 What I Learned

Technical:

  • How AgentComponent steps chain via routers and from/as input bindings in GitLab Duo Flows v1
  • Prompt engineering for focused, single-purpose agents produces far better output than one large prompt
  • How to model real-world energy consumption from infrastructure metadata using public carbon intensity data
  • How Claude's system prompts can enforce structured, consistent output formats across automated pipelines

About building under pressure:

  • Ship fast, debug faster — each failed pipeline taught me something the docs didn't
  • Undocumented = opportunity. Nobody else figured it out either, which means fewer competitors
  • The best projects solve problems that feel obvious in hindsight but nobody has tackled yet
  • A first-year student can compete globally and win — the internet doesn't care about your year of study

🔮 What's Next for Carbon Tracker

  • Region-aware carbon intensity — replace global 475 gCO2/kWh with location-specific values using runner metadata
  • Project carbon dashboard — cumulative Wiki page with monthly emissions trend graphs
  • Carbon budget alerts — notify teams when monthly pipeline emissions exceed a threshold
  • MR carbon diff — predict how a code change affects emissions before merging
  • Real runner wattage — per-runner power draw via GitLab runner metadata API
  • Weekly carbon digest — Slack/email summary of team-wide emissions and top savings

🏆 The Result

Won Honorable Mention — GitLab Duo Agent Platform
Hackathon 2026

6,971 global participants
Won: $500 prize cash
Solo build
5 days
First year B.Tech CSE student
Zero prior GitLab experience


🔗 Links


💬 Let's Talk

If you're building on GitLab Duo Agent Platform and have
questions about flows, toolset declarations, or multi-agent
orchestration — drop a comment. Happy to help.

If your team runs CI/CD pipelines and cares about your
carbon footprint — Carbon Tracker was built for you. 🌱


Built with GitLab Duo Agent Platform + Claude (Anthropic)

`

Top comments (0)