Transparency · Updated daily
AI and our environmental footprint
Kindora uses AI models to help nonprofits find and win funding. Those models run in data centers that use electricity and water, and the build-out of that infrastructure is falling hardest on some frontline communities. This page is our attempt to estimate our share for the sources where we have usable data, and to say plainly what we can't yet measure.
First, what we actually counted
MeasuredAnthropic and OpenAI each report how many tokens (units of text) our account processed, by model. These are counts, not estimates: the 90 days from July 17, 2026 through October 14, 2026.
Our Azure hosting is handled separately and isn't counted here. Microsoft's carbon tool allocates an emissions figure to our production subscription (13 months of it), but that allocation is Microsoft's own estimate rather than a measurement, so it belongs with the estimated figures below.
What that adds up to
EstimatedTurning those counts into emissions is where the uncertainty is. We cover the sources we could include: our AI model use and our Azure hosting.
Our providers don't publish how much electricity our requests actually use, so we apply energy assumptions we chose and a range of US grid intensities. Depending on which end of those assumptions is closer to the truth, the same usage works out to anywhere from 0.6 to 12 tonnes.
Across the full range, from about 0.2 to about 2.7 homes. The divisor is 10,380 kilowatt-hours, the electricity an average US residential utility customer bought from the grid in a year, per the US Energy Information Administration. This card covers our AI electricity only: Microsoft reports our Azure share as emissions rather than kilowatt-hours, so there is no Azure figure to include here.
Across the full range, from about 0.13 to about 2.5 cars. The divisor is 4.6 tonnes of tailpipe CO₂ a year for a typical US gasoline passenger vehicle, per the US Environmental Protection Agency. Unlike the electricity card, this one uses our total, so it includes Azure hosting whenever Microsoft's allocation is available.
Both comparisons are for scale only, and the two are not drawn to the same scope: one is our AI electricity, the other our total emissions. A household and a car also emit in different places, on different grids, burning different fuel. Treat these as a rough sense of size rather than a like-for-like swap.
- These are scenarios built on assumptions we chose, not a measured result or a statistical range.
- They are annualized run rates, not emissions for a single reporting year. The AI figures scale up our use from July 17, 2026 to October 14, 2026. The Azure figure uses Microsoft's allocation for 13 of the 13 months in our lookback, scaled to a year.
- This is not a complete footprint; see “What's not included” below.
These figures move with how much we use AI, which models we use, provider corrections to past data, and changes to our method. A lower figure is not evidence that we have reduced emissions.
Usage period ends October 14, 2026.
Month by month
Estimated electricity for each full month we have data for, on the middle assumptions. All months are calculated with method version 2026-09-11.1. A bar moves with how much text we sent that month and how much the models wrote back, the mix of models behind it, and how much of the input came from cache. Output counts for more per token than input in our assumptions, so two months with the same total can land differently. A lower month isn't evidence that anything about how we run got cleaner.
How we got from tokens to tonnes
- 1We take the token counts our providers report, by model, for the 90 days from July 17, 2026 through October 14, 2026, and scale them to a year. The period ends two days before each update because the most recent provider data can still change. Our own development and testing is in there too: about 19% of the modelled AI electricity in the middle scenario.
- 2We multiply those tokens by an energy-per-token assumption. Published research informs it, but no study gives these exact figures, and the AI companies we use don't publish them. The assumptions are meant to include data-center overhead, so we don't add a separate overhead factor.
- 3We convert electricity to emissions using illustrative carbon intensities from the EPA's eGRID2023 data, then add Microsoft's own figure for our Azure hosting. We don't know which data centers actually served our requests, so the grid figures are illustrative rather than located.
Our model treats energy as proportional to the number of tokens, but very long inputs can use disproportionately more energy. When we developed this method in September 2026, our AI assistant averaged about 57,000 input tokens per request, and we haven't analysed how request lengths are distributed. Our model doesn't fully capture this effect, so real energy use could be higher than all three scenarios.
For Azure hosting we use the estimate Microsoft's carbon tool allocates to our production subscription, under Microsoft's own method. In our September 2026 review, two other Azure subscriptions returned no usable report; they're excluded from this estimate.
Method version 2026-09-11.1.
| Our model category | Low scenario | Middle scenario | High scenario |
|---|---|---|---|
| Models we classify as smaller | 0.01 / 0.1 | 0.05 / 0.3 | 0.15 / 1 |
| Models we classify as larger | 0.05 / 0.3 | 0.2 / 1 | 0.4 / 3 |
The categories are ours. Providers don't publish sizes for every model we use.
Reused (cached) input is counted at 10%, 25% and 100% of a regular input token in the low, middle and high scenarios.
| Low scenario | 0.27 | EPA eGRID2023 SRVC (Virginia/Carolinas), 596.3 lb/MWh |
| Middle scenario | 0.35 | EPA eGRID2023 US average, 770.9 lb/MWh |
| High scenario | 0.41 | EPA eGRID2023 SRTV (Tennessee Valley), 903.3 lb/MWh |
Research that informed our assumptions
- Epoch AI (2025-02): GPT-4o ~0.3 Wh per 500 output tokens; ~2.5 Wh at 10k input; ~40 Wh at 100k input
- Google (2025-08): 0.24 Wh per median Gemini text prompt
- Jegham et al. v6 (2025-11): Claude 3.7 Sonnet 0.95-5.67 Wh per prompt, PUE-inclusive
How we currently use AI (not a claimed reduction)
Most of our work goes to small, light models rather than the big ones. We chose them because they are cheaper and faster. We can't tell you what that does to our emissions, for the reason below.
We use smaller models for routine work like sorting and scoring grant opportunities, and reserve larger ones for tasks that need them. Output is the more energy-intensive half in every estimate we're aware of.
Cached input is text our providers had already processed for us, so they reused that earlier work instead of processing it from scratch. We still submit the text. Our middle scenario counts a cached token at a quarter of a fresh one; our high scenario gives it no discount at all.
Priced entirely at our larger-model factors, the same tokens would come out here. This is arithmetic inside the assumptions in the table above, not a measurement, and we are not claiming our emissions went down because of it. We assume a smaller model draws roughly a quarter to a third of the energy of a larger one per token, because that is the direction the published research points. Our providers don't publish per-model energy, so nobody outside those companies can check the assumption, ourselves included. If it is wrong, this difference narrows or disappears. AI use only.
We haven't measured whether the way we route work between models changes our emissions, and we haven't set a quantified reduction target. The data that would settle it isn't published.
We don't train models ourselves. We do rely on models others trained, and we can't assign ourselves a share of that: providers don't disclose enough to allocate one, so training is excluded from these figures rather than counted as zero.
The figures on this page will most likely go up as Kindora grows.
What's not included
- Emissions from training the AI models and from building the data centers and chips. Providers don't disclose enough to assign a share to us. We don't train models ourselves, but we rely on models others trained.
- Smaller AI and web-search services we use, including embeddings, Perplexity, Cohere reranking, Firecrawl, Tavily and Apify.
- Our other hosting: AWS, Vercel, Supabase and Redis Cloud. In our September 2026 review, two other Azure subscriptions also returned no usable report. We haven't obtained usable account-level emissions figures for these, and we don't have a defensible substitute.
- AI coding-assistant subscriptions we use to build Kindora.
- Our laptops, home offices and travel.
- Water. We can't estimate our water use reliably, because we don't know which facilities serve our requests or how much water they use.
What we can't see
We don't choose, and can't currently confirm, which data centers serve our requests.
In May 2026, TechCrunch reported that Anthropic, one of our AI providers, had contracted the entire output of xAI's Colossus 1 data center near Memphis. The report doesn't say whether that capacity serves API customers like us. The gas turbines xAI used to power Colossus 1 were located in Boxtown, where residents and environmental-justice groups have opposed them. We don't know whether any of our requests are served there.
What we don't claim
We don't describe Kindora as carbon neutral, net zero or climate positive, and we don't buy offsets to support such a claim.
Estimates and limitations
- These figures are estimates from Kindora's own model. They are not a measured greenhouse-gas inventory, and no third party has reviewed or verified them.
- They rely on assumptions we chose and describe above. Actual emissions could be higher or lower, including outside the scenarios shown.
- The figures update automatically from usage data reported by Anthropic and OpenAI and, when available, Microsoft's Azure carbon allocation. They can change when providers correct that data or when we revise our method; each update records the method version.
- The figures cover only the sources listed above. They say nothing about the environmental attributes of any Kindora product or plan.
Questions or corrections: support@kindora.co