Where the project is heading

GreenCode runs until September 2027. By then the consortium intends to have a complete, partner-deployable pipeline: one that maps a codebase, baselines its quality, reconstitutes its infrastructure, measures and optimises its energy use, and certifies the result, with every change returned as a reviewable pull request. The vision statement sets the bar: energy optimisation of software as a routine, automated, verifiable engineering outcome, treated with the same rigour as quality, security and performance.

The work does not stop at the pipeline. Several of the project's public outputs are about what happens around it: a software energy benchmarking tool, a certification tool aligned with the Software Carbon Efficiency Rating, contributions to the Green Software Foundation's Impact Framework and patterns library, a Green AI working group, optimised contributions to the WordPress ecosystem, and a published account of migrating a large industrial codebase under sustainability constraints. Each of these is a place where organisations outside the consortium can take part before the project ends.

What comes next

• Certification that procurement can use. A software energy rating that buyers, tenders and ESG disclosures can rely on needs adoption beyond the partners. The consortium will work with standards bodies and the Green Software Foundation to make the rating a shared measure rather than a project artefact. Why policy needs such a measure is the subject of our article on policy for the energy of software and AI.
• Open-source decarbonisation at scale. Applying the pipeline to widely deployed open-source software is the fastest route to large, persistent carbon reductions, and the way the practice spreads. The climate case sets out why: a saving in a project with hundreds of thousands of deployments is realised everywhere at once.
• New sectors and deployment contexts. The first use cases come from the partners' own industries: industrial engineering software, banking and insurance mainframes, automotive and aerospace platforms, web and SaaS systems, research computing. Each new sector brings its own languages, infrastructure and constraints, and each makes the tools more general.
• Green AI beyond GreenCode. The methods developed to keep the pipeline's own AI lean, small and fine-tuned models, retrieval, routing and energy-aware scheduling, apply to any AI system, including those running at the edge on constrained power. The coordinator has been invited into the leadership consortium of a two-day Green AI sandpit under the Knowledge Exchange Hub for Mathematical Sciences' sandpit scheme, organised with Innovate UK Business Connect. Its question is how the mathematical sciences can reduce the energy and resource demands of AI, and it brings mathematical scientists and research software engineers together to look for new algorithms for AI computation. It is planned for November 2026 at STFC's Rutherford Appleton Laboratory at Harwell, directly after the Institute of Mathematics and its Applications' Climate, Environment and Sustainability special interest group event, and its formal output is a roadmap and position paper towards a substantial UK research investment in the topic. GreenCode brings to it the cross-domain experience of making generative AI efficient in practice. Our article Green AI is a mathematics problem as much as a hardware one sets out why the question matters.
• Scientific and HPC computing. Research software, across the physical, life and social sciences, is mostly written by subject experts rather than software engineers, and much of it is written to get one result and then set aside. When it reaches a shared high-performance computing facility, a lack of quality shows up as jobs that fail or never finish, and inefficient jobs slow everyone else's science while burning energy the facility pays for. Some universities now employ research software engineers to work alongside researchers, but the help is slow and piecemeal, and the use of software in research keeps growing. The consortium's academic use case, the sustainability transformation of a university computing cluster, is the first step. The next is to adapt the pipeline to research software directly: as a check that runs before a job is admitted to a cluster, and as a routine part of the research software lifecycle, so that codes run faster and more reliably, facilities get more science through the same hardware, and their operating cost and carbon footprint fall, all while the science the code performs is preserved. Because the same optimisations recur across disciplines, a fix found in a physics code can carry over to an epidemiology or social-science model, and a shared optimisation tool would connect research software communities that are otherwise siloed. The consortium has raised this idea with universities, facility operators and technology-transfer bodies over the past two years and is looking for the partners to take it into a funded programme. The case is made at more length in Research software, shared supercomputers and the energy of a failed job.
• After 2027. The consortium expects to continue the research, whether through a follow-on European programme or further Eureka work, and the partners will carry the tools into their own products and services. The project coordinator will keep the public results, this site and the publications available.

Partners we are looking for

The consortium is open to organisations that can add a use case, a deployment context or a route to adoption. In particular:

• Software owner-operators with large estates. SaaS providers, financial services, retail, telecoms and public bodies running systems at scale or high intensity, where a measured saving turns into tonnes of carbon quickly. You would bring a codebase and an infrastructure to measure; you would get the optimisation, the evidence and the rating first. Talk to us about a use case.
• Data centre and cloud operators. Organisations that host other people's software and want to see, and act on, the energy behaviour of what runs on their infrastructure: energy-aware scheduling, scaling with the energy mix, hotspot detection. Talk to us about infrastructure.
• Embedded, automotive and aerospace teams. Systems that must run on constrained or backup power, where efficiency is resilience. The partners already work on aerospace and vehicle platforms and want more. Talk to us about constrained systems.
• Standards bodies, certifiers and regulators. Anyone shaping how software energy efficiency will be rated, reported or procured, from the Green Software Foundation's initiatives to national procurement frameworks. Talk to us about certification.
• Universities and training providers. Partners who teach software engineering and want the pipeline's generated training material, the state of the art reviews and the measured results in their courses. Talk to us about teaching.
• Scientific and HPC computing. University clusters, national HPC facilities and the research software engineers who support researchers' code, who want to test optimisation before jobs run and measure what it saves in throughput, energy and cost. Talk to us about scientific and HPC computing.
• Open-source maintainers. Projects with a large install base that would accept optimisation pull requests, reviewed by their own maintainers, and share the measured outcome. Talk to us about your project.

How to get involved

Get in touch through our contact form, say which of the areas above fits you, what systems you run and what you would want to measure, and Chris Dean, the project lead, will reach out to you. Early adopters take part in in-market trials of the pipeline as components mature, and use cases can be added at any point in the project. Researchers who publish on GreenCode are listed on the researchers page; partners are listed on the partners page and the funding page explains who supports the work.