What a Crumb Bouncer search costs the planet

This isn't an energy research paper. It's a small team's honest attempt to answer a fair question: if Crumb Bouncer uses AI, does that come with a heavy carbon footprint? The figures below are estimates assembled from public research on comparable AI models, then applied to how Crumb Bouncer actually works. They're not measurements, and they're not audited. We've published the method so anyone curious can check our reasoning.

An honest word about using AI

We use AI, and we didn't want to be glib about that on a page like this. AI carries a real energy cost, and waving it away would undercut the whole point of showing you the math.

So here's the thinking. Celiac disease isn't a preference or a diet trend – getting glutened means real illness, sometimes for days. If pointing this technology at helping someone walk into an unfamiliar restaurant and ask the right questions means fewer people get sick, and over time more restaurant staff who actually understand what celiac requires, we think that's a use worth the energy it costs.

And we built it to spend as little of that energy as we reasonably could. The hand-written library at the center of this page exists partly for exactly that reason: so the everyday search doesn't spin up an AI model at all. We'd rather do the work once, up front, than run a model again for every person who asks the same question.

Is any given use of AI “worth it”? That's a fair question, and one we don't think should be brushed aside. But the honest answer here is that the cost is genuinely small – smaller, as you'll see below, than the drive to the restaurant – and we'd rather aim this kind of technology at something that matters: helping people with a real medical condition eat out without fear.

What we're estimating

The energy used by the cloud services that answer one search – measured in watt-hours (Wh) of electricity. We don't try to count the energy your phone uses to run the app, your home Wi-Fi, or the upstream cost of training the AI models. Those are real, but they're common to nearly every app and not specific to Crumb Bouncer.

Where the science is uncertain, we deliberately use the high end of published ranges. It's better to overestimate our footprint and be honest than to lowball it.

The one design choice that decides almost everything: the library

Crumb Bouncer keeps a hand-written library of just over 1,000 guidance entries – 60-plus cuisines and hundreds of specific dishes, each written and reviewed by a person, not generated on the fly.

When your search matches something in that library – “Italian,” “sushi,” “pad thai,” the everyday searches – Crumb Bouncer simply looks up the pre-written answer and shows it to you. No AI model runs at all. It's the energy of loading a normal web page.

The AI – a Claude model from Anthropic, our AI provider – only runs when your search isn't in the library yet: an unusual cuisine, or a dish we haven't covered. Then it writes a fresh answer. That new answer often gets reviewed and added to the library, so the next person who searches the same thing gets the cached, no-AI version.

This is the whole story of Crumb Bouncer's energy use: the common case is a cache hit, and a cache hit uses no AI. Every other design in a typical AI app – where every request calls a model – would use far more energy than this.

What a single search costs

A generated answer uses roughly 10–50× more energy than a cached one, because it's the only case that runs an AI model. Cloud providers don't publish per-query energy, so the generated figure is drawn from independent research on comparable mid-size language models; we use the upper part of that range to avoid undercounting. Even so, a generated answer is a fraction of a watt-hour – and it's the exception, not the rule.

How often is a search cached?

Honestly: at launch, we can't quote you a precise hit rate – we don't have enough real search data yet, and we'd rather not invent a number.

What we can say is structural. The library is built around the cuisines and dishes people search most, which is where the everyday searches land. And it grows: we keep an anonymous log of which searches miss (just the cuisine and dish typed – no name, no account, nothing personal) and add the gaps. So the share of searches that are cached – and therefore run no AI – starts high and climbs over time. We'll update this page with a measured hit rate once we have enough data to stand behind one.

What else Crumb Bouncer runs on

Beyond the AI, Crumb Bouncer leans on a small set of ordinary cloud services. None of them is AI, and all are shared across every user, so the per-person share is tiny:

These are fixed-baseline services: a shared database costs about the same whether it serves ten people or ten thousand, so the per-user figure only falls as we grow.

Turning watt-hours into carbon

To convert electricity into greenhouse gas, we use the US national-average grid carbon intensity from the EPA's eGRID dataset: about 370 g CO₂-equivalent per kWh.

• A generated search (~1 Wh) works out to roughly 0.4 grams of CO₂.
• A cached search is a small fraction of that – on the order of a hundredth of a gram.

Where this could be wrong

1. Per-query AI energy is the biggest unknown. Providers don't publish it, and independent estimates vary by an order of magnitude. We use figures from published research on comparable models, at the high end of the range.
2. The cache-hit rate isn't measured yet. It's the other big variable, and it moves the average per-search energy up or down. We'll firm it up with real data and update this page.
3. Model efficiency is improving. Today's AI models are meaningfully more efficient than the same class of model was a couple of years ago. If our provider ships efficiency gains, these numbers come down.
4. Training energy is excluded. The energy to train the AI models we use is real, but it's spread across all of that model's users worldwide – often billions of queries. The share attributable to one Crumb Bouncer search is tiny and can't be measured cleanly, so we leave it out.
5. Device and infrastructure “embodied” energy is excluded. This is standard practice for software carbon estimates, but it's worth knowing.

If any of these inputs are materially wrong – in either direction – we'd genuinely like to know.

Sources

• Grid carbon intensity: US Environmental Protection Agency, Emissions & Generation Resource Integrated Database (eGRID). epa.gov/egrid
• Vehicle emissions: US Environmental Protection Agency, Automotive Trends Report. epa.gov/automotive-trends
• Electricity reference data: US Energy Information Administration. eia.gov
• AI inference energy ranges: Independent academic measurements of small and mid-size language models. Provider-specific per-query figures are not publicly disclosed.

Treat this as a snapshot

These estimates reflect our best understanding as of the date at the top. Several inputs – model efficiency, grid carbon intensity, and especially our own cache-hit rate – shift over time. We'll revise this when we have cause to, but we make no promise about how often. If the date above is more than a year old, treat the numbers as directional rather than current.