Most AI runs flat out around the clock whether anyone needs it or not. We do not build it that way. This is the longer version of something I believe: that AI can be genuinely useful and still be built with some restraint about the power it burns. It is not a marketing angle. It is how I work.
The researchers call this "green-in AI". It is about the machinery: using smaller models where a smaller model will do, running things only when they are needed, and not leaving expensive hardware idling. This is our territory, and it is the part most people skip because it is unglamorous.
"Green-by AI" is the other half: AI applied to climate modelling, smart grids, emissions forecasting. Important work, but more academic and further from what a small business needs day to day. We mention it so the picture is honest, then we get back to the first half.
Training a single large language model from scratch can produce as much carbon as several cars over their entire lifetime. That figure comes from Emma Strubell's 2019 work at Carnegie Mellon, the paper that first put hard numbers on this, and it is the reason the conversation exists at all.
Then there is water, which almost nobody talks about. Data centres are cooled with it, and researchers like Shaolei Ren at UC Riverside have shown that a single long AI conversation can quietly consume a few hundred millilitres of fresh water. Multiply that across a planet that has started asking AI everything, all day, and it adds up faster than the public conversation has caught up with.
None of this is an argument against using AI. I use it constantly and I build with it for a living. It is an argument for using it deliberately rather than leaving everything running at full tilt by default, which is what most setups do simply because nobody thought to do otherwise.
The simple version: the machine switches on when there is work to do, and switches off when there is not, instead of running around the clock for the few minutes a day it is actually used. Less power, a smaller bill, no waste.
The lazy instinct is to send every task to the biggest, most expensive model going. Most tasks do not need it. We match the size of the model to the size of the job, often using a capable model for the hard part and a smaller or local one for the rest. It is cheaper to run, faster, and far lighter on power, with no real loss in quality where it counts.
Every word you send an AI costs energy. Stuffing a giant pile of context into every request, just in case, is wasteful and usually makes the answers worse, not better. We are careful about what the system reads and remembers, so it works on what matters rather than wading through everything every time.
The next best thing is one that only wakes up when there is something worth doing. That single idea sits behind a lot of how I build. A server running at full power overnight to answer three messages is not impressive engineering, it is just waste with a login screen.
I have run this in practice, not just in theory. The idea is simple: switch the machine on for the work, switch it off afterwards, and stop paying to keep an empty room lit. Less electricity, a smaller bill, and a clearer conscience, all from the same decision.
I am not the first person to care about this, and I would not pretend to be. If you want to read past my opinion, these are the names worth knowing. It is a young field, which is part of why it interests me.
Wrote the 2019 paper that first quantified the carbon cost of training AI models. The starting point for the whole conversation.
Climate lead at Hugging Face, behind CodeCarbon and the push for emissions labels on AI models. Talks about "frugal AI" in plain, practical language.
Coined the Green AI versus Red AI framing: efficiency as a first-class goal, not an afterthought to raw accuracy.
The researcher putting numbers on AI's water footprint, an angle most of the industry still overlooks entirely.
A Linux Foundation body publishing the Software Carbon Intensity standard, the emerging way to actually measure software emissions.
The leading nonprofit in the space, with an open library of accessible explainers if you want to go deeper than this page.
Almost all of the research in this field is aimed at the giants, the hyperscalers running enormous data centres. There is very little written for a small business or a small team, which is exactly the gap I care about. The good news is that the efficient way to build is usually also the cheaper way to build. Wake-on-demand compute and right-sized models do not just lower the carbon, they lower your bill.
So this is simply how we prefer to build, not a rule we put on you. The job always comes first. If your work genuinely needs a system running around the clock, that is exactly what we will set up. We just start from the efficient option rather than the wasteful one, because someone has to think about what each part actually costs to run. More often than not, the efficient choice and the right business choice turn out to be the same thing.