Jevons' Paradox in 25 Lines of Python

A post called “Jev in 25 Lines of Python” showed up high in Hacker News’ Best feed, with 652 points and 203 comments. It is published on nobodywho.ai. The title does most of the explaining: Jev reads as Jevons, and the implementation is as short as advertised — a couple dozen lines of Python.

An old observation that keeps coming back

In 1865, the economist William Stanley Jevons wrote in The Coal Question that as steam engines improved, Britain burned more coal, not less. Cheaper work per unit made new applications affordable, and the demand those applications created more than covered the fuel that efficiency had saved. Jevons was worried about Britain’s position as an industrial power and its long-term energy supply; the argument itself turned out to be portable. Economists now call the narrow version the rebound effect.

The result runs against intuition, which is why it gets pulled out whenever energy or compute gets sharply cheaper. It also undercuts a comfortable assumption on both the policy and the engineering side: that making something cheaper to use will reduce how much of it gets used. Sometimes the savings do go into lower consumption. Sometimes they go straight into new consumption. Over the past two years the live version of the debate is about inference. The cost of a single model call keeps falling, and falling costs bring in work that used to be too expensive to bother with. Whether the total bill falls along with the unit price is an empirical question, and the people arguing about it are mostly working from examples rather than measurements.

Why a short script counts as an argument

An economic intuition expressed as runnable code is harder to hand-wave than the same intuition expressed in prose. Small implementations have a long history as teaching tools, and they carry a rhetorical charge that full systems do not: nothing is hidden, so there is nowhere to bury an inconvenient assumption. At this size the program can only hold a few parts — a parameter standing in for efficiency, a function that maps unit cost to demand, and a running total. Change one number and the shape of the curve changes on screen.

The real benefit of that compression is where it puts the disagreement. If you think the conclusion is wrong, you can point at a specific line: an elasticity set too high, a step from cost to demand too crude to survive contact with reality. In prose, the objection usually stays at “I don’t think cheaper inference creates that much new demand,” which is not something anyone can settle. Executable models trade coverage for testability, and the trade is visible. Elasticities shift over time, hardware has limits, and there is a long distance between a demo and a product people pay for.

What the comment thread is actually arguing about

652 points means the post was pushed high; 203 comments means readers had something to say. The argument rarely stays on the code. It lands on what the code is being used to support. On one side, cheaper inference unlocks workloads that could not exist before — long contexts, video generation, agents that run for hours. On the other, quantization, smaller models, caching and on-device inference keep pushing the cost per token down. Both sides can find evidence. The part that will decide the outcome has not happened yet.

A script this small works as a diagram. It turns “efficiency increases demand” from a phrase into a handful of lines you can edit, and any reader can change a number and decide whether the result is convincing. Whether the real world follows that shape is a question for the next few years of electricity bills and inference traffic, not for twenty-five lines of Python.