I listened to a podcast this week in which a startup called Emerald AI claimed a revolutionary innovation that allows data centers to throttle energy demand. As I listened to the pod, though, I had a nagging feeling I'd heard this story before. I had, of course. In September 2009 I wrote a short post about what was called "follow the moon" architecture.
The follow-the-moon idea came from researchers at MIT and Carnegie Mellon, who predicted that cloud providers with data centers around the world could route traffic to regions with lower electricity demand and therefore lower costs. Night typically means cooler air and cheaper, off-peak electricity, and the researchers estimated that a strategy like this could cut energy costs by as much as 40%. My question at the time was whether our applications were ready to take advantage of it. Nearly two decades later, we seem not to have advanced very far at all.
A supply-side fix
The October 8, 2026 episode of "This Week in AI" featured Dr. Varun Sivaram, founder of Emerald AI, who described technology that lets a data center throttle its energy use when demand on the grid is high. This approach is a timely response to a high-visibility problem. Data center development is under intense scrutiny right now. When data centers are seen as adding to power grid stress, a solution that can ease demand at the right moments can allow an existing grid to support a data center without a great deal of additional infrastructure build. The throttling happens between the data center and the grid operator, and the customers whose workloads run there rarely see it.
As attractive as this solution seems, I do feel it's a superficial tweak on the margin, and its greatest appeal may be allowing data centers to claim a lower impact on grids and (perhaps) even skip the line versus data centers that don't offer this sort of flexibility.
As I listened to the pod, I couldn't help wondering why consumers of data center-based compute wouldn't be able to steer demand themselves, shifting meaningful amounts of energy usage to low-utilization or low-cost locations.
The missing price signal
What the conversation didn't mention was any way for customers to participate in demand-steering. The 2009 idea assumed someone could see where power was cheap or scarce and move work accordingly. A cloud provider can do that internally, but as far as I can tell, no provider gives customers a price signal that reflects the cost or availability of power in a region. Without one, a customer has no way to steer traffic away from a strained region and no reason to try.
A provider that throttles a facility to relieve the grid is making that decision on behalf of its customers. A price signal would let the customers make the decision themselves, and share in the savings when they do.
Cloud customers already have some control over price. Virtual machines on shared hardware cost less than dedicated hosts because the provider spreads the hardware across many customers. Customers can also choose the regions their workloads run in, but they usually do so to get multi-region backup or to sit closer to their users, not to follow cheaper power.
The solution we'd really need here consists of two parts. First, dynamic pricing would guide usage away from data centers experiencing peak-demand power consumption and toward off-peak locations. Prices could follow a regular schedule based on historic consumption, or they could be fully dynamic, changing minute to minute. The second is the ability to steer a unit of work to a cloud region dynamically in order to take advantage of lower rates.
Latency hasn't changed
In the 2009 post I did some napkin math. The earth is about 25,000 miles around, so even at the speed of light, a data center on the opposite side of the planet is roughly 135 ms away round trip. When I pinged two Australian sites, I got 233 ms and 248 ms, which shows what the routers in between add. The floor is set by physics, so I don't expect today's numbers to look much different.
Follow-the-moon also works against two decades of web performance work. We put static content on CDNs to keep it close to the user. Follow-the-moon asks us to run dynamic processing in whichever region is off-peak, which is often the one farthest from the user. A chatty application, such as a modern UI that fires many small requests as the page updates, is a non-starter for this type of work-steering.
Large units of work for region flexibility
Applications that partition large units of work are ideal for this architecture. Create a self-sufficient unit of work, hand it off and let it run, and connect the pieces with messaging. A message doesn't care that the round trip takes an extra quarter of a second, as long as you know when the work is done. Examples of this sort of work include batch jobs, model training, and analytics: work nobody is waiting on.
Another obvious candidate: since many AI requests take seconds to complete, an extra 150 to 250 ms of network delay is a small share of the total. That makes some AI inference a better candidate for dynamic-region computing than the web applications I was thinking about back in 2009. Training jobs that checkpoint their progress are better candidates still, since they can pause in one region and resume in another.
Space-based data centers
Space-based data centers are born of the same economics. Power availability is the main selling point for launching them, and they're likely to experience some of the same latency issues as a workload looking for off-peak terrestrial power. The workloads that fit orbiting data centers are the same ones: batch and asynchronous work, not low-latency interactive traffic.
Still hard, but solvable
The state of the art today is that supply-side tools are getting better. Techniques like those from Emerald AI can be considered a first step. The two problems I raised in 2009 are still open. Providers haven't given customers a way to see and respond to the price of power, and latency still limits which workloads can move. Until there is a price signal and applications are built to tolerate the delay, the cost savings promised by follow-the-moon architecture will continue to elude us.