What it costs Meta to give every user free agentic AI: GPU inference for tokens, plus CPU microVMs for running agents. Then how much extra revenue per user Meta needs to break even, or to keep today's profit margin.
Extra revenue per user per year that Muse has to bring in, through ads, commerce and messaging, to pay for giving it away.
Price one user's tokens and multiply up, or size the whole GPU fleet and multiply by its hourly cost. The two methods are the same equation rearranged, so they must match.
GPU inference for tokens against CPU microVMs for running agents, per year.
Memory and storage the fleet would hold. 1 EB (exabyte) = 1,000 PB = 1 million TB.
Priced per token from SemiAnalysis's B200 results.
One Firecracker microVM per active session.
Each server packs VMs until the first limit is hit. Agents mostly wait on the model, so VMs are given more vCPUs and RAM than the server physically has, relying on low average use.
Muse cost next to what Meta earns from each daily user today.
Every number above, with your inputs plugged in. N = daily users, T = tokens per user per day, E = tokens per $1, U = utilization.
| Quantity | Formula | With your inputs | Result |
|---|
Oversubscription means promising VMs more CPU and memory than the server physically has. It works because agent sandboxes spend most of their life idle, waiting for the model to reply.
With the current inputs, each server gives out – vCPUs per physical core and – GB of guest RAM per GB of real RAM. On average only – of CPU and – of RAM is actually in use.
| CPU | RAM | |
|---|---|---|
| What happens when demand exceeds the server | VMs take turns on the cores and everything slows down. Nothing breaks. | The host runs out of memory and the kernel kills processes or whole VMs. Failure is abrupt. |
| Typical safe ratio | 5–15 : 1 for agent workloads | 1.2–2 : 1 |
| Why agents allow it | About 90% of DSec sandboxes average 5% or less of the CPU they request (Fig. 5). | A Firecracker VM only takes host memory for pages it actually touches. DSec microVMs typically use a small fraction of the RAM they request (Fig. 5). |
| How DSec keeps it safe | Latency-sensitive VMs get priority; background VMs run under SCHED_IDLE, and core scheduling keeps them off the same physical core. Latency rise at 50% load fell from 45% to 17% (§5.2, §8.5). | A shared page cache (virtio-pmem with DAX) cut peak host memory 40%. Returning cold pages to the host (DAMON with balloon free-page reporting) cut memory over time 21%. Idle VMs are snapshotted to disk and their RAM freed (§5.2, §6.3, §8.4). |
| Guardrail | Keep average CPU busy near 50% so spikes (up to ~1.4 cores in DSec Fig. 3) have room. | Keep real RAM use below ~80% and reject new VMs on a full node, as DSec's per-node admission check does (§3.3). |
A server takes VMs until the first of five limits is hit: real CPU use, real RAM use, the vCPU cap, the RAM cap, or local disk. The two oversubscription inputs are safety caps. With the defaults, real RAM use binds first, so RAM ends up oversubscribed about 1.7 : 1 and CPU about 6.7 : 1, below both caps.
To see the cost of playing it safe, set Max RAM oversubscription to 1. Each server then holds only 750 VMs, the fleet grows to about 125K servers, and sandbox cost rises from about $4.9B to about $8.3B a year. Because GPUs dominate, total Muse cost moves only about 2%.