Carbon-Aware Inference in 5 Minutes: A CarbonLayer Quickstart

CarbonLayer — Tue, 04 Aug 2026 01:21:47 +0000

If you read the last post on how CarbonLayer routes inference for lower carbon and water cost, here's the part that matters more: actually calling it.

1. Get an API key

Sign up, then generate a key from the dashboard's API Keys section. Keys are scoped per account — list, create, and revoke them anytime, nothing shared across teams unless you explicitly invite someone in.

2. Call the inference endpoint

curl -X POST https://carbonlayer.polsia.io/api/inference \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"prompt": "Your prompt here",
"model": "your-model-id"
}'
Or with fetch:

const res = await fetch("https://carbonlayer.polsia.io/api/inference", {
method: "POST",
headers: {
"Authorization": "Bearer YOUR_API_KEY",
"Content-Type": "application/json"
},
body: JSON.stringify({
prompt: "Your prompt here",
model: "your-model-id"
})
});
const data = await res.json();

3. Read the savings back

Every response carries the routing decision alongside the model output — which edge site served it, and what it saved versus a fixed-location baseline: savedCO2g, savedWaterMl, waterIntensityMlPerKwh.

4. Check cumulative impact

GET /api/usage — your own key's usage and savings over time
GET /api/network and GET /api/savings — aggregate numbers across the whole network
GET /api/grid-intensity — the live grid data feeding routing decisions, cached on a 5-minute window.

5. See it in the dashboard

Same numbers, visualized — no separate setup, it's live the moment your key starts making calls.

That's the whole loop: one API call, real routing, real numbers back. No separate SDK to install, no sustainability report to wait on.

Full reference at CarbonLayer's /docs.

CarbonLayer

CarbonLayer — Tue, 04 Aug 2026 01:06:43 +0000

How CarbonLayer Routes AI Inference to Cut Carbon — and Water — Per Request

Most "sustainable AI" claims are marketing copy with no math behind them. Here's the actual mechanism CarbonLayer uses to cut carbon and water cost per inference call, and how we measure it.

The problem

Every inference call runs somewhere — a specific data center, on a specific grid, at a specific moment. Grid carbon intensity swings hard by time of day and location (a request served from a coal-heavy grid at peak demand can cost 5-10x the CO₂ of the same request served from a renewable-heavy grid off-peak). Most inference routing ignores this entirely and optimizes purely for latency or cost.

What we do instead

CarbonLayer routes inference across 7 edge sites, factoring live grid intensity into the routing decision alongside latency and cost. We pull grid carbon data through a live adapter, cached on a 5-minute window (/api/grid-intensity) so routing decisions reflect near-real-time conditions, not stale averages.

The math, per request

Every inference call returns:

savedCO2g — grams of CO₂ avoided vs. a fixed-location baseline
savedWaterMl — millilitres of water avoided (data center cooling draws real water, and it scales with the same grid/thermal conditions as carbon)
waterIntensityMlPerKwh — the water-per-kWh figure for the site actually serving the request
This isn't an estimate applied after the fact — it's calculated per call, using the actual site the request landed on and the actual grid intensity at that moment.

Why water, not just carbon

Carbon gets all the attention. Water doesn't, and it should — data center cooling is a real, measurable draw that scales with compute the same way carbon does. We treat it as a first-class number, not a footnote.

Where you can see it

/api/usage — per-API-key usage and savings, so you can see the impact of your own calls
/api/network and /api/savings — aggregate carbon + water numbers across the network
Dashboard — the same numbers, visualized

Why this matters beyond one company's inference bill

Right now, most data center operators report carbon and water at the facility or annual level — self-reported, aggregated, impossible to verify against actual workload. When savings numbers are calculated per-request, tied to the real site and real grid conditions at that moment, that's a verifiable trail instead of a sustainability report nobody can check. Enough companies routing on real per-call data starts to create pressure that annual PR reports never do — a market signal for which sites and which grids actually perform, not just claim to.

That's the direction we're building toward: this started as inference routing, but the same mechanism — measure the real resource cost of a workload, route to where it's genuinely cheaper, make the number visible per call — extends past inference. Training runs carry the same carbon/water math, just at different scale. And industries with specific compute and compliance profiles (healthcare, fintech, public sector) need this accountability baked in, not bolted on after the fact.

The inference tracker is the first proof point. The bigger bet is that verifiable, per-workload resource accounting becomes infrastructure every AI workload runs on — not a badge you slap on afterward.

Check out CarbonLayer,
Cut AI Carbon by Up to 80%
Sustainable AI Infrastructure
Track carbon and water per inference. Free tier, no credit card. Sign up in minutes.
Route AI workloads to renewable windows automatically.
Free for up to 50K inferences/mo.

https://carbonlayer.polsia.app

DEV Community: CarbonLayer

Carbon-Aware Inference in 5 Minutes: A CarbonLayer Quickstart

CarbonLayer