AI Compute Footprint Calculator Explains AI’s Impact | Zeniteq
Loading
Loading article
AI Compute Footprint Calculator Explains AI’s Impact
The open calculator compares AI tasks with everyday activities while exposing the assumptions behind its energy, water, carbon and infrastructure estimates.
The AI Compute Footprint calculator provides a transparent framework for estimating the environmental costs of AI, including electricity, water usage, carbon emissions, and data center space. Unlike opaque tools, it allows users to inspect the underlying logic in its JavaScript model, which calculates impacts based on facility-level watt-hours per task rather than individual chip consumption. By scaling variables like population size and task frequency, users can visualize how different workloads, from simple text queries to intensive video generation, translate into tangible infrastructure requirements and everyday environmental equivalents like driving or home electricity use.
AI Compute Footprint lets readers model the environmental cost of AI tasks, from a short answer to a functional app, and compare the results with activities such as driving, flying and using electricity at home. Its most useful feature is the ability to inspect the sources, assumptions and confidence behind those estimates.
Created by Tim Plaisted, the project publishes its calculations and underlying data on GitHub. The interface covers electricity, water, carbon dioxide, power demand and data-centre space, with controls for scaling a task from individual use to large populations. The repository lists a research cut-off of 11 October 2026.
That transparency gives readers a practical way to examine environmental claims about AI. A headline number can hide the workload, electricity grid or cooling assumptions behind it. This calculator puts those ingredients within reach, although its results remain estimates of modeled workloads, not measurements of someone’s particular ChatGPT, Claude or image-generation request.
What the Calculator Shows
AI Compute Footprint organises 16 tasks by estimated electricity per task. The list starts with a short answer and moves through images, songs, document drafts, presentations, small programs, video and increasingly substantial software projects.
According to the project documentation, an equation bar controls the task, frequency, number of people and period. Readers can change those inputs to explore personal use or a much larger scenario.
The outputs cover several different physical quantities:
Energy: electricity consumed over the selected period.
Power draw: the rate of electricity use, shown against references ranging from an LED bulb to worldwide electricity demand.
Work with Zeniteq
Promote your app with us
Reach readers exploring AI tools and workflows. Discover sponsorship and advertising options for your app.
Water: an estimate covering on-site cooling and water associated with generating electricity.
CO₂: electricity-related emissions calculated using a grid-intensity assumption.
Data-centre space: estimated floor and whole-site area, illustrated against familiar physical scales.
The distinction between energy and power matters. A watt-hour measures an amount of energy; a watt measures a rate. A workload spread over a year can consume substantial electricity without requiring the same power capacity as that workload concentrated into a day.
The page also compares its outputs with activities the selected population already undertakes, including eating beef, driving, flying, home electricity and home water use. Those comparisons make unfamiliar units easier to interpret. They do not, by themselves, make the underlying accounting boundaries equivalent.
I’d use an everyday comparison as a scale reference, then inspect the assumptions before treating it as an environmental ranking. The denominator can matter as much as the headline result.
How the Calculator Builds Its Estimates
The repository makes the model unusually easy to locate: it says every number, range, note and source lives in data/model.js, and the page recalculates from that file. Someone checking an assumption therefore has a defined place to start, without searching through unrelated interface code.
Tasks = people × share using AI × uses per day × days
It then converts that task count into electricity:
Electricity = tasks × facility-level watt-hours per task
“Facility-level” is an important qualifier. It describes the modeled electricity boundary; it is not simply a reading of a GPU chip’s power consumption.
For groups of 50 people or more, the tool counts only daily AI users by default. That means a population scenario is not automatically equivalent to every person in that population using AI every day.
This default deserves attention when comparing screenshots or shared results. Two scenarios can name the same population yet produce different totals because one uses an adoption share and another assumes universal use. Before debating the total, check how many people the model actually counts.
Water and Carbon Depend on Separate Assumptions
After estimating electricity, the model applies two further conversions:
Water = electricity × on-site cooling and power-generation water factors
CO₂ = electricity × grid carbon intensity
These equations explain why a single universal “water per AI request” or “carbon per AI request” figure is difficult to defend. Even with identical modeled electricity consumption, a different cooling factor or electricity mix changes the answer.
The selected grid assumption also needs to describe the computing operation being modeled. A reader’s home country does not automatically identify the grid supplying a remote AI service.
Within this model, doubling the number of tasks doubles electricity, water and carbon when all conversion factors stay fixed. That is a consequence of the published equations. It is not evidence that a real provider’s infrastructure scales perfectly linearly at every level of demand.
The Hardware Display Is a Modeled Equivalent
The infrastructure calculations introduce additional assumptions. The repository uses 1.5 kW per H100-class GPU, all-in, at 70% average draw to convert electricity into GPU time.
Multiplying those figures gives an assumed average of 1.05 kW per modeled GPU. Dividing electricity in kilowatt-hours by that power produces GPU-hours. The model then divides GPU time by eight to estimate server time, and uses further assumptions to estimate GPUs, racks and data centres.
Floor and site area are calculated using whole racks, with a minimum of one, and area-per-megawatt figures from recent AI campuses. Those choices are documented in the README.
The practical consequence is subtle: the space illustration should be read as an infrastructure equivalent, not as proof that one person’s activity occupies a dedicated rack. Electricity can scale continuously in the model while a whole-rack illustration changes in steps. That is a useful visualisation constraint to understand before interpreting a small personal scenario.
Confidence and Sources Are Part of the Interface
The live page includes a “How sure is this?” section with confidence explanations and sources, alongside tables for infrastructure assumptions, grids and per-person comparisons. Information icons provide routes to supporting details.
Those features let readers separate questions that are often blurred together:
What does the model assume?
Where did the assumption come from?
How much confidence should a reader place in it?
A linked source answers only part of that sequence. It may concern a particular model, output length, hardware setup or type of workload. Applying it to a broader category still requires judgment.
The repository puts the central limitation plainly: “Estimates, not measurements.” This article analyses the published page and documentation; it does not independently validate the outputs or measure requests sent to an AI service.
My view is that the inspectable calculation path is the project’s strongest contribution. A disputed estimate can be traced to a task definition, energy assumption or conversion factor. That makes disagreement more productive than arguing over an unexplained final number.
The research cut-off also gives readers a useful timestamp. Estimates assembled from evidence available by 11 October 2026 should be checked against the workload and technology being discussed, especially when newer models or different generation settings are involved.
How It Compares With Another Public Calculator
Dan Taylor-Watt’s AI Environmental Impact Calculator offers a useful comparison. It takes counts of chatbot messages, images, video clips and agentic coding sessions, then estimates annual electricity, CO₂-equivalent emissions and water.
AI Compute Footprint places more emphasis on scaling tasks across populations and visualising infrastructure. Taylor-Watt’s tool foregrounds a personal usage budget, regional grid selection and explicit per-use assumptions.
Its published central estimates and ranges include:
Activity in Taylor-Watt’s calculator
Central electricity estimate
Published range
Quick chatbot question
0.3 Wh
0.15–1 Wh
AI image
1.2 Wh
0.3–3 Wh
Approximately five-second AI video
500 Wh
100–1,000 Wh
Typical agentic coding session
41 Wh
15–120 Wh
These are Taylor-Watt’s modeling assumptions, not independent measurements made for this article or verified values for every AI product. His page attributes them to a mixture of company disclosures, research and other published analysis. The opened AI Compute Footprint documentation does not expose enough numerical detail to populate a like-for-like per-task table between the two tools.
The comparison still reveals something useful about task definitions. Using Taylor-Watt’s central values, a typical coding session consumes about 137 times the electricity of a quick chatbot message: 41 divided by 0.3. A five-second video comes to roughly 1,667 quick messages using the same arithmetic.
Those are derived comparisons within one calculator’s assumptions. They show why “one AI use” is an inadequate unit for environmental discussion. A short response, a multi-step coding session and a video-generation job represent very different workloads.
Taylor-Watt also changes assumptions for longer text tasks, reasoning modes, video duration and coding-session size. His page warns that per-use estimates could be several times higher or lower than central values.
I would therefore avoid interpreting AI Compute Footprint’s ordered task list as a permanent ranking of every product. It is a ranking under a chosen model. The settings and work represented by each task remain essential context.
What Everyday Comparisons Can Hide
Both calculators translate technical quantities into familiar activities, but the accounting boundary needs checking before drawing conclusions.
Taylor-Watt’s water factor, for example, covers cooling plus electricity generation, while his page separately describes an on-site-only water figure reported by Google. Comparing those numbers without their scope would make one estimate appear larger partly because it counts more categories of water use.
His streaming-video comparison presents a similar issue. The page says it includes the viewing device, while its AI estimates exclude the user’s device. That can be useful for a rough sense of scale, but it is not a fully matched comparison of two services. The calculator discloses these differences.
AI Compute Footprint has its own clear boundary: inference only. Training and hardware manufacturing are excluded. A low estimate for one modeled request therefore cannot settle the environmental footprint of developing and operating an entire AI system.
The useful distinction is between a workload estimate and a lifecycle assessment. This tool helps explain the former. Its published scope leaves important parts of the latter outside the calculation.
How to Use the Transparency
A productive way to read AI Compute Footprint is to work backwards from the result:
Check the task. Confirm that its modeled workload resembles the activity being discussed.
Check the demand. Inspect frequency, duration, population and the share counted as daily AI users.
Check the electricity estimate. Read the source and confidence explanation before treating a central value as precise.
Check the conversions. Identify the grid and water assumptions.
Check the comparison boundary. Establish what each everyday reference includes.
This approach turns the calculator into a way to audit a claim. If two estimates disagree, the task definition or conversion factors may explain the difference before either calculation is judged wrong.
The project’s licensing supports that scrutiny. Its repository licenses code under MIT, while data, text and design use CC BY 4.0, with attribution to AI Compute Footprint by Tim Plaisted.
Publishing the model does not make every input correct. It makes the inputs inspectable and reusable. For readers trying to evaluate AI environmental claims, that is a concrete improvement over a standalone number with no visible calculation behind it.
Frequently Asked Questions
3 questions
1
Does AI Compute Footprint Measure My AI Requests?
No. It models selected tasks using published assumptions and sources. It does not measure the electricity or water used by your particular request.
2
Does It Include Model Training and Chip Manufacturing?
No. The documented scope covers inference, meaning running AI workloads. Training and hardware manufacturing are excluded.
3
Can the Code and Data Be Reused?
Yes, subject to their licences. The code uses MIT; the data, text and design use CC BY 4.0, which requires attribution. The repository provides the licensing details.
