cloudparts

Software Carbon Intensity (SCI)

A method for scoring software by its carbon emissions per unit of work, such as grams of CO2e per API call, counting the energy it uses, the grid that powers it and a share of the hardware it runs on.

GSF project
What it is
Cloud cost and carbon
Type
Open source
Made by
Green Software Foundation (Linux Foundation)
Foundation
Green Software Foundation. Written by the GSF’s Software Standards Working Group; published as ISO/IEC 21031:2024. Part of the Linux Foundation
License
Specification text under CC BY 4.0, developed under the W3C Patent Policy patent mode; also published by ISO and IEC as ISO/IEC 21031:2024
Facts checked
28 October 2026
Website Source code

What it is

The SCI is a formula, not a tool: SCI = ((E × I) + M) per R. E is the energy the software uses, in kWh, including the overhead of the data centre, such as cooling, through its PUE. I is the carbon intensity of the electricity, in gCO2e per kWh, taken from the regional grid where it runs. M is the share of the hardware’s embodied emissions, from manufacturing to disposal, allocated to the software by how long and how much of the machine it reserves. R is the functional unit you choose, such as an API call, a user, a transaction or a minute of video, so the result is a rate rather than a total. The boundary has to include everything that significantly supports the software: compute, storage, networking, idle and standby machines, logging and monitoring, build pipelines, backups and, where relevant, end-user devices.

Two rules set it apart from a corporate carbon report. It counts only location-based grid intensity and excludes market-based measures such as renewable energy certificates, power purchase agreements and offsets, so the only way to lower a score is to use less energy, run on a cleaner grid or use less hardware. And because it is a rate, a growing product can still show progress. The Green Software Foundation published version 1.0 in November 2022; ISO and IEC published it as ISO/IEC 21031:2024, and the GSF’s own text is at 1.1.0. Extensions apply it to particular kinds of software: SCI for AI was ratified in 2025, and SCI for Web was a draft in October 2026.

Why teams pick it

  • An ISO/IEC standard, so a score can be explained to auditors, customers and procurement with a public reference
  • A rate per unit of work, which shows whether each request or user gets cleaner even as traffic grows
  • Counts embodied hardware emissions, which rewards using fewer and longer-lived machines, not only cleaner electricity
  • Ignores certificates and offsets, so the score responds only to engineering changes

Watch out for

  • You choose the boundary and the functional unit, so two products’ scores are rarely comparable; it is built for tracking one system over time
  • It says what to measure, not how: energy per workload and embodied emissions are hard to get in a public cloud, and most teams end up with estimates
  • Location-based numbers differ from the market-based figures in many corporate sustainability reports, which can confuse readers

Alternatives

What all cloud cost and carbon have in common →Compare side by side →
FOCUSOpen sourceThe FinOps Open Cost and Usage Specification: one schema for billing data, so cost exports from clouds, SaaS vendors and data centres land in the same columns with the same meaning.

An SCI score for one hour of an API service (illustrative numbers) · python

# E: energy for the hour, with data centre overhead (PUE)
server_kw, hours, pue = 0.20, 1, 1.2
E = server_kw * hours * pue                     # 0.24 kWh

# I: location-based grid intensity of the region, gCO2e per kWh
I = 400

# M = TE x (TiR / EL) x (RR / ToR): share of the server's embodied carbon
TE = 1_200_000                                  # gCO2e to make the server
EL = 4 * 365 * 24                               # expected life, hours
M = TE * (hours / EL) * (1 / 1)                 # whole server reserved: ~34 g

# R: functional unit, here API calls served in the hour
R = 50_000

sci = (E * I + M) / R
print(f"{sci * 1000:.2f} gCO2e per 1,000 API calls")   # 2.60

The four terms#

Every component inside the boundary is scored with the same functional unit, and the components are added up.

TermWhat it isWhere the number comes from
E, energykWh used by the software per unit of work, counting all hardware reserved or provisioned for it, not only what it keeps busyReal-world measurement, or a model built in a lab or from supplier data when measurement isn’t possible; data-centre overhead added through its PUE
I, carbon intensitygCO2e per kWh of the grid where the energy is used: short-run marginal, long-run marginal or average, but always location-basedData for the regional grid; an emissions factor for the system itself when it isn’t grid-connected
M, embodied emissionsTE × (time reserved ÷ expected life) × (resources reserved ÷ total resources)Life-cycle assessments (LCAs) of the hardware, ideally per device, or simpler estimation models; in the cloud, the share of vCPUs reserved is a suggested resource share
R, functional unitWhat the score is divided by: API call, user, device, transaction, minuteYour own traffic metrics; it should be how the software scales

See it in a real stack

No architecture uses Software Carbon Intensity (SCI) yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2021–2025

The Green Software Foundation formed its Software Standards Working Group in 2021, its first year, to agree on how to measure software emissions. The aim was a score engineers could move by changing code and infrastructure, rather than a total that certificates and offsets could lower. An alpha of the SCI came out in December 2021.

After public comment, version 1.0 removed ambiguities, for example by settling on location-based emissions factors and saying how to treat data-centre energy, and was announced at the GSF’s Decarbonize Software event during COP27 in November 2022. Navveen Balani of Accenture and Henry Richardson of WattTime led the work. The foundation then took it through ISO/IEC JTC 1, and in 2024 it was published as ISO/IEC 21031:2024. The GSF released version 1.1 of its own text in October 2024.

The method then branched out. Impact Framework, a GSF tool for computing SCI scores from manifests of observations, graduated in 2024, and SCI for AI, led by Balani and Richardson, was ratified in 2025 to cover model training and inference. In 2026 the foundation was also working on energy and water intensity specifications built on the same pattern.

Why it’s built this way

A rate per functional unit
A total grows with the business and punishes success. Dividing by a unit of work lets a team show that each request got cleaner, which is what engineering can control.
Location-based intensity only
Market-based figures fall when a company buys certificates, whatever the software does. The SCI excludes them so the score reflects the grid the software actually draws on.
Include embodied emissions
Making servers, phones and network gear causes a large share of IT’s footprint, so the SCI rewards keeping hardware busy and in service for longer, not only buying cleaner electricity.
Take it to ISO
An international standard gives buyers, auditors and regulators a reference they recognise, which a foundation document alone would not.

Timeline

  1. 2021

    Software Standards Working Group formed; SCI alpha in December

  2. 2022

    SCI 1.0 announced during COP27 in November

  3. 2024

    Published as ISO/IEC 21031:2024; version 1.1 in October

  4. 2025

    SCI for AI ratified

Sources7 · facts checked 28 October 2026

Improve this page on GitHub