When you ship a chatbot, do you know where it drinks? Most of us can recite our token costs to four decimal places and have no idea how many gallons of water went into answering a user’s question. That gap just got a little smaller, thanks to a PDF that wasn’t blacked out properly.
Nebraska data centers are required to file annual reports with the state Department of Water, Energy, and Environment, detailing electricity and water consumption. State law lets operators redact a lot of it. In this case, the redaction failed, and the numbers underneath became readable.
What the numbers actually say
Here’s what came out of the filings:
- Google’s Lincoln data center, filed under Agate LLC, reported peak electricity demand of 52.65 megawatts and annual water consumption of roughly 13 million gallons.
- Across six Nebraska data centers, total annual water consumption came to approximately 765 million gallons.
- Google’s Fireball Group LLC facility in Papillion reported the highest water use of the group, around 548 million gallons in 2025.
Do the division and the Papillion site alone accounts for somewhere north of 70 percent of that 765 million gallon total. The Lincoln facility that generated the headlines is, by comparison, a rounding error in the same state. That asymmetry is the part I find most useful as a builder, and I’ll come back to it.
Why a bot developer should care about a Nebraska water report
I build bots. Retrieval pipelines, agent loops, scheduled scrapers, the whole kit. The abstraction we work inside is deliberately clean: you call an endpoint, you get tokens back, you pay cents. Nothing in that loop tells you that a megawatt-scale facility somewhere is pulling electricity and water to make it happen.
I’m not going to pretend I can convert 52.65 megawatts into a per-query water figure. Nobody can do that honestly without knowing the workload mix, the cooling design, the climate, and the utilization curve, and none of that was in these filings. What I can say is that peak demand is the number utilities plan around. A 52.65 MW peak is a commitment that something on the grid has to be able to serve, whether or not it’s being used at 3 a.m.
That maps onto something every bot builder already understands: provisioned capacity versus actual use. We’ve all overprovisioned a worker pool because traffic might spike. Data centers do the same thing at a scale where the overprovisioning shows up in a state agency’s spreadsheet.
The design lessons I’m taking from this
The disclosure doesn’t change my architecture overnight, but it sharpens a few habits I’d already been drifting toward:
- Treat retries as a physical cost, not a logical one. An agent loop that retries five times on a malformed tool call isn’t just burning your budget. It’s burning capacity somewhere real. Cap your loops.
- Cache aggressively and unapologetically. Most bots answer the same twenty questions over and over. A semantic cache in front of your model call is the single highest-use efficiency move available, and I say that having measured it on my own projects.
- Right-size the model to the task. Classification and routing do not need a frontier model. Running a small model for intent detection and escalating only when needed cuts both latency and load.
- Batch what doesn’t need to be live. Nightly embedding jobs, document reindexing, summarization backlogs. If it can run off-peak, run it off-peak.
- Instrument your own usage before someone else has to. Log tokens, calls, retries, and cache hit rates per feature. You cannot argue about efficiency without numbers.
Redaction as a failed access control
There’s a second lesson here that’s purely technical, and it’s one I’d put in front of anyone building document pipelines. A black rectangle drawn on top of a PDF is not redaction. The text layer stays underneath. Any extraction library reads straight through it. If your bot handles documents that users consider sensitive, the only reliable approach is to remove the underlying content, not cover it, then verify by re-extracting the output and checking what comes back.
I’ve seen this bug in production pipelines more than once. Someone builds a tool that renders a redaction overlay for human reviewers, everyone signs off on the visual, and the machine-readable copy ships intact. Test your redaction the way an adversary would: with a parser, not with your eyes.
Where this leaves us
One state, six facilities, a handful of figures that were never meant to be public. That’s a thin slice of a very large system, and I’d rather have a thin slice of verified numbers than a thick stack of guesses. The useful takeaway isn’t outrage, it’s calibration. Our bots run on machinery with measurable appetites, and we now have a few real measurements instead of none.
Go look at your retry logic. Go check your cache hit rate. Then go check whether your redaction actually redacts.
🕒 Published: