Water transparency: per-inference data other data centers won’t show you

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 (device waterIntensity × 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.

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.

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.