Software Carbon Intensity (SCI)

Updated 12 April 2026

SCI is a metric that measures greenhouse gas emissions per unit of useful work by dividing total CO2e emissions by a workload metric.
Methodologies for SCI include monitoring with hardware sensors, estimation from resource logs, and black-box approaches from cloud dashboards.
Practical applications of SCI guide sustainable software practices through workload scheduling, carbon-aware APIs, and energy-performance balancing.

Software Carbon Intensity (SCI) quantifies the greenhouse gas emissions attributable to the operation of software per unit of useful work. It is formulated as the ratio of total carbon dioxide–equivalent emissions (CO₂e) to a chosen metric of software output, enabling direct, comparative, and actionable assessments at the algorithm, workload, or system level. SCI is a central pillar in modern software and cloud sustainability, with formalizations, methodologies, and practical implementations emerging across both industry (e.g., Google Cloud reporting, cloud provider dashboards) and research (Schneider et al., 2024, Pathania et al., 11 Jun 2025, Dodge et al., 2022, Thiede et al., 2023, Souza et al., 2022, Danushi et al., 2024).

1. Formal Definition and Mathematical Structure

SCI is defined as a rate metric:

$\mathrm{SCI} = \frac{C}{W}$

where

$C$ is the total operational carbon emissions (typically in gCO₂e or kgCO₂e),
$W$ is a workload metric quantifying "useful work" (such as number of requests, transactions, inference runs, CPU-hours, or job completions).

When embodied (lifecycle) emissions are included, the formula extends to:

$\mathrm{SCI} = \frac{C_{\mathrm{operational}} + C_{\mathrm{embodied}}}{W}$

The units can be tailored: e.g., gCO₂e per transaction, per CPU-hour, per ML model inference, or per user (Pathania et al., 11 Jun 2025, Dodge et al., 2022, Danushi et al., 2024, Thiede et al., 2023).

The canonical calculation follows the chain:

Power $\to$ $\to$ Energy $\to$ $\to$ Carbon
- At component $k$ and time $t$ : $P_k(t)$ (W)
- Energy: $E_k = \int_0^T P_k(t) \, dt$ (Wh or kWh)
- Emissions: $C$ 0, where $C$ 1 is the emission factor (gCO₂e/kWh) for location $C$ 2, typically time-variant via regional carbon-intensity (Pathania et al., 11 Jun 2025, Dodge et al., 2022).

2. Methodologies for SCI Measurement and Allocation

The literature delineates three major methodological paradigms for determining SCI (Pathania et al., 11 Jun 2025, Schneider et al., 2024, Danushi et al., 2024):

Monitoring Approaches directly measure power using hardware sensors, on-chip counters (e.g., RAPL, NVML), or software-based telemetry.
Estimation Approaches use resource utilization logs and model-based energy-to-carbon mappings, often employing published coefficients (e.g., Wh/vCPUh, Wh/GBh) or ML/regression models trained on prior benchmarks.
Black-Box Approaches rely on aggregated data and provider-disclosed emissions (e.g., AWS, GCP dashboards), generally withholding methodology details.

Google’s allocation pipeline for SCI in multi-tenant cloud environments exemplifies a state-of-the-art, physically grounded approach. For each user, machine, and time interval, machine energy is partitioned based on a weighted composite of reservation (contracted resource fraction) and measured usage. The combined allocation is controlled by a parameter $C$ 3, calibrated between 0.2–0.8 (operational best-practice: $C$ 4), determining the blend between reservation- and usage-based attribution (Schneider et al., 2024). Hourly regional carbon intensity is obtained from external sources (e.g., Electricity Map), and the user’s emissions are aggregated and normalized by their workload to compute SCI.

3. Practical Implementations and Tool Ecosystem

A range of open-source tools and cloud-scale systems implement the above methodologies, differing by granularity and component scope (Pathania et al., 11 Jun 2025, Dodge et al., 2022, Saraiva et al., 19 Aug 2025, Thiede et al., 2023):

Tool/Class	Basis	Measured Components	Granularity
RAPL, pyJoules	Monitoring	CPU, DRAM, GPU (NVML)	Process/machine
CodeCarbon, PowerAPI	Estimate	CPU, GPU, RAM; PUE opt.	Process/job/system
Cloud dashboards (AWS, GCP)	Black-Box	Total data-center usage	Tenant/project
SimGrid/Batsim Carbon plugin	Monitoring	Modelled platform hosts	Simulation task
Carbon Containers	Monitoring	Container power & usage	Container/job

Each approach exhibits trade-offs:

Monitoring provides high accuracy (±1–5% hardware) and granularity, but incurs minor runtime overhead.
Estimation is less intrusive and can project emissions for planned workloads, but is sensitive to coefficient accuracy (10–30% error typical; TDP misestimations up to 40% below 20% or above 80% CPU utilization).
Black-Box methods offer minimal overhead but lack transparency and process-level attribution.

Google’s production pipeline is structured as a SQL-style workflow operating on per-machine/per-user/per-hour tabular data, facilitating parallelization and policy experimentation via the $C$ 5 allocation parameter (Schneider et al., 2024).

4. Applications, Optimization Strategies, and Empirical Impact

SCI measurement creates actionable levers for emissions reduction, both for ML and general software workloads:

Workplace-level interventions: Region selection can drive up to 3–4× variability in SCI for large ML jobs; time-of-day scheduling and pausing during high RCI intervals yield further (mostly single-digit) percentage savings (Dodge et al., 2022).
Container and Virtualization Layers: Carbon Containers enforce per-container carbon budgets by dynamically scaling CPU quotas, migrating between servers, or invoking suspensions. Compared to suspend/resume-only policies, this reduces performance penalties by 3–7× while maintaining target carbon constraints across highly variable or consistently carbon-intensive regions (Thiede et al., 2023).
Carbon-Aware APIs and Orchestration: Systems such as Ecovisor and Treehouse expose fine-grained carbon feedback to applications, enabling SLO-constrained scheduling, power caps respecting real-time grid intensity, and cross-layer carbon/latency SLAs (Souza et al., 2022, Anderson et al., 2022).

In simulation contexts (e.g., Batsim), SCI quantifies the carbon emission per simulated job or GFLOP under varying platform and scheduling scenarios (Saraiva et al., 19 Aug 2025).

5. Integration into Software Engineering Practices

SCI is increasingly integrated into software development life-cycle models, including eco-centric Agile sprints (GREENSOFT), explicit green analysis phases, and continuous integration pipelines to rerun emission checks. Instrumentation ranges from profiling-based "white-box" tools (code-level energy smells, refactoring), to hybrid digital twin models and pure estimation ("black-box") techniques (Danushi et al., 2024).

Emerging guidelines recommend:

Tracking carbon as a first-class requirement.
Using real-time RCI APIs for dynamic carbon factor modeling.
Incorporating embodied emissions (manufacturing, disposal) via amortization over equipment lifetime.
Providing dashboards across experiment runs to facilitate reproducibility and community validation (Pathania et al., 11 Jun 2025, Danushi et al., 2024).

6. Challenges, Limitations, and Future Directions

Notable unresolved issues include:

Absence of Community Standardization: No single, agreed formula or taxonomy of normalization units (CPU-hours, requests, transactions), impeding cross-study comparability.
Limited Process-Level Attribution: Most current black-box and provider approaches lack process- or function-level breakdown.
Static vs. Dynamic Carbon Factors: Many estimation methods use static or hourly-averaged RCI, while real-time RCI can swing operational carbon by ±70% (Pathania et al., 11 Jun 2025).
Embodied Emissions: Inclusion of hardware manufacturing and disposal emissions is rare, though these can contribute up to 70% of device lifecycle impact.
Toolchain Gaps: Mainstream developer IDEs and CI/CD tools are only beginning to integrate SCI profiling and reporting (Danushi et al., 2024, Pathania et al., 11 Jun 2025).

Proposed advances include developing reference benchmarks for SCI, integrating real-time grid APIs, standardizing functional unit taxonomies, refining cross-component measurement (e.g., memory, network), and raising tool maturity to production-readiness.

7. Alignment with Reporting Protocols and Standards

SCI methodologies, especially those implemented in large-scale cloud platforms, are aligned with the Greenhouse Gas Protocol’s Scope 3 standards. The Google model, in particular, follows GHG Protocol preferences for physical allocation of emissions (usage over economic reservation wherever physically justifiable), supporting enterprise cloud customers in mandatory upstream leased asset and purchased goods/service reporting categories (Schneider et al., 2024, Pathania et al., 11 Jun 2025).

Reporting best-practices emphasize alignment with established environmental management standards (e.g., ISO/IEC 14001), integrating both operational and (where feasible) embodied carbon into software sustainability KPIs.

References:

(Schneider et al., 2024) Carbon accounting in the Cloud: a methodology for allocating emissions across data center users
(Pathania et al., 11 Jun 2025) Calculating Software’s Energy Use and Carbon Emissions: A Survey of the State of Art, Challenges, and the Way Ahead
(Dodge et al., 2022) Measuring the Carbon Intensity of AI in Cloud Instances
(Danushi et al., 2024) Carbon-Efficient Software Design and Development: A Systematic Literature Review
(Thiede et al., 2023) Carbon Containers: A System-level Facility for Managing Application-level Carbon Emissions
(Souza et al., 2022) Ecovisor: A Virtual Energy System for Carbon-Efficient Applications
(Anderson et al., 2022) Treehouse: A Case For Carbon-Aware Datacenter Software
(Saraiva et al., 19 Aug 2025) Estimating CO $C$ 6 emissions of distributed applications and platforms with SimGrid/Batsim