What is Koomey's law?
The computations you get per joule double at regular intervals: every 1.6 years until 2000, every 2.6 after.
Koomey's law is the empirical observation that the number of computations you get from one joule of energy doubles at regular intervals. In the work that gave it its name, Jonathan Koomey and his coauthors reconstructed the electrical efficiency of computing machines starting from ENIAC and found a doubling roughly every year and a half, holding steady across wildly different technologies, from vacuum tubes to microprocessors. It is a law about energy, not speed: it measures how much work you get per unit of electricity consumed, the quantity that shows up on the power bill and in the sustainability report, rather than how many transistors fit on a chip, which is Moore's law territory. After 2000 the pace slowed, and the slowdown is documented. For decision makers the curve itself is not the point: the point is that efficiency per computation improves while the absolute energy use of computing rises, with no contradiction between the two.
The number, and why it slowed
The baseline figure comes from the 2011 paper by Koomey, Stephen Berard, Marla Sanchez and Henry Wong in IEEE Annals of the History of Computing, Implications of Historical Trends in the Electrical Efficiency of Computing: computations per kilowatt-hour double every 1.57 years across the whole historical series, from 1946 onward. That average already contains the post-2000 slowdown; peak efficiency ran faster. The slowdown is stated by the same authors, and it is the figure to cite today: in a 2016 article in Electronic Design, Koomey and Sam Naffziger write that peak output efficiency doubled about every 1.6 years from the dawn of the computer age, and that by the turn of the millennium growth had slowed to a doubling every 2.6 years or so, held back by the physics of CMOS circuit scaling: the voltage reductions that kept power use down while clock rates climbed came to an end. The gains continue, but they are slower and they come from specialized hardware rather than from general scaling.
An enterprise example
A company replaces a five-year-old server fleet with machines that do the same work on half the power, and budgets for a lower electricity bill. Twelve months later the bill is flat or higher. Nothing was measured wrong: the new machines freed up capacity, and free capacity fills. Reporting jobs that ran once a day because they cost too much now run hourly, the data team adds the test environments it used to be refused, and somebody switches on an inference workload that was unthinkable before. Efficiency per computation improved exactly as promised, and precisely for that reason the number of computations grew by more.
Why it matters for decision makers
That example is the Jevons paradox applied to the energy of computing, which is why Koomey's law is a constraint rather than a strategy. More efficient hardware lowers the cost of a unit of compute, and compute that costs less gets asked for more: the total does not fall on its own. Three practical consequences follow. A cost or emissions reduction plan resting only on a hardware refresh has no lever: the variable that governs the total is demand. The rate at which efficiency improves is no longer the 1990s rate, so deferring energy savings to next-generation hardware bets on a curve that has slowed. And the lever genuinely left in your hands is which workload you run, with which model and how often: choose a small model where a small model is enough, switch off what nobody uses, put an explicit threshold on volumes. Efficiency is something you buy, demand is something you govern.
Related terms
- Moore's law · The observation that transistors per chip double at regular intervals: for decades it made computing cheaper on its own.
- Jevons paradox · Making a resource more efficient often raises its total consumption, not lowers it, because you end up using more of it.
- Green IT and Digital Sustainability · The practices for reducing the energy footprint of IT infrastructure and AI workloads, now also a CSRD reporting obligation.
- FinOps · The practice bringing financial accountability to the cloud: every team sees, understands and optimizes the cost of what it runs.
- SLM · A small, specialized language model: a fraction of an LLM's cost, runs even on-premise, and for focused tasks it is plenty.
A term that hits close to home? Let's talk.
CONTACT ME