CodeCarbon: Energy & Emissions Tracker

• CodeCarbon is an open-source tool that estimates operational energy and carbon emissions from computing using telemetry and region-specific electricity factors.
• It integrates with hardware interfaces such as RAPL for Intel CPUs and NVML for Nvidia GPUs to track energy use across CPU, GPU, and RAM components.
• Researchers use CodeCarbon to compare energy and emissions across training and inference workflows, supporting green AI initiatives and optimization studies.

CodeCarbon is an open-source software tool for estimating the energy consumption and carbon footprint of executed code. In recent machine-learning and AI studies, it is used as a telemetry-and-accounting layer that tracks CPU, GPU, and RAM energy, converts energy into carbon-equivalent emissions using location-dependent electricity carbon intensity, and logs runtime and component-level consumption for training and inference workflows (Fovet et al., 7 Jul 2025, Rodriguez et al., 2024).

1. Measurement model and accounting semantics

Across the literature, CodeCarbon is presented as an operational accounting system rather than a direct carbon sensor. Its core role is to observe or estimate power-related behavior of compute components, accumulate that behavior over runtime into energy, and then transform energy into emissions with a regional carbon-intensity factor. A systematic review places it in the on-chip-sensors category, characterizing it as using RAPL and NVML and accounting for CPU, RAM, and GPU; in the same review, the generic power–energy relations are stated as $E=P*T$ for approximately constant power and $E=\int_0^T P\,dt$ for time-varying power (Rodriguez et al., 2024). Studies using CodeCarbon then make the emissions layer explicit with formulations such as $E_{CO_2}=C\times P\times t$, where $C$ is carbon intensity, $P$ average power, and $t$ duration (Almog, 16 Sep 2025), or $\mathrm{CO_2eq}=E\times\gamma$, where $E$ is total energy and $\gamma$ is the electricity carbon intensity (Mamun et al., 3 Apr 2026).

This accounting model makes the geographic context intrinsic to the output. Inference and training workloads executed on identical hardware can yield different $\mathrm{kg\ CO_2eq}$ if the assumed grid differs, because the emissions calculation is downstream of the energy estimate. Several studies exploit that fact directly: one compression study fixes all runs to a French VM and applies a carbon intensity of $E=\int_0^T P\,dt$0, while prompt-engineering work contrasts Alberta and Ontario using CodeCarbon’s regional factors (Fovet et al., 7 Jul 2025, Mamun et al., 3 Apr 2026). This establishes CodeCarbon as a scope focused on operational electricity use rather than on embodied hardware impacts or full datacenter life-cycle assessment.

2. Instrumentation, platform interfaces, and execution modes

The review literature describes CodeCarbon as a software-accessed hardware-sensor or hardware-counter-based method. In that characterization, it relies on vendor interfaces such as RAPL for Intel CPUs and NVML for Nvidia GPUs, and is constrained by Linux OS, Intel CPU, Nvidia GPU, and Python in the canonical setup summarized by the review (Rodriguez et al., 2024). The same review emphasizes that these interfaces are not fully transparent: prior studies disagree on whether some reported values are direct measurements or model-based estimates, especially for CPU and RAM domains. That ambiguity is not incidental; it defines the epistemic status of CodeCarbon outputs as telemetry-informed estimates rather than wall-plug truth.

At the same time, the platform surface has expanded beyond the canonical Linux–Intel–Nvidia configuration. An optimizer study on Apple Silicon reports CodeCarbon 3.0.4 integrated with macOS powermetrics to obtain detailed power-consumption measurements for CPU, GPU, and memory subsystems on an Apple M1 Pro system running PyTorch on the MPS backend (Almog, 16 Sep 2025). In federated-learning instrumentation based on NVIDIA NVFlare, CodeCarbon is configured explicitly at process scope with tracking_mode="process" and measure_power_secs=1, making per-process attribution central to the methodology (Tapp et al., 30 Jan 2026). These deployments suggest a family of operating modes—machine-level tracking, process-level tracking, and platform-specific telemetry backends—rather than a single fixed instrumentation path.

3. Integration into training, inference, and orchestration workflows

The most common integration pattern is coarse-grained wrapping of an experimental run. In an inference study of CompactifAI compression on Llama 3.1 8B, “The tracker was initialized before model execution and it was terminated after response generation,” so that each full run over a 104-question test set became one CodeCarbon tracking session (Fovet et al., 7 Jul 2025). A training study on optimizer choice uses a nearly identical envelope: each run begins by setting the seed, initializing a CodeCarbon tracker, performing data loading and model/optimizer setup, executing epoch-by-epoch training with validation, and stopping the tracker only when training terminates, including early stopping (Almog, 16 Sep 2025).

Framework-level integrations push the same idea into orchestration layers. WarpRec places CodeCarbon in the monitoring stack beside TensorBoard, Weights & Biases, and MLflow, and states that it was adopted to “automatically quantify energy consumption and carbon emissions”; the paper also ties CodeCarbon-derived outputs to a Writer Module that stores execution metadata and carbon-emission estimates as reproducible artifacts (Avolio et al., 19 Feb 2026). In federated learning, the integration becomes phase-aware rather than monolithic: NVFlare clients instantiate CodeCarbon tasks such as init, idle_time, round_k, and evaluate, so that initialization, waiting/coordination, per-round local training, and evaluation are measured separately (Tapp et al., 30 Jan 2026). This suggests a methodological progression from simple run-level wrappers to lifecycle-aware instrumentation aligned with the semantics of the surrounding system.

4. Reported outputs and derived analytical quantities

The primary outputs associated with CodeCarbon in the surveyed papers are runtime, total energy, component-level energy, and emissions. The CompactifAI study reports total duration, total greenhouse-gas emissions in $E=\int_0^T P\,dt$1, CPU and GPU energy in $E=\int_0^T P\,dt$2, RAM tracking, and “Total Energy Consumed,” then uses those quantities to compare compressed and full-size inference runs under fixed prompt-generation settings (Fovet et al., 7 Jul 2025). WarpRec exposes a similar but more dashboard-like profile: emissions, emissions rate, CPU power, GPU power, CPU energy, GPU energy, RAM energy, total energy consumed, and peak RAM usage for recommender-model training on NetflixPrize-100M (Avolio et al., 19 Feb 2026).

A notable development is the use of CodeCarbon outputs as raw material for secondary metrics rather than as final reporting endpoints. In eco-aware cybersecurity, CodeCarbon-derived energy and emissions are merged with predictive metrics into an Eco-Efficiency Index defined as

$E=\int_0^T P\,dt$3

making “$E=\int_0^T P\,dt$4 per kWh” an explicit model-selection criterion (Aashish et al., 31 Dec 2025). In prompt-driven software-testing studies, batch-level energy $E=\int_0^T P\,dt$5, emissions $E=\int_0^T P\,dt$6, and duration $E=\int_0^T P\,dt$7 are normalized into a Software Carbon Intensity,

$E=\int_0^T P\,dt$8

and then further folded into composite indices such as SVI and $E=\int_0^T P\,dt$9 (Kumari et al., 3 Apr 2026). In sustainable code-generation work, CodeCarbon’s energy_consumed metric becomes the basis for average energy, average $E_{CO_2}=C\times P\times t$0, and “Carbon per Correct Answer,” with Pass@1 and token/runtime statistics analyzed jointly (Mamun et al., 3 Apr 2026). The tool thus serves both as a measurement backend and as an input layer for higher-level efficiency metrics.

5. Domain-specific uses across contemporary AI workloads

CodeCarbon now appears across a wide range of workloads rather than being confined to a single phase of ML experimentation. In model-compression research, it is used to compare a CompactifAI-compressed Llama 3.1 8B model against its full-size baseline during inference, producing evidence on runtime, emissions, and CPU/GPU energy reduction under controlled QA prompting (Fovet et al., 7 Jul 2025). In optimizer benchmarking, it wraps full training runs over MNIST, CIFAR-10, and CIFAR-100 on Apple M1 Pro hardware, enabling comparisons among SGD, Adam, AdamW, RMSprop, Adagrad, Adadelta, Adamax, and NAdam in terms of duration, emissions, and emissions rate (Almog, 16 Sep 2025).

In recommender systems, CodeCarbon is embedded into WarpRec as part of “Green AI profiling,” where it decomposes CPU, GPU, and RAM energy for algorithms such as ItemKNN, EASE$E_{CO_2}=C\times P\times t$1, NeuMF, LightGCN, and SASRec (Avolio et al., 19 Feb 2026). In federated learning for MRI-to-CT conversion, it tracks the emissions and energy consumption of entire federated training runs and supports claims that adaptive encoder freezing reduces time, total energy consumption, and $E_{CO_2}=C\times P\times t$2 emissions by up to 23% while preserving model quality (Raggio et al., 25 Nov 2025). In federated-learning methodology, it is explicitly combined with NVFlare to make initialization, idle/coordination time, local training, evaluation, and communication accounting comparable across sites and rounds (Tapp et al., 30 Jan 2026).

The same pattern extends to software-engineering and language-model studies. Datacenter-location work uses CodeCarbon v2.4.1 to simulate LLM inference under the electricity mixes of the UAE, Iceland, Germany, and Texas while keeping hardware and workload fixed, thereby isolating the effect of regional grid carbon intensity (Hassan et al., 21 Nov 2025). Workflow-level economic-research experiments use CodeCarbon in a default Colab configuration to compare prompt-governed LDA pipelines, concluding that operational constraints and decision-rule prompts reduce runtime and estimated $E_{CO_2}=C\times P\times t$3 far more reliably than generic “green” language (Alonso-Robisco et al., 17 Mar 2026). Text-to-video benchmarking uses CodeCarbon with NVML and pyRAPL to measure GPU, CPU, and RAM energy for open text-to-video models, while observing that GPU accounts for more than 80% of total energy across models (Delavande et al., 23 Sep 2025). These applications collectively position CodeCarbon as a general observability substrate for Green AI experimentation.

6. Validation, limitations, and methodological disputes

The literature is explicit that CodeCarbon is useful but not universal. A systematic review states that “there exists no universal tool” for evaluating ML energy consumption and notes that tools disagree materially across use cases (Rodriguez et al., 2024). The same review reports that CodeCarbon is among the tools often closest to an external reference meter in comparative experiments, yet also stresses hardware-support limitations, the lack of full process isolation relative to CarbonTracker, and uncertainty about what on-chip interfaces are actually measuring versus estimating (Rodriguez et al., 2024). For cloud or virtualized environments, the review leaves open whether readily available tools remain reliable when utilization semantics are altered by virtualization.

A dedicated validation study strengthens that caution. Comparing CodeCarbon 3.0.1 against wall-socket measurements on a workstation with an Intel i9-13900K and RTX 4090, the study finds that CodeCarbon “better follows the ground-truth patterns, but consistently underestimates the consumption by 20–30%,” with dynamic power error often exceeding 100 W and dramatically worse behavior for CPU-only inference than for GPU inference (Fischer, 26 Sep 2025). The paper interprets this underestimation structurally: software-internal telemetry misses some system-level contributors such as power-supply inefficiencies, cooling overhead, peripherals, and other unprofiled components. The implication is that CodeCarbon outputs are often better treated as lower bounds on full-system operational energy than as wall-plug equivalents.

Individual application papers add further caveats. The CompactifAI study, for example, uses a tightly controlled VM but reports no repeated-run protocol, no monitoring interval, no batch size, and no uncertainty analysis, so the published numbers appear to correspond to single end-to-end runs per model and configuration (Fovet et al., 7 Jul 2025). At the opposite end of scope, project-level life-cycle work on the Moshi foundation model argues that even perfect run-level operational accounting would remain incomplete because hardware manufacturing, datacenter overheads, water consumption, resource depletion, failed runs, debugging, ablations, and other research stages dominate the footprint of a real GenAI project; in that study, the final successful runs account for less than 4% of total compute (López-Rauhut et al., 13 Apr 2026). CodeCarbon therefore occupies a clearly bounded methodological niche: it is a practical instrument for operational energy and carbon estimation of executed code, but not a substitute for external metering when high-accuracy system energy is required, and not a full life-cycle accounting framework.