Why Agents Need So Many CPUs
One agent’s daily workload, multiplied by millions.
You ask your agent to catch you up on your inbox, find flights for a trip and check the prices again tomorrow. It needs to open things, run programs and keep track of what it finds. Meta gives each Muse user’s agent a computer in the cloud for that work.1 Let’s look inside, then ask what happens when millions of people put theirs to work every day.
Your agent needs tools.
A browser to search the web, code to compare results, files to save them, and connections to email and calendar. These let the agent act on your request.
CPU executes · RAM holds live state
Storage retains files
Your day starts with a briefing.
You ask your agent to summarize your inbox and tell you what needs attention before your first meeting. Its control software starts the job inside your virtual machine. Physical servers supply the CPU execution, memory and storage that make this computer work.
The software keeps track of the request, the tools it can use and the results so far. When it needs the model to choose a next action, it sends that context over the network to a separate service running on GPUs.
The GPU generates the next action.
The model reads your request and might produce an instruction to fetch recent messages or check today’s calendar. Generating that response is inference. GPUs perform the numerical calculations; the workspace carries out the resulting tool instruction.
Beside the GPU, high-bandwidth memory (HBM) holds the model’s weights and cached context. The service can process requests from many agents together. Larger models need more weight memory. Longer contexts increase cached state, while generating more tokens adds computation and keeps the request active longer.
The CPU gathers what the model needs.
Your agent’s software calls the authorized email and calendar connections, processes their responses and prepares the results for the model. The model uses that information to write your briefing. CPU execution and GPU inference alternate as the job progresses.
Your VM exposes virtual CPUs to these programs. The host schedules their instructions on physical cores, sharing execution capacity across workspaces. CPU cost depends on the execution time the programs consume. More demanding tools, or more tool calls per job, increase that work.
A travel search takes another round of work.
Later, you ask the agent to compare flights. This time it opens a browser, reads travel sites and runs code to compare prices. The results go back to the model, which can request another search or tell the software to save a shortlist. A single job can involve many rounds of inference and tool execution.
Each round adds CPU work and network traffic. Including more observations in the next prompt can also increase inference cost. Permissions govern the actions: Muse’s Sentinel service checks connector actions and outgoing requests around this loop.1
The browser waits. Its state stays in memory.
While a travel site responds, the browser can yield the CPU. Its open pages and price table stay in system RAM, ready for the next step. This is separate from HBM at the model service.
This distinction matters when you count the work. A six-minute job might spend much of that time waiting rather than executing instructions. Waiting frees CPU capacity for other programs, while the browser’s live state can continue occupying memory.
The agent picks up where it left off.
The agent saves the shortlist as trips.csv and records your request to check prices again. Durable storage keeps that state after the research job ends. The next morning’s scheduled job loads the file and starts another round of model calls and tool use, without a new message from you.
A suspended workspace can release its working RAM while retaining saved files. Keeping it warm instead uses memory between jobs. The hosting system trades faster resumption against the cost of retaining those live processes.
Your day overlaps with everyone else’s.
Your price check runs alongside other people’s briefings, calendar updates and research. Each workspace has its own state, while shared servers supply CPU execution and model inference.
More simultaneous tool work needs more CPU capacity; more resident workspaces need more RAM. Files occupy storage even when agents are idle. CPU demand depends on how much work each agent performs and how many agents perform it at the same time.
Now multiply that day by millions.
A briefing, a travel comparison and a later price check are three separate jobs. Add document updates, inbox checks and other delegated tasks, and one person has a daily workload. Across millions of people, those jobs become a large amount of software to run.
The estimate below starts with jobs per person per day and a resource budget for each job. It shows how allocated workspace capacity and cost grow with use. Physical CPU requirements also depend on how much of each job is spent executing, how busy periods overlap and how efficiently the servers run the software.
What does a personal computer for everyone cost?
Use Muse’s reported 2.8 million global downloads as a starting population. Then imagine 10 million or 100 million people delegating work. How much infrastructure would serving them require?
The estimates below give every person an agent workspace and the same daily workload.
Live browser pages, running programs and intermediate results. Charged while the workspace is running.
Saved files and agent state. Retained and charged between jobs, even when the workspace is stopped.
Execution capacity for the workspace. An assumed allocation for this model, not a disclosed Muse CPU specification.
The 8 GB memory and storage figures are reported resource budgets used as assumptions here. Reviewed Meta documentation does not establish those capacities.
Give each person work to delegate.
Illustrative public-price equivalent · USD · 30-day month
2.8 million people
At the reported download scale
- CPU + RAM + storage
- Model inference
- Workspace-hours / day
- Average allocated vCPUs
- Average allocated RAM
- Saved storage
10 million people
Future adoption scenario
- CPU + RAM + storage
- Model inference
- Workspace-hours / day
- Average allocated vCPUs
- Average allocated RAM
- Saved storage
100 million people
Future adoption scenario
- CPU + RAM + storage
- Model inference
- Workspace-hours / day
- Average allocated vCPUs
- Average allocated RAM
- Saved storage
The CPU story is time spent running software.
More jobs mean more workspace-hours. Longer or more demanding jobs increase the execution needed for each person. At large populations, even modest daily use becomes a substantial fleet workload.
Tokens measure the model side of that workload. They help estimate inference spending, but a larger token bill does not tell us how many CPUs an agent needs. For that, we need the execution cost of its tools. Converting this model’s allocated capacity into a physical server estimate requires measurements of representative personal-agent jobs.
CPU suppliers such as NVIDIA, AMD and Intel, cloud providers, and memory and storage companies are exposed to this growth. The opportunity comes from how much work people delegate, balanced against how efficiently the infrastructure can perform it.
Sources, evidence & how to read the figures
The hardware, resource occupancy, task timing and population are schematic. Vera and Rubin illustrate CPU and GPU roles; this is not a disclosed Muse hardware deployment. Per-user CPU, RAM and storage capacities have not been established from the reviewed official documentation. Product-specific unknowns are retained in the research record and claim ledger.
- Meta: Introducing Muse and How We Built Safety Into Muse, September 8, 2026. Personal VM, execution environment, state and external inference. Official vCPU/RAM/disk limits, physical allocation, utilization, and idle lifecycle were not established in the reviewed sources.
- Anthropic: Scaling Managed Agents. Separates durable session state, agent control, and execution. Implementations need not share Muse's VM topology.
- NVIDIA Vera CPU, Vera Rubin NVL72, and Vera delivery. Hardware roles and reference architecture. The illustration simplifies packaging, memory and networking; it does not assign a whole chip to each VM. Vera also serves in standalone CPU systems.
- NVIDIA–Meta infrastructure announcement, February 17, 2026. Establishes a company-level relationship, not a disclosed Muse-on-Vera/Rubin deployment.
- AWS tenancy documentation and Google Cloud lifecycle documentation. Physical tenancy, persistence and execution are different properties.
- Microsoft FY26 Q4 earnings transcript. Management's discussion of CPU importance for agents. Directional evidence, not a universal CPU/GPU demand ratio.
- DeepInfra: We Benchmarked NVIDIA Vera, July 21, 2026. Operator-reported controlled replay, fixed injected CPU work, identical 20-core partitions and secure microVM hosting. No live LLM generation in the comparison; workload-specific capacity, not a Muse sizing rule.
- AgentCgroup: Understanding and Controlling OS Resources of AI Agents. Coding-agent resource characterization on an Intel Core Ultra 9 285K system with 128 GB DDR5. Concurrency findings are specific to that experimental workload and platform.
Further study: Compute and Agent Infrastructure
This essay builds on MTS's Compute physical-stack explanation and Agent Infrastructure's harness, environment and measurement research. CPU time measures execution consumed; elapsed time measures how long a task takes. VM allocation and physical fleet capacity describe different levels of the system.