Personal Agent Bench

nanoMuse, an open-source personal agent in the shape of Meta Muse

nanoMuse is an open-source personal agent that copies the shape of Meta's Muse and moves it off Meta's cloud and onto the phone and computer you already own. It is published on GitHub under GPL-3.0-or-later by a small team at Zhejiang University, with apps for Android, iPhone, Mac, Windows, Linux and the browser, and a relay that joins them which anyone can run. We have not tested nanoMuse and we have not taken it apart. This page is an account of what the project and its paper say, who said each part, and where the two already disagree.

  • nanoMuse puts a whole agent on each device, rather than one agent in a vendor's virtual machine. On Android and on a computer it can operate other apps through their screens, which Meta Muse cannot.
  • Its own documents describe an approval gate in front of every action, memory kept as Markdown files you can open, and a model you choose.
  • The paper that introduced it also reads how Meta Muse is built. Where that reading overlaps with our Muse teardown, it agrees with what we found.
  • Nothing here is a measurement. nanoMuse is not in our exam, has no score, and the project itself says it has no success rate to report yet.

What nanoMuse is, and who builds it

The project's README calls nanoMuse "an open-source personal agent for every device you own": one agent with a name and a look of its own that does things, keeps working while the app is closed, remembers you, and asks before anything you cannot undo. It describes itself as free, non-profit and community-run.

The first build went up on GitHub in late September 2026. The paper gives the first release date as 25 September; the release list shows version 0.1.1 published a day earlier in UTC. The pace since then has been fast. Version 1.0.0 was published on 8 October and 1.0.3 on 11 October, the forty-fourth release in under three weeks. On 12 October the repository had about 900 stars.

The paper, nanoMuse: An Open-Source Personal Agent for Every Device You Own, is by Guangyi Liu, Yong Liu and Jiangning Zhang of Zhejiang University and went on arXiv on 6 October. On Hugging Face Papers it had 103 upvotes by 12 October, and the README says it placed third on the daily list for 8 October. That is how it reached us: our weekly scan of Hugging Face for new agent benchmarks picked it up, and it was a product rather than a benchmark.

The team is in China and the project serves both audiences. The apps sign in with an e-mail address or a mainland-China phone number, the agent can answer in Telegram as well as Feishu, DingTalk and WeCom, and the README is translated into nine languages besides English. It is on our list of personal agents because it is built and documented for anyone to install.

nanoMuse vs Meta Muse: the same shape, turned inside out

The paper is direct about where it comes from. In its account, Meta Muse "showed the field what the product is": one agent with a name, one long conversation, memory you can read, messages it sends first, a wallet behind an approval. Then it argues that the other half of Muse, one Linux virtual machine per person in Meta's cloud, sold in one country, with nothing open beyond a small gadget SDK, is the wrong shape for something that holds a person's life.

nanoMuse's answer is to keep the first half and invert the second. The README's own comparison table puts it in three lines:

  • Where the agent runs. Meta Muse: a cloud VM per user. nanoMuse: your phone, your computer, or a server of yours, with one account across them.
  • Apps without an API. Meta Muse: out of reach, because the VM never touches your devices. nanoMuse: the screen itself, on the phone and the computer, with you taking over for logins. Not on iOS, which does not let one app operate another.
  • Models. Meta Muse: Meta's. nanoMuse: a free allowance on the project's relay, or your own key.

The paper is just as direct about what nanoMuse lacks next to Muse: a model of its own, the per-person VM with kernel-level tracking of which processes have touched private data, stand-in credentials swapped at the network edge, a wallet, and "the polish of a large team." That list is unusually candid for a launch paper, and it is the list a reader should keep in mind.

How nanoMuse acts: a ladder that ends at the screen

Each device runs its own agent. On Android it lives inside the app, built on an earlier open-source phone agent called OpenMinis, with a small Linux system, a shell, a browser and MCP servers. On a computer it runs inside a desktop app built on DeepSeek's open agent harness. The iPhone app has everything except hands on the screen, and the web app shows the same conversation from a runtime on a machine you own.

To reach an app, the paper says, the agent climbs a ladder and stops at the lowest rung that works: a skill, a command-line tool or an MCP server first; then a page fetched with your login; then the browser; and only last the device's own screen. That last rung, called Hands, is off by default. It works one screenshot at a time. The model sees the screen and the goal, then answers with one gesture and a sentence saying what it is about to press.

That sentence is the interesting part. A rule cannot judge a picture, but it can judge words, so a step whose label contains a committing word such as "confirm payment", "send" or "delete" is treated as sensitive and approved every time. On Android the accessibility text under the finger is checked as well, and the stricter of the two wins.

The devices also talk to each other. The README's example is saying something on the phone and having it run on the PC; the paper's is finding an order number on the phone and putting it in a spreadsheet on the Mac in one conversation. A job sent to another device runs under that device's own approval gate, so the phone cannot lend the Mac a permission the Mac never had.

What nanoMuse asks before it acts

Every tool call goes through what the project, borrowing Meta's word, calls a Sentinel. The paper gives its decision order: denied tools, your own rules, the always-allow and always-ask lists, then a taint rule (once a conversation has read private data, sending data outside the allow-list becomes a question), then the tool's risk against the mode you set, and last a short list of warnings no setting can wave through.

The current privacy document sorts what the agent may do into three tiers. Installing software runs and is reported afterwards. Deleting and sending ask first, and you may remember the answer for one chat or for one folder, recipient, site or app. Paying, ordering, booking, trading and transferring ask "at the moment of paying, every time." Passwords, verification codes and card numbers are never typed by the agent; those screens are handed to you.

Here the record already disagrees with itself. The paper, describing version 0.1.40, says a payment approval "is never remembered." The privacy document for the 1.0 releases describes an option called *Remember and run next time in X*, limited to one app or site, unlocked with your fingerprint, face or PIN, and announced in the chat each time it is used. That may be a deliberate change after the paper was written, but it is the clearest example of why the paper should be read as a snapshot rather than as the current product.

The paper is also honest about the limit of all this. On a single device the Sentinel runs in the same trust domain as the agent. It is, in the paper's words, "a policy boundary," not the privilege boundary Meta Muse builds by keeping real credentials on a host the agent cannot reach. A compromised device is a compromised agent.

Where nanoMuse keeps your memory and your chats

On the phone, memory is a set of Markdown files you can open in the app: who the agent is, who you are, what holds across conversations, a dated diary, and the agent's routines. On the computer each memory is a line with a change log and an undo. The paper lists, as an open problem, that a memory line does not yet record which model wrote it or how sure it was.

What leaves the device depends on how you run it. With your own API key and no account, the privacy document says nothing of yours leaves except the calls to your model provider. Sign in and two more things happen, both by default:

  • Your chats are synced. The text of the main conversation is stored on the project's relay, nanoMuse Cloud, so every device shows the same history. Files, images and tool results are not uploaded. One switch turns it off and deletes what is stored.
  • Your chats may be kept for training. A switch called *Help improve nanoMuse's AI models* is on for accounts created on the community relay since its version 0.9. While it is on, the relay keeps the text of your chats with the relay's models to train an open model. It does not keep your memory files, tool results or images.

The relay's free allowance is ¥10 of model use per account, paid by the developer, and the relay forwards requests to Alibaba Cloud's Model Studio. The paper calls the training default "the choice in this project we are least sure of." Anyone who would rather not take it can run their own relay, which the self-hosting guide sizes for a server with one virtual CPU and 1 GB of memory, or skip the relay and use their own key on one device.

What the nanoMuse paper says about Meta Muse, checked against our teardown

A third of the paper is a reading of how Meta Muse is built, from Meta's public documents, the shipped apps, and what the authors describe as a copy of Muse's production system prompt. They say they do not reproduce it, mark every statement as documented, prompt, observed or inferred, and state plainly that they cannot verify the copy's provenance beyond its consistency with the rest. We do not repeat the prompt-based details here.

We did check the overlap against our own teardown of Muse, which comes from the web product rather than from any prompt. Where the two cover the same ground, they agree: one Linux VM per user in Meta's cloud; a gatekeeper that alone can approve connector actions and outbound traffic; credentials held outside the agent's reach; memory as plain files in a home directory; and tool definitions that load a group at a time rather than all at once. We found nothing in the paper that contradicts a published line on our Muse page.

Two things in the paper are not on our Muse page. One is Meta's gadget SDK, released on 2 October under the Apache licence, which lets a device you build pair with Muse. The other is the observation that Muse's browser sees an accessibility snapshot of each page, so it cannot operate an interface that lacks one. The first comes from Meta's own repository; what it does and does not open is set out on Is Meta Muse open source?. The second is the gap nanoMuse's hands are built to fill.

nanoMuse is not OpenMuse

The names collide, so it is worth saying plainly. OpenMuse is a different project, from CopilotKit, published on 15 September under the MIT licence: a server with a persistent browser and a Linux workspace, and apps that are windows onto it. nanoMuse's paper describes it the same way and draws the difference in one sentence: nanoMuse puts the agent on the device, which gives it the phone's screen and lets a single device work with no server at all.

Neither is affiliated with Meta. Both borrowed the name because Muse defined the shape they are building towards. If you are comparing where personal agents actually run, our where it runs page sets the hosted ones and the self-run ones side by side.

What a teardown of nanoMuse would have to answer

nanoMuse is unusually easy to examine, because the code is public. That makes it closer to OpenMuse, which we read rather than probed, than to the closed products in our teardowns. If it went through the process we use, these are the questions it would have to settle.

Whether the Sentinel's decision order in the code matches the paper's, release by release, now that the payment tier has already moved. What the Hands rung actually does with an icon-only button, which the paper admits is judged by neither label nor accessibility text. What the relay stores in practice when sync is on, against the list in the privacy document. Whether a device that was offline really forgets a deleted account, as the paper says. And the number the project says does not exist yet: how often the hands succeed, and how often a person has to take over.

A published design and an observed behaviour are different kinds of evidence, and only the second goes on our scorecard. Until then nanoMuse gets a page like the ones for Claude Dispatch and OpenAI Dots. A blank here is not a low score. It is a blank.

FAQ

What is nanoMuse? An open-source personal agent, published under GPL-3.0-or-later, that runs as a whole agent on each of your devices: Android, iPhone, Mac, Windows, Linux and the browser. A relay that anyone can host joins them into one conversation.

Is nanoMuse made by Meta? No. It is an independent project from a small team at Zhejiang University, built in the shape of Meta Muse and openly compared with it. Meta Muse itself is closed and runs in Meta's cloud.

Is nanoMuse the same as OpenMuse? No. OpenMuse is a separate open-source project from CopilotKit that runs on a server. nanoMuse runs on your own devices and can operate the screen of an Android phone or a computer.

Is nanoMuse free? The project says it is non-profit and never charges. Signing in gives ¥10 of model use on its relay, paid by the developer, or you can use your own key from one of the listed providers, or a ChatGPT plan.

Does nanoMuse keep my chats? If you sign in, the main conversation is synced to the relay by default, and on accounts created on the community relay since its version 0.9, chats with the relay's models are kept to train an open model until you turn that switch off. With your own key and no account, the project says only the calls to your model provider leave the device.

Have you tested nanoMuse? No. It is not in our exam, it has no score, and we have not taken it apart. Everything on this page comes from the project's repository, documents and paper, dated and linked.