Muse, the personal AI agent Meta recently announced, runs on a cloud computer assigned to each user.
The fact that Meta provides a dedicated virtual machine (VM) was disclosed when the product launched on September 8. What has come into clearer view since then is how code is executed inside that VM, along with the CPU, memory and storage configurations confirmed in real-world environments.
That said, "one computer per person" does not mean a single VM handles all of the AI's processing. Separating the user-specific space from the processing Meta provides as shared infrastructure also makes it easier to understand what the figure "2 vCPUs" actually represents.
Even inside a per-user VM, execution environments serve different roles
According to Meta's technical explanation, Muse assigns each user a Linux virtual machine in the cloud.
The smartphone or web interface connects to this VM through a secure communication channel. Even after the user closes a conversation, the agent can continue working on a set schedule. Files, credentials for connected services and work history are also managed with this per-user environment as the basis.
Meta's product design overview explains that Muse executes commands on its machine and can write its own code and tools as needed. At Meta Connect on September 23, Meta also announced a feature that operates apps on a user's own Mac. However, the user's Mac and the cloud VM assigned to them are separate execution environments.
Muse also cannot freely control the entire VM.
The part that handles code execution and work-file operations is isolated in a systemd-nspawn container within the VM. Even if administrator privileges are obtained inside the container, those privileges do not extend to the whole VM or to Meta's infrastructure.
Meta explains that, even within the same VM, the area where code runs is separated from the area that manages credentials and outbound communication.
The latter includes "Sentinel," which checks external communications and operations on connected services, a service that manages credentials, and a database that stores work history.
For example, even if Muse mistakenly followed a malicious instruction embedded in a web page, the design prevents the work container from directly rewriting the safety mechanisms or the actual credentials.
The key point here is the scope of the phrase "the AI has administrator privileges." Even if Muse holds strong privileges inside its work environment, that does not mean it can control Meta's physical servers themselves.
Rohan Adwankar, who examined an actual Muse environment, confirmed the presence of systemd-nspawn and the virtualization software Cloud Hypervisor in the environment assigned to him.
The structure, with a systemd-nspawn work container and a VM outside it, matches the multilayered isolation Meta describes.
However, this is a result confirmed in a single user environment. It cannot be stated definitively that every Muse environment uses the same virtualization software.
Are 2 vCPUs, about 8GB and 100GB official Muse specifications?
In several Muse environments that were examined, the CPU appears as "2 vCPUs" and memory as about 7.7GiB.
In Adwankar's environment, nproc returned 2, memory was 7.7GiB, and about 100GB of persistent storage was confirmed. Testing by another user also reported a configuration of 2 vCPUs and 7.7GiB.
| Item | What Meta has disclosed | Example confirmed in real environments | Caveat |
|---|---|---|---|
| CPU | Provides a VM for each user | 2 vCPUs | This is a virtual CPU count and does not mean two physical CPU cores are dedicated |
| Memory | No specific guaranteed value disclosed | About 7.7GiB | A value from the observed environments, not a guaranteed product specification |
| Storage | Retains user files persistently | About 100GB persistent volume | A logical capacity; it does not necessarily occupy the same amount of physical disk at all times |
| GPU | GPU configuration inside the VM not disclosed | No GPU device found in the examined environments | Does not mean AI model inference does not use GPUs |
What Meta officially explains is the structure of assigning a VM to each user.
The figures of 2 vCPUs, about 7.7GiB of memory and 100GB of storage, on the other hand, are values observed in real user environments, not official specifications Meta guarantees to all users.
For example, just because the system shows 7.7GiB, it cannot be restated as "Muse is guaranteed 8GB of memory."
Likewise, even if the CPU model or virtual CPU count can be confirmed, each user does not necessarily have exclusive use of the corresponding physical CPU cores.
Meta has not currently disclosed minimum guaranteed performance per user, performance during peak load, or differences in VM configuration by pricing plan.
The browser and AI model inference may run outside the user's VM
The "browser" Muse uses is also not as simple as Chromium running constantly inside the user's dedicated VM.
In its explanation of the safety design, Meta says it places an actual Chromium-based browser in a separate virtualized environment and connects to it through an intermediary service.
The agent in charge of web operations is also set up to receive only the information needed to operate a page, so it cannot freely run arbitrary JavaScript on web pages.
When examining his own environment, Adwankar likewise confirmed a mechanism that connects to a separate virtual machine in order to use the browser.
In other words, just because a "dedicated cloud computer for the user" is provided does not mean every process, including the browser, runs inside that VM.
The same applies to inference by the AI model itself.
Meta explains that data needed for inference is sent outside the VM and processed through a dedicated path. No GPU device was found in the work environments examined.
From this, it is reasonable to think the observed 2 vCPUs are mainly the computing resources for Muse to manipulate files, execute code and control various tasks.
How many GPUs run Muse's AI models, where they are located, and how much computing resource a single request consumes cannot be determined from the figure of 2 vCPUs.
Files persist, but the same VM does not keep running forever
Adwankar also confirmed that, in his environment, a roughly 100GB persistent volume is separate from a temporary system area.
He further observed that during system updates the VM itself is replaced, and the user's persistent volume is reattached to the new VM.
Given this structure, Muse's "one per person" does not mean the exact same VM runs forever.
More precisely, it is better understood as a setup in which each user can keep using their work environment and data continuously, while the VM behind it can be swapped out as needed.
Meta also explains that users can view, edit and download files and memories inside the VM, and that data is backed up on an ongoing basis.
Separating the system area from user data in this way makes it easier to update the underlying software while preserving the user's files and work state.
However, there is no guarantee that the update method Adwankar observed is used in the same way for all users or at all times.
Nor does the 100GB capacity mean that 100GB of physical disk is reserved from the start for every user.
"2 vCPUs × number of users" doesn't tell you how many servers are needed
If we assume each Muse user is allocated 2 vCPUs and about 8GB of memory, it is tempting to calculate simply how many users one server could hold.
But estimating the actual infrastructure scale from that is difficult.
Not all users run their VMs at the same time, and virtual CPUs are not necessarily pinned to logical CPUs on the physical side. As for memory, the upper limit allocated to each user is not necessarily the same as the amount actually consumed in physical memory.
In the environment Adwankar examined, a mechanism that returns unused memory pages to the host was also confirmed.
So it is not appropriate to assume that, because "8GB per user" is displayed, every user constantly occupies 8GB of physical memory.
On the other hand, the storage that holds users' files and work history is needed even while the VM is not running.
In addition, inference GPUs to run the AI models and separate environments to run browsers are required. These must be considered computing resources separate from the 2 vCPUs shown in the user VM.
Therefore, simply multiplying the user VM's CPU and memory by the number of users cannot estimate the number of servers, capital costs or power consumption Meta needs for Muse.
To judge how far Meta can scale this approach, it is necessary to look not only at guaranteed resources per user but also at the share of VMs running concurrently, actual storage usage, browser environment utilization, and the computing load and usage limits on the AI inference side.
What is known at present is that in the several Muse environments confirmed, a relatively small virtual CPU and memory configuration is combined with persistent storage, while the browser and AI model inference are split off onto separate infrastructure.
If Meta later discloses per-plan computing resources, performance guarantees and limits during congestion, it will become clearer how far the model of "providing a cloud computer to every individual user" can be offered at scale.