A few months ago, CarbonRunner shut down. They had built a carbon-aware CI/CD runner for GitHub Actions. They made it simple to choose the greenest region, make a one-line edit and they claimed: get faster, lower cost builds with up to 90% fewer emissions. Their shutdown notice is three bullet points, slightly shortened here:
- Nobody cares. "People care about money, they don't seem to care about environmental savings, even if they're faster."
- The cost of switching is too high. Even a one-line change was too much friction.
- AI makes CI look cute. Datacenters keep getting built on cheap land in hot places running on coal and gas.
Not "Hello world!" but "Sorry world!" they wrote. 😢🌍 "Sorry we couldn't make the internet a greener place in 2025." I don't know about you, but this one hit me hard.
To be fair, startup failures are rarely proof of market indifference. There are a hundred ways to miss product-market fit that have nothing to do with whether the underlying problem matters. But the question buried in their epitaph is still worth grappling with. The carbon case is real and already lands with a lot of engineers. The harder problem is getting it to survive contact with those engineers' boss or whoever controls the budget.
Meanwhile, in the research world, the state of the art keeps advancing. Researchers are publishing increasingly sophisticated multi-variable optimization frameworks. New papers demonstrate that optimizing for carbon intensity alone can, in specific scenarios, shift environmental burdens (ex: water stress, air pollution, grid congestion) to already-strained regions. The science is getting better, but adoption is flat-lining or getting worse.
The Distinction Is Real
Let's define a couple terms before we go much further.
Carbon-aware computing means responding to real-time carbon intensity signals when making scheduling decisions and running deferrable workloads when and where the grid is cleaner. This is what most tools in the space do today, including Compute Gardener, the Carbon Aware SDK and what CarbonRunner did before turning off the lights.
Grid- or sustainability-aware computing means optimizing for the broader health of the grid and the local environment, of which carbon intensity is one (often the primary) signal among several. Water stress in the datacenter's basin. Air quality near the generation source. Grid congestion and price spikes that indicate system strain. These are real dimensions that vary by region and time and they don't always move in the same direction as carbon intensity.
Consider what this framing implies: carbon-aware isn't competing with grid-aware. It's an instance of it; grid-aware with one signal wired in. You can't argue carbon-aware vs. grid-aware any more than you can argue Camry vs. Toyota. The debate, to the extent there is one, is about scope and signal maturity, not about whether the approach is fundamentally right.
Geerd-Dietger (Didi) Hoffmann and Verena Majuntke recently demonstrated this with Orca, in a paper accepted to ICT4S '26. In quick summary, Orca is a sustainability-aware scheduling framework that jointly optimizes across carbon, water stress, air pollution exposure and grid stress indicators. Their work is solid and the direction is true. In a three-region case study (Frankfurt, Tokyo, Northern California), they showed that CO2-optimal routing sometimes diverges from locally-optimal routing. This is observed especially when a low-carbon region happens to be water-stressed or experiencing poor air quality.
I recently had the chance to speak with Didi about this work and I genuinely think it moves the field forward. Optimizing for a single variable in a complex multivariate system can push you away from the global optimum. Any engineer who's ever tuned a system knows this intuitively. And yet...
The Correlation Is Strong With This One
Here's what Orca's own data shows. In their case study, the carbon-only baseline and the multi-criteria optimum agreed on the same region for roughly two-thirds of the hours evaluated. The divergences were real but not dramatic and they were driven primarily by one region's (Japan's) persistently high water stress penalty.
This matches what we've seen in practice. Carbon intensity is strongly correlated with most other grid health indicators most of the time. When the grid is clean, it's usually because renewables are abundant. That, in turn, means less combustion and particulate, less water-intensive thermal generation, less air pollution from fossil plants and lower wholesale prices. The signals move together far more often than they diverge.
Don't get me wrong, when they do diverge, it matters. But the scenarios where carbon-optimal scheduling meaningfully worsens local outcomes generally involve specific regional characteristics. Factors such as a low-carbon grid that happens to sit in a water-stressed basin or a clean-energy window that coincides with grid congestion from other demand. These are knowable, addressable edge cases. And more than that, they're a roadmap. The divergences tell us exactly which signals to integrate next: basin-level hydrology, weather forecasting, real-time air quality, grid congestion. Not reasons to abandon carbon-aware scheduling, but the agenda for how it evolves additional dimensions of awareness.
The Signal Maturity Problem
Here's the part that gets lost in the academic discussion: carbon intensity is really the only environmental signal we have that's reliable, real-time, API-accessible and globally available in a form that schedulers or routers can actually consume.
The additional signals that frameworks like Orca want to consider (basin-level water stress at sub-monthly resolution, real-time air quality per datacenter zone, grid congestion indicators in comparable units across jurisdictions, operator-disclosed Water Usage Effectiveness figures) are either incomplete, regional, paywalled, updated infrequently, require bespoke integration per datacenter operator or, most commonly, some combination of these.
Orca's own evaluation highlights missing data points throughout their air quality time series (OpenAQ gaps), simplified water modeling (WUE multiplied by a coarse stress band) and the limitation of average-mix rather than marginal emissions factors.
These are real concerns AND they're not yet addressable at the tooling layer because the signal infrastructure doesn't exist. Carbon intensity is the floor we can build from today. As water stress data, grid congestion signals and air quality APIs become similarly mature, they absolutely should and will be incorporated.
But at that point, it's a signal upgrade. Not a paradigm shift.
The Behavioral Change Is the Hard Part
This is the part that matters most. And it's the part that CarbonRunner's epitaph makes impossible to ignore.
CarbonRunner didn't fail because they were using the wrong signal. They didn't fail because carbon-only optimization might occasionally route a CI job to a water-stressed region. They failed because, in their words, "nobody really cares."
The bottleneck to carbon-aware computing (or awareness of any kind) has never been signal quality. It's always been adoption. The activation energy required is organizational and cultural: classifying workloads by flexibility, shifting institutional expectations (a batch job submitted at 2am doesn't need to start at 2am — it just needs to finish by 8am), and integrating a scheduling layer that actually acts on external signals. No longer is it a "fire-and-forget" operation, but a decision with ongoing environmental (and economic) consequences. That's hard. It's unfamiliar. It requires changing habits that have been optimized for developer convenience or costs alone, not environmental awareness.
But here's the thing: that behavioral change only really needs to happen once. Once an organization has classified its workloads by flexibility, once it has built the scheduling infrastructure to act on external signals, once the institutional muscle memory exists, upgrading the signal set is trivial. Swapping a carbon intensity value for a multi-variable sustainability score is only a configuration change. The hard work is building organizations that can respond to any external signal at all. Getting them to respond to one unlocks responding to five. The habits transfer. The tooling upgrades.
The research community is doing important work improving signal quality and optimization scope. But debating whether to optimize for carbon intensity alone or a Pareto-weighted vector of carbon, water stress, NOx exposure and grid congestion is like arguing over wine pairing for a dinner that no one has RSVP'd to.
The Excused Inaction Pattern
I keep seeing the same reasoning structure across different conversations in this space.
- "Carbon intensity doesn't capture marginal emissions accurately." → True in some contexts.
- "Carbon-only optimization might increase water stress." → Possible in specific region+time combinations.
- "We should fix energy markets so prices incorporate externalities, then we won't need carbon signals." → A worthy long-term goal.
Every one of these is a legitimate observation about a real limitation. And every one of them, in practice, gets elevated from "limitation" to "road block" along its journey to the all-too-common destination of excused inaction.
It's a pattern, and once you see it in one discussion, you begin to see it everywhere.
To be perfectly clear: the researchers aren't "the problem." Didi's paper advances the field in exactly the right direction. Tammy Sukprasert's work at UMass Amherst on marginal vs. average signals sharpens our understanding. These are scientists doing what scientists should be doing... pushing toward more accurate models of complex systems.
The problem is what happens when those nuanced findings propagate into industry conversations. Even as multi-variable optimization is the right direction, some forces would happily weaponize its complexity as an excuse to skip earlier steps entirely. "Necessary but not sufficient" gets heard as "not necessary." "Has limitations" gets heard as "doesn't work." And the conclusion is always the same: we need to understand the problem better before we act. Which, as we know, is a wonderful way to delay action.
If We Build it, Will They Come?
We're building at a time where environmental stewardship isn't just undervalued, in some markets, it's actively penalized. "Sustainability" has become a dirty word in some boardrooms which were publishing sustainability reports only two years ago. CarbonRunner didn't fail because their technology didn't work or provide the value stated. They failed because the market they were selling into doesn't yet feel sufficient pressure (whether regulatory, economic or social) to care.
The EU's Corporate Sustainability Reporting Directive doesn't care about the political winds in Washington. Electricity prices don't care about your feelings regarding climate change. And the physical constraints of water-stressed grids feeding power-hungry datacenters don't negotiate with anyone's politics.
When these pressures mount again (and they will, regardless of any single administration's or nation's posture), the question won't be "Should we optimize for sustainability?" It'll be "How fast can we start?" The organizations that already know how to flex their compute will adapt in weeks. The ones that don't will spend years trying to catch up.
The major cloud providers offer carbon footprint reporting. These tools are genuinely useful for compliance and retrospective accounting, but post-hoc and coarse-grained by design. They can tell you how much carbon your EC2 fleet generated last month. They cannot help you make operational decisions such as to defer your batch job four hours because the grid is dirty or electricity is cheaper in off-peak hours. That real-time, workload-level scheduling layer is precisely what's missing.
And this is why tools that work on economic signals alongside environmental ones matter. The rough correlation between "green" and "cheap" doesn't require a friendly regulatory regime to deliver value. At Compute Gardener, we call this our green↔cheap knob. It's a blending engine that lets organizations weigh carbon optimization against cost optimization. In environments where you can pitch sustainability, lean green. In environments where that's a dirty word and you can only pitch savings, turn the knob to cheap. The scheduling flexibility you build serves both goals, because the signals are correlated more often than not.
Where This Is Heading
The research community is converging on what we might call "sustainability-aware" computing. That is, multi-variable optimization that considers carbon, water, air quality, grid health and cost as composable signals with configurable weights. That is the right destination.
At Compute Gardener, we're similarly on the journey from carbon-aware toward additional layers of awareness. Our architecture is built around a modular signal ingestion and blending engine. We use carbon intensity and electricity pricing today, with a modular design that allows incorporation of additional signals as they mature. Ultimately, the scheduler doesn't care whether its decision was based on optimizing for one variable or five. The organizational capability of classifying workloads and scheduling flexibly is the foundation. Everything built on top of that is an incremental lift.
Getting organizations to think about workload flexibility, to classify jobs by deferrability, to build scheduling infrastructure that responds to external signals; that's the expensive, culture-changing work. But, fortunately, it only needs to happen once. And it produces value on day one, even with carbon intensity as the only signal and even in a political environment that can't say the word "sustainability" out loud.
Ultimately, there's no debate between carbon-aware and grid-aware computing. If one exists, it's between awareness and unawareness. And closing that gap is where every bit of energy in this space should be focused. At the very least, it's where we continue to see value and will keep contributing.
Then, one day soon, new, upgraded and more reliable signals will become available. The research will keep improving. The optimization scope will broaden. But none of that matters if nobody cares.
You care. Start somewhere. Start now.
Interested in what sustainability-aware computing patterns could look like for your workloads? Whether you're running ML training, CI/CD pipelines, batch processing or any deferrable compute, we could help you quantify savings opportunities. Check out our open-source Kubernetes scheduler or reach out about a consulting engagement and we can continue the conversation considering your particular infrastructure.
Dave Masselink builds carbon/grid/sustainability-aware scheduling and routing tools at Compute Gardener. He's pretty sure the hardest part of sustainable computing is spurring action and has little to do with deciding the correct signal(s) to consider.