carbon-aware-scheduler

name

carbon-aware-scheduler

description

Design time-shifting of flexible workloads (batch jobs, CI, training, backups, crons) to hours and regions when grid electricity is cleanest, using carbon-intensity signals like Electricity Maps, WattTime, or the Carbon Aware SDK. Use this skill whenever the user mentions carbon-aware computing, scheduling flexible/deferrable jobs, demand shifting, running workloads when energy is clean, or asks how to reduce the carbon intensity (not just amount) of their compute. Part of Lean Agentic AI Skills; emits schedule designs plus lean-findings.json.

Carbon-Aware Scheduler

Advisor skill — this is the suite's only skill that primarily moves I (carbon intensity), the term code alone can't touch. Input: job inventory (what runs, how often, deadline flexibility), regions in use. Output: a schedule design + lean-findings.json (findings = shiftable jobs currently running carbon-blind).

The same kWh emits several times more carbon on a coal-heavy evening grid than a solar-rich afternoon. Work that can wait should wait for clean power.

Subject type: emit subject.type: "architecture" in findings.

Procedure

1. Classify each job's flexibility: hard-realtime (never shift — mark passed), deadline-flexible (must finish by X — shift within window), fully elastic (nightly batch, training, backfills — shift freely), spatially flexible (can run in any region — shift in space, not just time).
2. Pick the signal: Electricity Maps API, WattTime, or the GSF Carbon Aware SDK (wraps both); UK: National Grid carbon intensity API. Forecast endpoints matter more than live ones — you schedule against the forecast.
3. Design the mechanism, simplest that works:
   • Static windows — if the region's clean hours are predictable (solar regions: midday), a plain cron change is 90% of the win at 0% of the complexity. Recommend this first.
   • Threshold gating — job wrapper checks forecast, runs when intensity < threshold or deadline forces it. Include the deadline-forcing branch ALWAYS (a job that never runs because the grid never got clean is an outage, not a win).
   • Orchestrated — Kubernetes (KEDA carbon-aware scaler), Airflow sensor tasks, or cloud scheduler + function gate for fleets.
4. Emit findings for each shiftable-but-unshifted job class, with the concrete mechanism as the fix.

Trade-offs to always name

Latency to results (name the delay each job tolerates), clustering risk (everything piling into the same clean window — stagger), spot-price interactions (clean hours aren't always cheap hours), and the honesty ceiling: shifting doesn't reduce energy used, only its carbon intensity — pair with E-reduction skills, never present shifting as a substitute for efficiency.

Honesty rules

Intensity varies by grid; never quote gCO2/kWh figures without a source for the user's actual region. "Midday solar dip" logic applies to solar-heavy grids only — check the region before hand-waving.

Not this skill's job

Choosing regions permanently (region-selector), making jobs batchable (inference-placement-advisor, architecture work).