I stumbled across Carbon-aware electricity pricing during a break and ended up poking at it far longer than planned. The idea is simple but useful: track daily electricity pricing across 38 grids so engineers can think about when workloads run, not only how much compute they consume.
That distinction matters for AI and infrastructure teams. A batch inference job, container image build, backup, or large test suite does not always need to run immediately. If pricing data can act as a scheduling signal, teams may be able to shift flexible workloads toward cheaper or cleaner periods without redesigning their entire platform.
My first impression is that this works best as an observability input rather than an automatic control plane. The daily granularity is approachable, but it is also a limitation. Production schedulers often need hourly or regional data, confidence intervals, historical comparisons, and a clear explanation of how each grid value was calculated.
A quick way to inspect the project is intentionally low-friction:
docker run --rm curlimages/curl:8.10.1 \
-L https://carbonawarepricing.com/
For a real deployment, I would ingest the published data into an internal service, attach timestamps and source metadata, then expose only a small policy such as:
workloads:
nightly-evals:
allowed_window: "low-cost-or-low-carbon"
max_delay_hours: 12
require_manual_override: true
The important engineering boundary is governance. Do not let a pricing feed silently reschedule customer-facing workloads, security scans, or disaster-recovery jobs. Keep the raw data, validate unexpected changes, and make the decision auditable.
Things I would watch before production:
The community signal is still small, but the concept is refreshingly practical. It turns sustainability from a dashboard metric into a scheduling consideration, while leaving room for teams to make conservative infrastructure choices.