Carbon
Energy times location-based grid intensity, with a carbon-price band rather than fake precision.
Footprint
Estimate the environmental cost of AI workloads
Class1 computes carbon, water, and materials deltas on the same Monte Carlo draws as dollars, so the footprint has the same approval moment as the spend.
Why it sells
Finance asks for dollars. Boards increasingly ask for exposure.
Carbon is not the same geography as water. A cheaper or lower-carbon region can still be water-stressed.
Class1 makes the tradeoff visible before architecture choices become production habits.
Second-currency method
The footprint report is not decoration beside the cost report. It uses the same approval moment.
A pull request can increase output length, fallback rate, context size, retry pressure, or tool schema load. Those same drivers affect energy. Class1 calculates footprint deltas on the same Monte Carlo discipline as dollars so the environmental exposure is tied to the software change, not to a generic annual sustainability estimate. This guarantees that sustainability is treated with the same rigorous mathematical discipline as financial risk.
Carbon and water are separated because the best carbon answer is not always the best water answer. Region choice, grid intensity, WUE, and water scarcity can point in different directions. A governance report that collapses them into one green score hides the tradeoff the buyer needs to see. For example, moving compute to a desert region might yield 100% solar energy (low carbon), but severely exacerbate local water stress.
Materials are treated honestly. API inference usually excludes provider Scope 3 because the customer cannot inspect the provider hardware inventory. Owned hardware, however, can include embodied carbon, material depletion pressure, and e-waste because the equipment choice is part of the customer's architecture. By keeping these distinctions clear, Class1 prevents greenwashing and provides actionable metrics.
Footprint auditor
Footprint buying triggers
Where the second currency becomes a business decision.
Regulated reportingEnterprises increasingly need explainable AI energy and sustainability assumptions, especially when workloads move from experiments to recurring product paths.
Region strategyThe same workload can look different in Virginia, Quebec, Sweden, or Mumbai. The buyer needs to see carbon and water separately before choosing default deployment regions.
Build versus buyOwned hardware changes materials and embodied impact. API usage shifts much of that burden to provider disclosures and should be labelled as such.
Budget reviewWhen P90 dollars are near the approval line, a footprint delta can become the additional reason to cap context, shrink output, or redesign the workflow.
Water
Energy times WUE times AWARE scarcity. Water geography is not carbon geography.
Materials
Owned hardware includes embodied carbon, ADP materials pressure, and e-waste. API inference declares provider Scope 3 as excluded.
Calibration
Provider carbon actuals can feed the same actuarial table pattern as cost actuals.
Deeper context
The Class1 engine
At the heart of our platform lies a strict adherence to the principles of cost engineering, adapted for the unpredictable nature of Large Language Models. Unlike traditional software where compute costs are deterministic and tied directly to traffic, AI feature costs are highly variable. They depend on model selection, input token length, output token variability, the frequency of retries due to hallucinations or malformed JSON, and dynamic fallback chains.
To capture this complexity, Class1 employs Monte Carlo simulations using Common Random Numbers (CRN). By modeling the system before and after a pull request across thousands of synthetic scenarios, we isolate the true cost delta of your architectural change from background noise. This approach allows us to assign an AACE (Association for the Advancement of Cost Engineering) estimate class to the forecast, communicating both the expected cost and the confidence interval.
Furthermore, this estimation does not happen in a vacuum. The Blue Book ledger records historical execution data, creating a closed-loop calibration system. As your team merges changes and actuals are observed in production, the engine updates its actuarial tables. This continuous feedback loop ensures that our pre-merge budget gates remain accurate and actionable, preventing catastrophic cost overruns before they reach production while maintaining developer velocity.