The cost of AI that never shows up on the invoice

A new report finally puts real numbers to what AI actually uses, including the part of the cost that never reaches your invoice.

An AI chip that has been hooked up to both water and electricity.

TLDR:

If you only have a minute, here is the heart of it. When a business adds an AI feature, it sees a bill for the money and almost nothing else, while the real cost, the electricity and water and land and electronic waste behind every prompt, stays out of sight because it is carried by people far away who never chose it. This month the United Nations University gathered those scattered numbers into one place, and they turn out to be larger and stranger than most of us assumed. Efficiency helps, but it will never be enough on its own, and the one lever still in our hands is the oldest one there is, choosing the lightest tool that actually does the job and asking, every so often, whether a thing needs building at all.

This month a bill landed in my inbox for all the testing and playing around I had been doing with Claude, the AI tool I reach for most these days, and I sat for a moment looking at it the way you sometimes look at something ordinary that suddenly seems worth a second glance. It was a short document. It told me how much this month’s usage had cost in the local currency, and then it stopped. It almost feels reassuring how tidy a bill like that looks, because it gives the impression that the whole story of what you used fits neatly onto a single line. But the longer I sat with that line, the more I came to feel that it was misleading in a way that is hard to point at, because of everything it left out.

Over the past year or so we have watched the number of jobs in tech fall in a way that still unsettles me, and part of that is because some of those roles have been handed to AI, either by giving the people who remain a set of tools meant to lift both their output and the quality of their work, or by building agents that take the task over entirely. I am not raising this to wander into the question of jobs, which deserves a long and careful conversation of its own. I mention it because it says something about scale. AI has become genuinely capable in a way it simply was not a few years ago, when it could barely translate a sentence without leaving grammatical mistakes scattered through it, and now it plans and solves fairly complex problems across one industry after another. It has become woven into my own field as well, where it helps write the code behind projects and, with tools like Claude Design, has started reaching into the design side too. And the more it becomes part of everything we do, the more often that bill arrives, and the more weight sits behind every line on it.

When the machine used to push back

To understand why that bill bothers me, it helps to go back a little, to a time when the machine itself refused to let you be wasteful. When I think about the early days of programming, long before my own time at the keyboard, every line of code carried weight because the hardware gave you no room to be careless with it. Memory was scarce, and so was processing power, and so efficiency was not some virtue you reached for on the days you had the energy for it, it was simply the price of getting anything to run at all, and in that sense the constraint itself did a lot of the teaching. You wrote lean code because the machine sitting in front of you would not tolerate anything heavier.

Then came the long stretch of years where hardware kept getting faster, more or less on the rhythm that Moore’s Law described, and something subtle shifted in the way we worked, and the old pressure to be careful slowly eased. If the machine was always going to be quicker next year, and the connection always a little fatter, then the small inefficiencies in your code stopped feeling like they mattered very much, and the honest question many of us started to ask, sometimes without even noticing we were asking it, was why spend an evening optimizing something when the hardware would absorb the cost for you anyway. I understand that logic completely, because I lived inside it for years, but the result was that a whole generation of software slowly grew heavier, since the thing that used to keep it honest had faded into the background.

What is happening now with AI is a strange echo of that same story, except the cost has moved somewhere we cannot see it at all. With the old hardware, at least the constraint was right there on your desk, in the slowness of the machine, reminding you it existed. The machine that does the work now is not on your desk, though, and it never will be. It sits in a data center somewhere you will most likely never visit, and the resources it burns through to answer you are spread out across power grids, water tables, and eventually landfills, in places that tend to be far away from both you and the person who built the feature in the first place. The bill you receive is honest about the money and silent about all of the rest, and it stays silent precisely because someone else, somewhere else, is the one actually paying for it.

This is the thing I want to spend some time on, because it has been sitting with me for a while and I finally have something solid to point at. This month the United Nations University released a report with the fairly plain title of the Environmental Cost of AI’s Energy Use, and what makes it genuinely useful is that it gathers the pieces that are usually scattered across different conversations, the carbon, the water, the land, and the electronic waste, and puts them in one place with real numbers attached. I am going to walk through some of those numbers, and the point is not to frighten anyone, because guilt has never made me a better developer and I doubt it does much for anyone. What I am after is simpler than fear, which is that it is hard to feel the weight of a thing until you can actually see it written down.

Training is only one side of the footprint

For several years the story we were told about the cost of AI pointed, gently, in the wrong direction. The picture most people ended up carrying is that the real expense happens once, up front, when a model is trained, and that after that the thing simply exists and can be used more or less freely, the way you might think of a bridge as costly to build and then close to free to drive across. I genuinely wish that were the case, because it would make all of this much simpler than it actually is.

None of this is to suggest that training is cheap, because it is not. The report puts the training of GPT-3 at around 1.3 gigawatt hours of electricity, and the training of GPT-4 somewhere between fifty and seventy gigawatt hours, which are not small figures by any measure. But the part that changes the entire shape of the problem is that training is not where most of the energy actually goes. The far larger share is spent later, in what gets called inference, which is really just a technical word for the model being used, every single time someone somewhere sends it a prompt and waits for it to answer.

To put that into something you can hold onto, the report estimates that a single text prompt uses around 0.42 watt hours of electricity on average, which sounds almost trivial right up until you remember how many of them there are. ChatGPT alone is estimated to handle something close to 2.5 billion prompts every single day, which works out to somewhere around 383 gigawatt hours of electricity a year for that one product on its own. So the feature you added does not cost once, the way training does. It costs a little every time it runs, more or less forever, and the more people use it the larger that running total grows. A text prompt, though, sits right at the cheap end of the scale. An image costs a great deal more than that, and a video more again, and the gap between them turns out to be wide enough that it deserves a moment of its own, which is where I want to go next.

Not every use weighs the same

Once you accept that the real cost lives in the using rather than the building, the next thing the report makes clear is that not every use weighs the same, and the differences between them are not small. A simple text task and a generated video are not two points sitting close together on a line, they are closer to different worlds. The report offers one comparison that stayed with me for days, because it turns these abstract figures into something almost domestic. The energy behind a single generated image could keep a ten watt LED bulb lit for roughly seventeen minutes, which already feels like more than you would expect to sit behind one picture. But the energy behind a single high complexity AI video could keep that very same bulb burning for around forty two hours, which is closer to two full days of light, spent on a clip that might last only a few seconds.

What I find most important here, though, is less the size of the numbers and more the place where the decision actually lives. The footprint of any given task is shaped by things like which model you reach for, how long your prompt is, what format you ask the result to come back in, and what resolution you want. Those are real choices, and they make a real difference to the total. But almost none of them are choices the person using the tool ever actually sees, because they are buried in the defaults of the product, decided once by someone else and then applied to everyone who comes along afterward. You are rarely asked whether you truly need the heaviest model for a small task, or whether a lighter output would have done the job just as well. The decision has already been made on your behalf, and it tends to be made on the side of more rather than less. This is the same instinct I keep circling back to in my own work, that choosing the lightest thing which actually does the job is one of the very few real levers we have, and it happens to be exactly the lever that product defaults lift out of our hands.

The part almost no one connects to a screen

Then there is the part that almost no one pictures when they think about a screen, which is water. For a long time it was something close to a kept secret that the data centers doing this work rely on enormous amounts of fresh water to keep their equipment cool, and that they often sit in regions where the people living nearby are already short of it to begin with. Getting honest figures out of these facilities has been difficult, which is part of why a report like this one matters, because it finally puts some weight behind a worry that for years was mostly intuition.

To make it tangible again, the report describes the water behind a single generated image as roughly two tablespoons, which sounds almost harmless until you multiply it across the billions of small requests happening every day. A single complex video, on the other hand, carries a water footprint of around 4.1 liters, which is close to two days of drinking water for one person, spent on something that might play for a handful of seconds.

The detail that genuinely surprised me, though, the kind that makes me trust the people who wrote this, is the way it refuses the comfortable version of the story. We tend to assume that if we simply move AI onto cleaner energy, the problem more or less takes care of itself. But low carbon does not automatically mean low water, or low land. The report shows that switching the electricity behind these systems from coal to bioenergy can cut the carbon footprint by around seventy percent, which certainly sounds like a clean win, while at the very same time increasing the water footprint more than thirtyfold and the land footprint a hundredfold. So the choice that looks greener on one axis can turn into the dirtier choice on another, and the reassuring idea that renewables on their own make AI harmless does not really survive a closer look.

The ground it sits on, and the metals it is built from

Beneath all of this sits the physical ground itself, along with the materials these machines are built from, and these are the parts of the story that sit furthest from anything you actually see on your screen. The report projects that the land footprint of AI infrastructure could pass 14,500 square kilometers by 2030, which is roughly twice the size of greater Jakarta, given over to the buildings that house all of this. And the hardware inside those buildings depends on critical minerals that have to be dug out of the ground, very often in places with weak environmental oversight, and frequently in the Global South. This is the upstream end of the bill, the part that is not only geographically distant from the person clicking the button but morally distant as well, because the real cost of pulling those minerals out of the earth lands on people and places that will almost never see the benefit of what gets built from them.

What gets left behind

And then there is the other end of it, the downstream end, where all of this eventually goes once it has been used up. This is the part that connects most directly to something I have been arguing for years, which is that lean software keeps hardware useful for longer than it would otherwise be. The report estimates that AI infrastructure could generate as much as 2.5 million tonnes of electronic waste every year by 2030. To make a number like that mean something, it is the rough equivalent of throwing away nearly 250 Eiffel Towers, a great deal of it ending up in lower income economies where the safeguards for handling that kind of waste are limited at best. Every time software grows heavier than it actually needs to be, it nudges the hardware underneath it toward the scrap heap a little sooner than it had to go, and this is the mountain that keeps growing at the bottom of that particular hill.

What changes once we can see the cost

Now I have to be honest about something, because it would be very easy for me to take all of this and turn it into a tidy argument that we simply need to make AI more efficient and then the problem more or less solves itself. That is the version of the story I would genuinely prefer to tell, since efficiency is the thing I have spent most of my career caring about. But the report points at something that complicates my own optimism, and I think it is far more useful to sit with that than to pretend it is not there. It is an old pattern, sometimes called the rebound effect, and sometimes the Jevons Paradox, and the idea behind it is uncomfortably simple. As these models become more efficient, they also become cheaper to run, and as they become cheaper, they end up being used a great deal more. The gains you make on each individual query have a way of being swallowed whole by the sheer growth in how many queries there are, so you make each one cost less and the world simply responds by doing ten times as much of it, and the total climbs rather than falls.

What that means, and it honestly took me a while to fully accept it, is that efficiency on its own is necessary but not sufficient. Writing leaner code and choosing lighter models genuinely matters, but if all it does is lower the price of doing more, then the saving simply evaporates. Some restraint has to come along with it. There has to be a willingness to put actual limits on things, on output length, on resolution, on whether a heavy generative model is being reached for when a far simpler tool would have handled the same task without complaint. That tension is real, and I would much rather name it plainly than pretend that my favorite solution is the whole of the answer.

And yet, even sitting with all of that, what I keep coming back to in this report is a reason for hope, even if it is not the warm and uplifting kind. It is genuinely hard to make a pattern like the rebound effect feel encouraging on its own terms. But what has actually changed, and I think this matters more than it first appears, is that the cost is finally out in the open. For the first time we have real figures for how much water and electricity sits behind all of this, and knowing the true scale of something is what has to come before you can ever begin to use it more carefully, because you cannot put limits on a cost you were never able to see. For years this was mostly a hunch, and now it is written down, and that on its own already feels like somewhere to start.

Once those numbers are visible, questions become possible that simply could not really be asked before. You can start to ask whether a particular use is actually worth what it costs, and that is a question that lives at the level of a single developer choosing a model on a Tuesday afternoon, but also far above any of us, at the level of governments who are only now starting to look seriously at limits, and perhaps one day at whether some uses are worth allowing at all when set against what they take. Because there is a real difference, once you can finally see the price, between spending this much water and electricity on the search for a treatment for a disease like cancer, or on something as large as hunger or drought or a changing climate, and spending the very same on generating yet another set of throwaway jokes. If we are going to carry a cost this size, then it seems far more defensible to aim it at the problems that actually deserve it, and the fact that we can even have that conversation now is, in its own modest way, real progress.

Who actually pays the bill

And this is what brings me to the part of the report that weighs the most, because it takes everything I have described so far and ties all of it to actual people and actual places. It is one thing to talk about grids and water tables in the abstract, where they stay safely theoretical, and quite another to look at the specific places where this bill has already landed on people who never sent a single prompt in their lives.

In Ireland, data centers accounted for around 21 percent of all metered electricity in 2023, which is more than every urban household in the country put together, and the strain grew serious enough that the national grid operator paused new data center approvals around Dublin until 2028. Uruguay tells a different version of the same story, where plans for a water hungry data center arrived in the middle of a 2023 drought that had already drained Montevideo’s freshwater reserves to the point where the tap water was no longer safe to drink. And underneath these particular stories sits a structural fact that is genuinely hard to look away from, which is that more than 90 percent of the world’s specialized AI computing is concentrated in just two countries, while more than 150 countries have little or no access to it at all. So the communities that host the infrastructure, and that inherit the water shortages and the mounting electronic waste, are very often not the ones using the technology in the first place. The cost did not disappear when it fell off the bottom of your invoice. It simply moved onto someone who never got any say in the matter.

The one lever that is actually yours

I want to end somewhere other than guilt, because guilt has never once made me a better developer and I doubt it will do much for you either. What the report points toward, in the end, is the same place I have been trying to get to in my own work for years, which is the idea of fitting the tool to the task instead of reaching for the most powerful thing in the room out of pure reflex. It means choosing the lightest model that can actually do the job, and asking for the lowest energy format that still meets the need, and then, every so often, sitting honestly with the harder question underneath all of it, which is whether a given feature needs generative AI at all, or whether we are reaching for it mostly because it is there and impressive rather than because it is genuinely the right thing for the job.

This is, in its own way, the same discipline I keep coming home to. It is the instinct behind writing lean code, and it is the same thing I think about when I remember how the engineers on the Apollo missions had to squeeze every last drop of capability out of a machine that gave them almost nothing to work with, because the constraint left them no real choice but to be deliberate about every decision. It is the same thing I mean when I say that the best code is often the code you never end up writing, and that the best feature is often the one you decide not to build. The constraint that the old hardware used to impose on us has gone, and nothing out there is going to reach in and put it back for us. So if we want it, we have to supply it ourselves, on purpose, out of judgment rather than out of necessity.

And here is the part that I think matters most for anyone running a business and looking at that invoice at the end of the month. Almost none of the real cost of AI is anywhere on that page. It is out in the grids and the water and the ground and the waste, and a great deal of it is being paid by people you will never meet. But a surprising amount of it is still shaped by choices that are entirely yours to make, in how you build, in what you ask for, and in what you decide is actually enough. That is not a reason to feel bad about any of it. It is one of the few genuine levers you still have your hands on, and I think it is worth holding onto.

If you have read this far and you are sitting with some of the same surprise I felt when I first went through all of this, at how large the footprint really is, and at how much responsibility sits with both the companies behind these tools and those of us who use them every day in our work, then I would gently encourage you to go and read the report yourself. You can work through the full thing if you have the patience for it, or you can get the essential points from the executive summary, which is a good deal shorter and still leaves you holding the real shape of the problem. Either way, I think it is worth letting it change, even a little, the way that single line on your next invoice looks to you.

Here’s a link to the report: https://unu.edu/inweh/collection/environmental-cost-of-AIs-Enrgy-Use-Carbon-water-and-land-footprints