Why Stockholm, Not Arizona: Where AI Waste Heat Has a Buyer

Lake Mead seen from Hoover Dam, with a water intake tower on the Nevada side at left: a white mineral bathtub ring runs along the canyon walls above the waterline, marking the level the reservoir used to stand at

A bathtub ring: mineral left on rock the water used to cover. Lake Mead from Hoover Dam in 2005. The band has grown a great deal since. USGS, public domain.

On August 8, 2026, Lake Mead, the Colorado River's largest reservoir, sat near its lowest level since it was filled some ninety years ago (AP). The same week, developers were still racing to build data centres across the Arizona desert it waters. Some cool by evaporating the one thing that stretch of country has least of.

A strange place to generate heat you plan to throw away. So when AI's electricity turns to heat, where should the heat go? Two sites answer in opposite ways, and it comes down to water.

The Choice Comes Down to Water

A hot, dry site looks ideal for cooling, because dry air makes evaporative cooling cheap. It pays when the gap between the two thermometers below is 15–20 °F (8–11 °C) or more (MEP Academy).

Dry-bulb and wet-bulb thermometers side by side; the wicked wet-bulb thermometer reads lower because evaporating water pulls its latent heat off the wick, and the gap is called the wet-bulb depression

Image source: The Engineering ToolBox.

The bare thermometer shows the air temperature (the dry-bulb). The wet one reads lower, because evaporating water takes heat away. That is the wet-bulb, the coldest an evaporative cooler can reach. Hot, dry air widens that gap, helping evaporative cooling, but the process consumes water.

Arizona: The Water-Hungry Case

Hot, dry air makes evaporative cooling work well, but it is a choice. Dry air coolers use no water and cost more in equipment and fan power. Onsite power with an absorption chiller does not change that, since the chiller still rejects heat, usually through a cooling tower (US Department of Energy). The EPA's 2007 cost figures price whole packages at old energy prices (EPA CHP Partnership), so we skip cost.

Instead we use one simple what-if. Take a 10 MW IT pod that gives off 87.6 GWh of heat a year, and assume a hot, dry site rejects all of it by evaporation. At about 1.5 litres per kWh, that is roughly 130 million litres of water a year.

We deliberately assume all heat is rejected by evaporation. Actual projects can choose other cooling systems. Tucson declined the original Project Blue proposal in August 2025 (Grist). The developer moved ahead outside the city with closed-loop air cooling that it says uses no water for industrial cooling (AZPM).

Stockholm: A Heat Pump and a Buyer

Stockholm gives the same heat a second path. The pod can dump heat through dry cooling, or lift part of it to a temperature that Stockholm Exergi, the city's heat network, will buy. The operator sells what the network takes and rejects the rest.

Two things help. Sweden's grid is 99% low-carbon in 2025 (hydro, wind and nuclear, with fossil fuels at 1.2%) (Ember; World Nuclear Association), so the heat pump runs on nearly clean power. And Open District Heating pays for heat instead of charging to dump it.

The question is narrow. For one 10 MW pod in Stockholm, how much heat reaches a real buyer, and how much is thrown away? This post models the physics, not the cost or payback.

What the Network Will Buy

Open District Heating buys heat at three grades. Retur goes into the return line and pays least. Inblandning is blended into the network at a fixed 74 °C. Prima matches the network's own supply temperature, which rises in cold weather, and pays most.

The delivery-temperature ladder: Retur, Inblandning and Prima's required delivery temperature plotted against ambient, with the loop's constant 47°C return marked; its crossings with the Retur curve bound the free-delivery window

Prima runs from 68 to 103 °C over a year. Inblandning is 68–80 °C, and we take the middle, 74 °C. Retur must be at least 3 K above the incoming return (Öppen Fjärrvärme product sheet). The network curves come from Energiforsk 2024:1059, an average over 213 Swedish systems, not a Stockholm measurement.

How much heat the network takes is our own assumption, and it matters most: a 2 MW summer base, plus 900 kW per kelvin of space heating below 17 °C, capped at 20 MW.

The chosen network demand curve against ambient temperature: capped at 20 MW below -3°C, falling to a 2 MW summer base above 17°C, and crossing the 8 MW of liquid-path heat a 10 MW pod produces at about 10°C, above which the network wants less than the pod produces

Above about 10 °C, the network wants less heat than the pod's liquid loop carries, and the rest is dumped. Change the base or the slope and that crossing moves, so every result below depends on numbers we chose.

How Much Heat Is Coming?

We use a stress test to see how much heat a large deployment of AI agents could produce.

Anthropic's CEO says AI could take half of all entry-level white-collar jobs within five years (Axios). The ILO is more careful: about a quarter of jobs exposed, with change likelier than replacement (ILO). We run the extreme case. Take the world's ~724 million manager, professional and technical jobs (ILO), and give each one an AI agent running every hour of the year.

Power per agent is our weakest number. Google reports about 0.24 Wh for a median Gemini text prompt (Google), but a prompt is not a constant load. We assume a 700 W GPU at a PUE of 1.2, shared by 10 to 100 agents: 8.4 to 84 W each, for 8,760 hours.

The chain from 3.6 billion workers to 724 million white-collar jobs, times 8.4 to 84 watts per always-on agent, times 8,760 hours, giving 53 to 533 TWh a year, or 13% to 128% of the 415 TWh every data centre on Earth used in 2024

That gives 53 to 533 TWh a year. The low end is an eighth of what all data centres on Earth used in 2024 (about 415 TWh). The high end is more than all of them together. This corresponds to 608 to 6,080 pods of 10 MW, all releasing their electricity consumption as heat. To examine where that heat can go, we model one pod.

Inside One Pod

We modelled the pod in Modelica and exported it as one FMU. It runs as a study here, reading a year of Stockholm weather. Later, the same FMU runs as the plant itself, taking commands from an orchestrator.

A closed loop carries the liquid-cooled 80% of the pod's heat:

The pump keeps a constant 5 K rise across the rack, so flow is a constant 383 kg/s, carrying the loop's 8 MW share of the 10 MW pod. Supply and return stay at 42.00 °C and 47.00 °C, to the digit, for all 8,760 hours.

The same loop as the actual Modelica thermal circuit: the circulator, the rack- and cooling-side loop pipes, the heat-flow blocks that inject the IT load and tap off the sale and rejection duties, and the accumulator tank with its standing loss to ambient

The same loop in the model itself, exported from OpenModelica (OMEdit).

The heat pump and delivery path are equations, linked to the loop through heat-flow blocks:

tapHeat.Q_flow = -qTap;   // evaporator duty, drawn off the cooling pipe
prodHeat.Q_flow = qProd;  // condenser duty, delivered to the tank node
delHeat.Q_flow = -qDel;   // delivery, drawn out of the tank node

The first two lines are the two ends of the heat pump: heat in at the cold end (evaporator), heat out hotter at the hot end (condenser). The difference is compressor work. The heat-pump equations connect to the thermal circuit through these heat-flow blocks.

The standalone top-level model: the Stockholm weather table, the constant IT load, the product selector and the network supply and return curves, all feeding the data-centre pod

The same pod wired to its drivers, on the left, that step it over the weather year.

Throwing the Rest Away

Heat the network does not take goes to the air. Below 39 °C ambient, the dry cooler holds the set point on fan power alone. Past that, a mechanical stage takes the overflow at a much worse efficiency:

freeCool = tAmbK + dTApproachNominal < tPlaSupNominal;     // ambient cool enough to skip mechanical lift
qRejFreeCap = if freeCool then yDry*qDryCapNominal else 0; // fan capacity on offer, throttled by fan duty
qRejFree = min(qRej, qRejFreeCap);                         // what the fans actually move
qRejMech = qRej - qRejFree;                                // whatever spills past them
pDry = qRejFree/copCoolFree + qRejMech/copCoolMech;        // electricity, one term per stage

In Stockholm the mechanical stage never turns on. The warmest hour is 30 °C, so every hour runs on fans alone (COP 15).

The Year, End to End

We run the Stockholm Arlanda TMYx year (8,760 hourly rows, −18.0 °C to 30.0 °C) once per product, with every set point at its default.

Product	Heat sold	of IT energy	IT heat recovered	Heat-pump work	Demand-limited
Retur	56,517 MWh	64.5%	61.5%	2,651 MWh	31.1% of hours
Inblandning	57,768 MWh	65.9%	55.7%	8,986 MWh	34.9% of hours
Prima	57,768 MWh	65.9%	54.6%	9,918 MWh	34.9% of hours

Heat sold includes the compressor work the heat pump added. IT heat recovered is only what came off the IT loop. For Inblandning, the network buys 57,768 MWh, of which 8,986 MWh is compressor electricity. So 48,782 MWh (55.7%) came from the IT loop.

Retur needs no heat-pump work for 38.5% of the year because the 47 °C loop is already hot enough. The two premium products sell the same amount of heat, capped by the 8 MW condenser. Prima lifts higher, so more of that 8 MW is compressor work.

With every set point at its default, the storage tank just cools from 47 °C to 15.3 °C. We have not applied a dispatch strategy in these runs.

Heat sold vs. heat dumped by month for Inblandning: supply is flat all year, demand isn't, and the mismatch is worst in summer

The mismatch is worst in summer, when the pod has the most to sell. Let the network take everything and delivery reaches 80.0% of IT energy, the 8 MW condenser limit. The gap from 65.9% is fourteen points, all from hours above about 10 °C, when the network wants less than the pod produces.

What the Desert Would Have Evaporated

The pod modelled here evaporates nothing. The comparison asks what the same pod would use at a hot, dry site that evaporated all its heat, at about 1.5 L per kWh:

Three columns: a hot, dry site that cools by evaporating water uses roughly 130 million litres a year; Stockholm uses 0 litres on site because fans cool the pod all year; that 130 million litres splits into about 73 million litres a year for heat sold to the network and about 58 million litres a year for heat the fans reject

The 130 million litres comes from the cooling choice. Stockholm uses no onsite water because its rejection is dry, even if it sold no heat. For Inblandning, 48,782 MWh of IT heat goes to the network. That is about 73 million litres of the all-evaporative burden. The other 38,818 MWh is about 58 million litres, avoided because that heat is dry-cooled.

Interpreting the Results

Under the assumed network demand, the Stockholm pod delivers 55.7% of its IT heat as Inblandning over the year. Including compressor work, the heat sold equals 65.9% of IT energy. The model uses no onsite water for cooling. A dry-cooled Arizona build would also use no water for cooling, though it would pay in energy and equipment.

The recovery figure rests on a demand curve we picked. Removing the summer demand limit raises heat delivery by fourteen percentage points, to the condenser limit. Without prices, the model cannot tell us whether summer heat sales would be economical.

One more limit: the 500 m³ tank is one well-mixed node, so only 1,155 kWh of the 15,595 kWh it holds ever cycles. A real tank stratifies. In a later post, we will use Nord Pool's hourly prices to test how dispatch changes these results.

Running It Yourself

The annual results come from one notebook with three FMU runs, one per product. Open stockholm_pod_annual.ipynb in DC2DH/post-1 and run it top to bottom. It prints the annual table from this post.