Your batch job starts the moment you click Submit. The Kubernetes pod spins up at 6 p.m. The model training run kicks off during the evening demand spike. Nobody asked whether the grid was burning coal or soaking up midday solar. The software treated every kilowatt-hour as identical.
It is not. On the California Independent System Operator (CAISO) grid, average life-cycle emissions intensity can swing from roughly 484 grams CO₂ equivalent per kilowatt-hour (gCO₂e/kWh) overnight to about 292 gCO₂e/kWh at midday, driven by solar availability (Meyer et al., 2025). In Germany, hourly factors have ranged from 37% to 141% of the annual average within a single year (Kannan et al., 2017). The same compute job, same code, same hardware, can produce very different carbon outcomes depending on when and where it runs.
Carbon-aware computing is the idea that software should know that difference and act on it: defer flexible workloads to cleaner hours, route batch jobs to greener regions, or throttle capacity when the grid is dirty. Not as a sustainability brochure. As scheduling logic.
Key Abbreviations in This Post
- CI (Carbon Intensity): Grams of CO₂ equivalent emitted per kWh of electricity consumed (gCO₂/kWh).
- MOER (Marginal Operating Emissions Rate): Emissions from the next unit of generation dispatched when demand changes.
- AEF (Average Emissions Factor): Annual or regional average CI; simpler but can misestimate avoided emissions.
- VCC (Virtual Capacity Curve): Hourly compute capacity limits that reshape flexible load to greener times (Google, 2022).
- SCI (Software Carbon Intensity): Green Software Foundation (GSF) rate metric for software emissions per functional unit.
- SLA (Service Level Agreement): Deadline or latency contract a job must meet.
- GSF (Green Software Foundation): Industry body behind the Carbon Aware SDK and SCI specification.
- KEDA (Kubernetes Event-Driven Autoscaling): Scaler framework that can pause workloads on external signals.
- CRD (Custom Resource Definition): Kubernetes extension for domain-specific scheduling policies.
The One-Minute Version
- Grid carbon intensity changes by hour and region because generation mix shifts with demand, wind, and solar (Carbon Intensity, n.d.; Meyer et al., 2025).
- Carbon-aware software uses live or forecast CI data to schedule deferrable work into lower-emission windows (Green Software Foundation [GSF], n.d.; Radovanovic et al., 2022).
- Three levers: temporal shifting (when), spatial shifting (where), and load shaping (how much capacity per hour).
- Google's Carbon-Intelligent Computing has run in production since 2020, using Virtual Capacity Curves to delay batch workloads to greener hours (Radovanovic et al., 2022).
- Developers can start today with the GSF Carbon Aware SDK, Python tools like cleanshift, or Kubernetes controllers. Savings of 16 to 41% are reported on flexible pipelines (Bhat et al., 2026; GridWise AI, n.d.).
- It only works for flexible workloads. User-facing latency-critical paths need different policies.
Why "A Kilowatt-Hour Is a Kilowatt-Hour" Is Wrong
Utility bills count energy, not emissions. Climate math needs both.
Electricity grids are dynamic systems. When demand rises at dusk, gas peaker plants often ramp up. When the sun is strong, solar displaces higher-carbon sources. Wind surges at night in some regions. Nuclear and hydro provide relatively steady low-carbon baseload. The result: carbon intensity curves that look nothing like flat lines.
Research on hourly accounting shows that using annual average emission factors can bias inventory estimates by up to 35% compared with hour-by-hour measurement in some regions (Lou et al., 2022). For load shifting specifically, marginal emission factors matter: they estimate what generator actually responds when you add or remove demand (Siler-Evans et al., 2012).
Carbon-aware computing treats electricity like a variable-price, variable-emissions commodity. The job is not just "use less power." It is "use power when the grid is cleaner, if you can."
Three Ways Software Can Shift Its Carbon Footprint
1. Temporal shifting (when)
Defer batch training, nightly ETL, report generation, or backup jobs to the lowest-carbon window before the deadline. A four-hour Spark pipeline due by 8 a.m. might sleep until 2 a.m. when wind output peaks instead of starting at 6 p.m. during a gas-heavy evening (GridWise AI, n.d.).
2. Spatial shifting (where)
Run the same container in a region with cleaner current or forecast CI. The GSF Carbon Aware SDK exposes endpoints like /emissions/bylocations/best to compare multiple cloud regions and pick the lowest-intensity location for a given time window (GSF, n.d.). Data gravity limits this: moving a 50 TB dataset across regions may cost more carbon than you save.
3. Load shaping (how much, each hour)
Instead of binary run-or-wait, cap hourly capacity for flexible workloads. Google's Carbon-Intelligent Computing System generates day-ahead Virtual Capacity Curves (VCCs): hourly CPU limits that preserve total daily capacity while starving dirty hours and filling green ones (Radovanovic et al., 2022). The same total work completes. The shape of demand changes.
How Carbon-Aware Scheduling Works in Practice
The pattern is consistent across hyperscale internal systems and open-source tools:
- Ingest carbon signals. Providers like WattTime, Electricity Maps, UK Carbon Intensity API, and grid operator feeds supply historical, live, and forecast CI by region (Carbon Intensity, n.d.; GSF, n.d.).
- Normalize units. The GSF Carbon Aware SDK converts heterogeneous provider formats into standard gCO₂/kWh (GSF, n.d.).
- Define workload policy. Label jobs as latency-critical, flexible, or batch. Attach deadlines, duration, and acceptable delay.
- Optimize the window. Search all valid start times before the SLA and pick the lowest total emissions contiguous window (GridWise AI, n.d.; cleanshift, n.d.).
- Execute and receipt. Run the job, log kg CO₂ avoided versus an immediate baseline. Some tools sign receipts for audit (ebb-ai, n.d.).
Example Python policy with cleanshift:
from cleanshift import find_cleanest_window, MockProvider
best = find_cleanest_window(
MockProvider(),
duration_hours=2,
max_delay_hours=24,
)
# Sleep until best.start_time, then run your training jobPolicies can go further: halt_if_dirty pauses a long job mid-run if CI spikes above a threshold, then resumes when the grid cleans up (cleanshift, n.d.). That is carbon-aware computing as process control, not just queue management.
Who Is Already Doing This?
Google: Carbon-Intelligent Computing at fleet scale
Since 2020, Google has operated a production Carbon-Intelligent Computing System across its data center fleet. It forecasts next-day carbon intensity, predicts flexible load, and generates Virtual Capacity Curves that limit hourly batch capacity during dirty periods while preserving daily throughput (Radovanovic et al., 2022). The same infrastructure later supported demand response during grid emergencies in Oregon, Nebraska, the U.S. Southeast, and Europe (Utility Dive, 2023). Carbon awareness became grid reliability tooling.
Green Software Foundation: the open standard layer
The GSF Carbon Aware SDK provides CLI, Web API, and client libraries so developers do not rebuild provider integrations. It aligns with the Software Carbon Intensity (SCI) specification, which defines carbon-aware behavior as software that adjusts consumption in response to the carbon intensity of the energy it uses (GSF, n.d.). SCI scores operational emissions as energy times grid CI plus embodied hardware costs, per functional unit.
Kubernetes-native schedulers
Patterns include KEDA scalers that scale to zero when CI exceeds a threshold, custom controllers that hold "carbon-deferred" jobs until the SDK returns an optimal window, and research systems like Carbon-Kube, which reduced CO₂ emissions on Spark pipelines by 41% with only 1.1 to 1.7% latency overhead in AWS EKS experiments (Bhat et al., 2026; Tekko, n.d.).
Agent and batch API integration
Tools like ebb-ai route deferrable Large Language Model (LLM) agent tasks through batch APIs during off-peak grid hours, claiming 40 to 70% lower carbon and roughly 50% lower cost when deadlines allow (ebb-ai, n.d.). Carbon awareness meets inference economics.
When It Works, and When It Does Not
| Workload type | Carbon-aware fit | Why |
|---|---|---|
| ML training, ETL, backups | Excellent | Hours of slack, high energy draw, clear deadlines |
| Overnight agent summaries | Strong | Deferrable, batch API compatible |
| Video rendering farms | Strong | Queue-based, deadline-driven |
| Interactive web APIs | Poor | Users expect sub-second response |
| Cross-region data pipelines | Mixed | Data gravity may erase spatial gains (Bhat et al., 2026) |
| Always-on inference at fixed SLA | Limited | Use right-sized models and clean-grid siting instead |
Carbon-aware scheduling is not a substitute for using less energy. It is a multiplier on top of efficiency. A smaller model on a clean grid at the right hour beats a frontier model running immediately on a coal-heavy evening.
Real-World Examples (Problem → Cause → Effect)
1. Nightly ML fine-tune on CAISO
Problem: A team fine-tunes a model every night. Jobs auto-start at 6 p.m. when engineers leave the office.
Cause: Cron triggers ignore grid CI. Evening is often gas-heavy as solar drops and residential demand rises (Meyer et al., 2025).
Effect: Carbon-aware wrapper defers the 3-hour job to the 11 a.m. to 2 p.m. solar window. Same SLA (results by 7 a.m.). Estimated 30 to 40% lower operational CO₂ for that job versus immediate start.
2. Spark pipeline with hard deadline
Problem: A daily analytics DAG must finish before 9 a.m. for executives. Default Kubernetes scheduler runs it at midnight.
Cause: Standard schedulers optimize for cluster utilization, not marginal grid emissions.
Effect: Carbon-Kube uses forecast-based time planning with SLA envelopes. In published experiments, CO₂ fell 41% with under 2% latency penalty (Bhat et al., 2026).
3. Grid emergency demand response
Problem: A regional grid faces peak stress during a heat wave.
Cause: Fixed compute load adds to peak demand when peaker plants are most carbon-intensive.
Effect: Google reduced data center power during requested windows using the same carbon-intelligent platform, supporting grid reliability in Oregon, Nebraska, and Europe (Utility Dive, 2023). Carbon-aware load shaping doubles as demand response.
4. "Green" chatbot with no deferral policy
Problem: A product team markets an AI assistant as sustainable but serves every query synchronously on demand.
Cause: No workload classification. Every request is treated as latency-critical.
Effect: Peak-hour inference on dirty grids. Fix: separate interactive path from deferrable background tasks (summaries, eval runs, log analysis) and apply carbon policy only where slack exists.
Building Carbon-Aware Software: A Practical Checklist
- Classify workloads. Tag jobs with priority: latency-critical, flexible, batch. Only the latter two defer.
- Attach SLAs. Every deferrable job needs a deadline and duration estimate.
- Pick a signal source. Start with Electricity Maps, WattTime, or a regional grid API. Use the GSF SDK to normalize (GSF, n.d.).
- Choose marginal or average CI consciously. Marginal rates better reflect avoided emissions from shifting load; averages are simpler for reporting (Siler-Evans et al., 2012; Lou et al., 2022).
- Integrate at the scheduler. Cron replacement, Kubernetes controller, CI pipeline gate, or Python wrapper around your training script.
- Emit receipts. Log baseline (run now) versus optimized (deferred) kg CO₂. Auditable metrics beat vague "we care" pages.
- Watch for rebound. Cheaper off-peak compute can increase total usage. Track absolute emissions, not just intensity (GSF, n.d.).
The Bigger Picture: From Carbon-Aware to 24/7 Clean Energy
Carbon-aware scheduling is a bridge strategy. It reduces emissions today on grids that still mix fossil and renewable generation. The long-term goal for many hyperscalers, including Google, is 24/7 carbon-free energy: matching every hour of consumption with clean supply, not just buying annual renewable credits (Utility Dive, 2023; Google Cloud, n.d.).
Until every hour is clean everywhere, timing matters. Software that treats the grid as a live signal, not a static utility bill, is one of the lowest-friction climate levers developers actually control. You do not need a new model architecture. You need a scheduler that reads the atmosphere.
What if software could choose the cleanest time to run? It already can. The data exists. The SDKs exist. Production systems at Google scale have done it for years. Open-source tools now bring the same idea to Kubernetes clusters, Python batch jobs, and agent workflows.
The constraint is not technology. It is workload design. Carbon-aware computing works when you admit that not every job needs to run right now, that a kilowatt-hour at noon is not the same as a kilowatt-hour at dusk, and that schedulers are climate policy encoded in cron syntax.
Defer the batch job. Shape the load curve. Print the receipt. Same software, cleaner hour, measurably less carbon. That is not a thought experiment. It is an engineering ticket waiting in your backlog.
References
- Bhat, S., Sirikonda, S. R., Katoch, V., & Jain, R. (2026). Carbon-Kube: A Kubernetes-native framework for multi-objective carbon-aware scheduling of big data pipelines. IEEE IEMECONTECH. https://doi.org/10.1109/iementech202669403.2026.11434192
- Carbon Intensity. (n.d.). About the carbon intensity forecast. https://carbonintensity.org.uk/
- cleanshift. (n.d.). Delay batch ML/AI jobs to the cleanest grid window. https://pypi.org/project/cleanshift/
- ebb-ai. (n.d.). Carbon-aware MCP scheduler for agentic AI workflows. https://github.com/Vitalini/ebb-ai
- Google Cloud. (n.d.). Google's approach to carbon-aware data center. https://cloud.google.com/blog/topics/sustainability/googles-approach-to-carbon-aware-data-center
- Green Software Foundation. (n.d.). Carbon Aware SDK. https://carbon-aware-sdk.greensoftware.foundation/docs/overview
- Green Software Foundation. (n.d.). Software Carbon Intensity (SCI) Specification. https://sci.greensoftware.foundation/
- GridWise AI. (n.d.). Carbon-aware compute scheduling. https://www.grid-wise.us/
- Kannan, R., Strunz, K., & Wiese, F. (2017). The trends of hourly carbon emission factors in Germany and investigation on relevant consumption patterns for its application. International Journal of Life Cycle Assessment, 22(4), 621-632. https://doi.org/10.1007/s11367-017-1277-z
- Lou, X., Carley, K. M., & Azevedo, I. M. L. (2022). Hourly accounting of carbon emissions from electricity consumption. Environmental Research Letters, 17(4). https://doi.org/10.1088/1748-9326/ac6147
- Meyer, J., et al. (2025). The dynamics of the California electric grid mix and electric vehicle emission factors. Energies, 18(4). https://doi.org/10.3390/en18040895
- Radovanovic, A., et al. (2022). Carbon-aware computing for datacenters. IEEE Transactions on Power Systems. https://arxiv.org/pdf/2106.11750
- Siler-Evans, K., Azevedo, I. M. L., & Morgan, M. G. (2012). Marginal emissions factors for the U.S. electricity system. Environmental Science & Technology, 46(9), 4742-4748. https://doi.org/10.1021/es300145v
- Tekko. (n.d.). Carbon-aware scheduling using Kubernetes and the GSF SDK. https://tekko.id/en/blog/carbon-aware-scheduling-using-kubernetes-and-the-gsf-sdk
- Utility Dive. (2023). Google taps carbon-intelligent computing platform to help maintain grid reliability in power crises. https://www.utilitydive.com/news/google-carbon-intelligent-computing-platform-system-reliability-demand-response-grid-emergency/698958/
