The water brief.
One dispatch, one number. That's the whole argument.
Every
POST /api/inferenceresponse carrieswaterMl,savedWaterMl, and the device'swaterIntensityMlPerKwh. We publish the tonnage on /api/savings and the per-region breakdown on /api/network. No NDA, no annual report embargo — read the actual live numbers whenever you want.
The water cost of generative AI rarely makes the headline. Kilowatt-hours do — those are the visible numbers energy grids and regulators already know how to measure. Water is the quiet one: cooling towers, adiabatic systems, on-site reclamation. It's also the number the communities building loudest objections are noticing first.
We discovered this issue was resonating publicly long before CarbonLayer shipped its first inference. A wave of petitions brought it to the front page in a way spreadsheets and ESG reports never had:
- Hold AI Developers Accountable for Toxic Data Centers in Our Neighborhoods — a campaign against contaminated runoff near active AI build-outs.
- Protect Our Water: Demand Accountability for Hazardous Data Center Practices — focused specifically on water draw, reclaimed-water chemistry, and disclosure.
- Ban and Put a Stop to Unwanted AI Data Centers in the U.S. — the loudest community-wide call for a moratorium on new builds in stressed regions.
These petitions show how strongly communities are asking for transparency — and they aren't wrong to ask. We can't credibly disagree with the request and respond with another opaque quarterly tonnage summary. The honest answer is what we shipped: the number, per inference, on every response.
What "transparent" actually means in the contract
Every successful POST /api/inference response carries four fields the dispatch logic
computes in-band, before the row is written to the ledger:
waterMl— the milliliters of water the chosen device drew for this call (devicewaterIntensity× kWh × 1,000).savedWaterMl— how much water was avoided versus a notional hyperscaler baseline (1,800 mL per kWh — the same comparator every leading provider faces).waterIntensityMlPerKwh— the per-region rolling value we report on /api/network, so you can audit which device your traffic is landing on.baselineWaterMl— the full counterfactual: what the same inference would have cost in water on a generic hyperscaler.
Numbers are illustrative — not marketing ceilings. A typical 50-token small-model request to a low-carbon Marseille site, modeled at roughly 120 gCO₂/kWh × 0.014 kWh, returns something like ~1.7 g CO₂ and ~7 mL of water. That's an example dispatch, not a maximum — the live numbers land where they land, and you can read them straight off the response.
What this page is NOT
CarbonLayer does not currently publish facility-level water-scarcity or basin-stress scores. The numbers above trace to per-site cooling-water coefficients (public engineering literature) and per-inference attribution math — not to an external scarcity dataset. Wiring a licensed scarcity source is a separate roadmap line.
When that integration lands, every published score will be stamped with the standard grid-resolution disclosure visible at the same eye-line as the figure: scores are attributed at ~30 × 30 mile hydrological grid resolution, so neighboring facilities inside the same grid cell can return identical values. The same vocabulary ships today on the per-region carbon and per-site water numbers so the disclosure language is consistent across non-licensed and licensed surfaces the day the scorer wires up.
Why per-inference, not per-quarter
Annual sustainability reports take 12–18 months to produce and another 6 to publish. Grassroots campaigns that brought this issue to public attention have a much tighter feedback loop — petition, town hall, council vote, water-rights filing. The disclosure cadence has to match the people asking the questions, not the calendar of an audit partner.
So we don't gate the number behind an annual report or a marketing tier. The same field
that lands on the developer's response lands on
/api/savings and is the same field a CSRD tonnage roll-up reads from.
One source, no two-track disclosure where the public number trails the customer number by
a quarter.
Worked example · Marseille · claude-haiku · 50 tokens
One small request, all four water fields visible.
waterMl— ~7 (modeled — a per-inference slice of the facility total)savedWaterMl— ~18 (modeled — a baseline comparator delta)baselineWaterMl— ~25 (modeled — the 1.8 L/kWh notional hyperscaler)waterIntensityMlPerKwh— 510 (measured — per-site seed coefficient)Toy numbers from
carbon-router.ts: 0.014 kWh × 510 mL/kWh device water intensity, vs 1,800 mL/kWh notional hyperscaler baseline. Every number carries amodeledormeasuredchip directly on the response (waterSource/carbonSource/*IntensitySourceondevice) — see the methodology page for the boundary, and the worked example below for the chip pattern in the actual wire shape.
On offsetting, and what we're exploring next
We are exploring a bamboo-planting partnership as a future program that could convert avoided hyperscaler water into retained watershed capacity. It is not a confirmed initiative yet, and we are not going to call it one until the program actually exists. If we move forward with a bamboo partnership, we'd want it to be transparent too: site-level planting numbers, survival rates over time, and a clear published scope of what the partnership actually covers versus what it doesn't.
Until then, the only defensible answer we have to "how much water did your last inference use?" is the field on the response. No proxy disclosure, no approximation. Same response shape, same cadence, same number whether you're prototyping in a free tier or running platform-scale traffic.