Academic high-performance computing has a material climate footprint. A modern HPC cluster running at scale draws power in the megawatt range; the embodied carbon of the hardware, the operational carbon of the grid electricity, and the cooling overhead together produce annual emissions comparable to a mid-sized industrial facility. The sustainable-research community has been working on this since the late 2010s; 2026 is the year that carbon-aware computing moved from research interest to operational practice at academic clusters. This post walks through what’s happening and what cluster operators should be doing.
What carbon-aware computing means
Carbon-aware computing is a family of techniques for reducing the carbon footprint of computational work without reducing the work itself. The techniques include: temporal shifting, running non-urgent jobs during periods of low-carbon-intensity grid electricity; geographic shifting, running jobs at facilities with cleaner local grids; load-following, scaling cluster capacity with grid carbon intensity; efficiency improvements, doing more work per kilowatt-hour through hardware and software optimisations; demand reduction, eliminating redundant or wasteful computation.
The CASRAI carbon-aware computing entry tracks the terminology and the academic community’s evolving vocabulary.
What’s changed in 2025-2026
Three things converged in 2025-2026 to move carbon-aware computing into practical academic deployment.
First, real-time grid carbon-intensity data became reliable. The Electricity Maps API, Tomorrow’s national emissions data, and several regional grid operators’ direct data feeds now provide sub-hourly carbon-intensity data for most major grids. Scheduling decisions can be made on near-real-time information, not on average historical data.
Second, scheduler integrations matured. Slurm, PBS Pro, and the major HPC schedulers now have plugin or integration paths for carbon-aware scheduling decisions. The plugins consume carbon-intensity feeds and influence job dispatch decisions based on configurable policies. The integrations are not yet universal but are no longer bespoke.
Third, institutional commitments matured. The major UK research councils’ joint commitment to net-zero research by 2040, the EU’s broader sustainability-in-research push under the European Green Deal, several US universities’ institutional net-zero commitments — these created the policy mandate that aligns with the technical capability.
What clusters are doing
A non-exhaustive tour of the patterns we see at academic clusters in 2026.
Temporal scheduling for batch jobs. Most clusters have substantial batch workloads where the deadline is days or weeks out. Carbon-aware schedulers shift these jobs to grid-low-carbon windows. The University of Edinburgh’s ARCHER2, the Stuttgart HLRS cluster, and the Berkeley Lab NERSC system have all reported carbon savings in the 15-25% range from temporal shifting without measurable impact on time-to-result for affected jobs.
Geographic shifting for cloud-burst capacity. Clusters with cloud-burst arrangements for peak loads are increasingly directing burst capacity to cloud regions with cleaner grids. The carbon savings here are large per job but only apply to the burst fraction.
Idle reduction. The least glamorous and most impactful intervention. Clusters typically have substantial idle capacity due to scheduling fragmentation; running fewer nodes more efficiently produces direct emissions reduction. The pattern is to consolidate workload onto fewer nodes during low-demand periods and power down the rest, which requires the ability to bring nodes back up reliably when demand rises.
Hardware efficiency. The energy-per-flop trajectory in HPC hardware has been favourable; recent-generation hardware is materially more efficient than 5-year-old hardware. The cluster-refresh-cycle question becomes a sustainability question: when does the embodied carbon of new hardware get amortised by the operational savings? Mark Allen and the Green Software Foundation have published useful frameworks here.
Software efficiency. Often-overlooked. A scientific code that uses 30% less compute for the same result delivers a 30% emissions saving. Code-efficiency efforts at HPC centres (profiling, algorithmic improvements, library updates) have outsized impact. The Software Sustainability Institute has been advocating this for years and is finally getting traction.
The reporting and accounting layer
An emerging challenge is how to report computational carbon to funders and institutional sustainability offices. The CodeCarbon library, ML CO2 calculator, and several others provide per-job carbon-estimation tools. The estimates are approximate but useful at the order-of-magnitude level. Major HPC centres are now publishing annual carbon reports; the methodology varies and harmonisation work is underway via the Green HPC working group.
The CASRAI sustainable research domain is tracking the reporting standards. Our recommendation is that funders should ask for computational carbon estimates in proposals for compute-intensive work, with the estimate framed as a planning aid rather than a hard constraint.
What researchers should do
Three practical recommendations for researchers running compute-intensive work.
First, profile your code. The single highest-impact intervention is identifying the parts of the workflow that consume disproportionate resources. The Performance Optimisation and Productivity (POP) network in Europe and similar initiatives elsewhere provide free or low-cost profiling support. A well-profiled and reasonably-optimised code typically achieves 1.5-3x the throughput-per-kwh of an unprofiled version of the same workflow.
Second, use carbon-aware schedulers where available. If your cluster supports temporal shifting, mark jobs as deadline-flexible where they genuinely are. The scheduler will exploit the flexibility; the carbon savings accrue without effort on your part.
Third, report and account. Include computational-carbon estimates in your project’s environmental reporting. Make the cost visible. The cultural shift that follows visibility is the longest-term impact.
What institutions should do
For institutional HPC operations, the 2026 priorities are: deploy carbon-aware scheduling; publish annual carbon reports with methodology disclosure; integrate computational-carbon estimation into the user-facing portal; participate in the inter-institutional benchmarking and best-practice exchange via the Green HPC working group.
For institutional sustainability offices, the priority is to bring research computing into the institutional carbon accounting. Many institutional net-zero commitments under-count or omit research computing; this is a material reporting gap.
For funders, the priority is to recognise sustainability as a legitimate cost item in compute-intensive grants and to use the proposal-stage carbon estimation as a planning input rather than a punitive metric. UKRI’s 2024 sustainability-in-research guidance is a useful model.
The honest limits
Carbon-aware computing reduces but does not eliminate HPC’s footprint. A genuinely net-zero research-computing posture requires either grid decarbonisation (largely outside HPC operators’ control) or computational-demand reduction. The demand-reduction conversation is uncomfortable — large language model training, climate modelling at very high resolution, large-scale molecular dynamics — but it is increasingly unavoidable. The sustainable-research community needs to have it without flinching, while continuing the technical work that makes the unavoidable computational work as low-impact as feasible.
