Muse teardown: Meta's agent and its private Linux VM
Meta's personal agent, with a Linux machine of your own behind it.
Meta gave each Muse user a Linux machine. Not a metaphor, not a container abstraction you never see: sign in and there's a VM waiting, and the agent lives on it.
This page is shorter than the others on purpose. Muse is Meta's, the risk of getting a detail wrong is higher than it is for a startup, and we'd rather publish four things we're sure of than twelve we're mostly sure of.
The request is built on your machine, not fetched as a finished blob
Most agents assemble the model request on a server and ship the result. Muse assembles it on your VM, which is a stranger design than it sounds and has one consequence you can feel.
The fixed part is a small skeleton, around fifty lines, mostly routing rules. Everything personal gets embedded into that skeleton from plain markdown files in your home directory. Change one of those files and the runtime doesn't rebuild the whole package; it slips in a short note saying the context changed. Different jobs get different subsets, too. The main chat gets the full set. Subagents run without the workspace conventions. A background loop that maintains memory gets almost nothing but your profile.
On top of the skeleton sit the per-turn insertions, and there are a lot of them. On the VM we watched, 141 system-role messages were being computed for a single session: greetings, file-change notices, hourly memory passes reporting their own progress, subagents narrating where they've got to, research tasks checking in.
Two tool layers, kept deliberately apart
The permission sheet lists 52 connectors and 246 methods, and it carries no parameters at all. Each entry knows what it's called, what it belongs to, and whether it's allowed, asks first, or is refused. Nothing about how to call it.
The real definitions load separately, one namespace at a time, when something needs them. There are 58 skills, each a document the agent reads before acting rather than a function it calls.
Splitting it this way is the right call and more products should copy it. You get a cheap, stable permission contract that doesn't change when an API does, and the expensive part of a tool definition only enters the context when it's about to be used.
Memory is a file you could open
Your profile, your long-term notes, the assistant's own personality: markdown in a home directory, embedded straight into the request. Of the four agents on this bench, Muse is the one where "what does it think it knows about me" has a literal answer, sitting on a filesystem, in a format you can read.
We say *could* deliberately. The web surface can't leave that directory tree, an interactive terminal was never opened to us, and we're not going to claim you have a text editor on your own VM when we didn't verify it.
Web, and effectively only web
A messaging channel exists in the documentation. A paired-device story exists in the documentation too. Neither is where the product lives, and neither is what we tested. Browser work spins up a second machine rather than driving the Chrome on your desk.
What we couldn't establish
[TODO 保留本节,上线前逐条复核]
- The traffic between the runtime and the model. We know the structure of what goes in; we never saw a single one of the actual requests leave.
- Credentials. No permission, no access, and we didn't go looking for a way around that.
- Live third-party sign-ins. Never connected, so every integration we describe is described from its contract rather than from watching it work.
- An interactive terminal. The owners chose not to open one.
Pricing
[TODO Muse 的商业化形态与 Meta 账号体系挂钩,上线前单独核,不要照抄另外三家的结构]
How Muse scores
[TODO 接 /how-scoring-works 的五条轴,等 data/scorecard.json 定稿后填]
- 执行位置
- 工具暴露方式
- 记忆载体
- 渠道入口
- 我们没测到什么
The five axes
Where it runs
One Linux VM per user. The request is assembled on that machine rather than fetched as a finished blob. Browser work spawns a second, separate machine.
How tools are exposed
Two layers kept deliberately apart: a permission sheet of 246 methods carrying no parameters at all, and the real definitions loaded a namespace at a time when needed.
Where memory lives
Plain markdown in a home directory, embedded straight into the request. Changing one of those files inserts a short note rather than rebuilding the whole package.
How you reach it
Web is the real surface. A messaging channel exists but is not where the product lives.
What we could not establish
The raw traffic between the runtime and the model — structure known, contents never seen. Also credentials, live third-party sign-in, and an interactive terminal the owners chose not to open.
The other three
- PinePhones companies on your behalf about bills, refunds and cancellations.
- InstinctLives in your messaging apps rather than in a new interface.
- TownWeb and native Mac, with a real foothold on the machine itself.
All four runtimes, side by side on the same five axes.
See the scorecardOr read how we score, and why the existing agent benchmarks don't answer this.