The common claim around Muse is simple: give every user 2 vCPUs and 8GB of memory, and CPU demand explodes. A new estimate from Robonomics argues that this framing misses the real constraint. In its base case, supporting 100 million daily active users would require roughly 1 GW to 2 GW of average total power, and only about 0.1 GW of that would come from the CPU/VM sandbox layer. If daily inference-equivalent model calls per user run higher, total demand in the 3 GW to 4 GW range is described as entirely plausible.
The paper’s central point is that the bottleneck sits in inference, not CPU. For investors tracking AI infrastructure and power demand, the estimate lays out a more detailed breakdown of what Muse could require in compute, memory, and electricity.
Muse sandbox infrastructure starts with concurrency, not headline DAU
The estimate begins with Muse VM and sandbox infrastructure. Based on the observed setup, each user is assigned 2 vCPUs, about 8GB of memory, and about 100GB of persistent logical storage.
The first mistake, the author says, is to assume that 100 million daily active users means 100 million VMs consuming compute at the same time. The base assumption is that the agent tied to each daily active user is actively working for two hours per day on average. That yields about 8 million concurrently active VMs, calculated as 100 million users multiplied by two hours and divided by 24 hours.
Meta, however, would not provision only for the daily average. Usage clusters during waking hours and comes with bursts. Using a peak-to-average ratio of 2.5x, the estimate raises the figure from 8 million to about 20 million peak active VMs. Adding roughly 20% spare capacity brings the standing online fleet to about 25 million VMs. In other words, the base case assumes infrastructure sized for around 25% of daily active users to be online at once.
CPU demand depends on oversubscription
The next distinction is between virtual CPU allocation and physical CPU demand. Agent sandboxes are presented as a good fit for CPU oversubscription because they spend large stretches waiting. A VM may remain alive during those periods while using very little CPU.
As a benchmark, the estimate points to DeepSeek’s recently released DSec infrastructure. According to the piece, the production-grade agent sandbox platform runs on about 160 nodes with roughly 30,000 physical CPU cores and 250 TB of DRAM, while handling peak concurrency above 380,000 sandboxes. DSec also showed stable operation at about 800 micro-VMs per node. Using about 188 physical cores per node, that works out to roughly 0.23 physical cores per live VM.
The author describes DeepSeek as exceptionally efficient and suggests Muse could land in a range of 0.3 to 0.75 physical cores per live VM. The base case uses 0.5 physical cores per live VM, which is equivalent to one physical core supporting about two simultaneously live Muse VMs.
Applied to the 25 million live VMs in the base case, that implies demand for about 12.5 million physical CPU cores. On 256-core CPUs, that comes to around 50,000 chips. On 192-core CPUs, the figure rises to about 65,000. Based on current public pricing, the estimate puts CPU procurement cost at about $800 million.
Memory demand is large, but still not the main power draw
On memory, the paper says Muse exposes about 8GB to the user environment, but one observed instance used only about 3GB at the time it was measured.
Multiplying 25 million live VMs by 3GB gives about 75 PB of physical DRAM. The estimate treats 75 PB to 100 PB as a reasonable base range. At current public prices, that translates to about $2 billion in DRAM cost.
For power, the conclusion is much smaller than many headline assumptions suggest. At the scale of 100 million daily active users, the entire Muse sandbox or VM layer would require about 0.1 GW.
Inference is where the power bill rises
The estimate says model inference is handled by Meta’s external inference infrastructure. Under Meta’s description of the Muse architecture, the personal computer runs tools locally and stores state, while the actual model runs on separate inference infrastructure.
For energy per inference event, the paper cites a 2026 Microsoft study that estimated a median energy cost of about 0.31 Wh for an optimized frontier-scale ordinary query. A long-reasoning query, however, uses about 15 times as many tokens as a standard query and consumes about 13 times as much energy, or roughly 4 Wh per long-reasoning query.
The estimate adds that the study specifically noted much higher energy use for inference and agent workloads. For Muse-like workloads, it assumes a rough sensitivity band of 5 Wh to 10 Wh per heavy inference-equivalent event.
At 50 inference-equivalent events per user per day, inference alone reaches about 1 GW
In its sensitivity analysis, the paper assumes each daily active user generates 50 inference-equivalent events per day. That is framed as a workload comparable to 50 heavy inference events for each active Muse user every day.
At 5 Wh per event, the math comes to 100 million users multiplied by 50 events per day multiplied by 5 Wh, or 25 million kWh per day. Dividing by 24 hours gives about 1.0 GW of average power.
On that basis, inference alone could require about 1 GW to 2 GW of average power. The paper then argues that a 3 GW to 4 GW Muse deployment is entirely reasonable. It also says this may be why Meta has been rumored to add 7 GW to 10 GW of compute capacity next year.
Conclusion centers on inference, not raw CPU counts
The closing argument is that the popular shortcut of multiplying 2 vCPUs and 8GB by the full user base materially overstates CPU demand because it treats logical VM allocation as if it were dedicated physical infrastructure.
The more interesting takeaway, according to the estimate, is that consumer agents could become a meaningful new source of demand for CPUs and traditional DRAM, while inference remains the real compute bottleneck. As agents take on more work, run longer trajectories, and increasingly spawn other agents, inference demand could grow faster than user counts themselves.
