nanoMuse is a personal agent you can host yourself

An agent that acts, and keeps acting when the app is closed

nanoMuse is described as an open source personal agent for every device you own: one agent with a name and a look of its own, in the style of Meta's Muse, which does things instead of answering questions, keeps working while the app is closed, remembers you, and asks before anything you could not undo.

Those four properties are the design, and each one is a decision.

Doing things rather than answering questions moves the product from a chat interface to an agent that operates a device. The topics attached to the repository include `gui-agent`, `computer-use` and `cross-device`, and the project description says it works on Android, iPhone and iPad, Windows, macOS and Linux and in the browser, with your phone's screen and your computer as its hands.

Keeping working while the app is closed is the difference between a session and a job, and it is why the repository contains a daemon service as well as a chat. The release cadence reflects the same intent. Version 1.0.0 Keel came on 2026-10-09 for the phone, the desktop and the browser, installs over the previous version and keeps your data. The versions after it are 1.0.3 Helm, 1.0.4 Compass and 1.0.5 Lookout, and the news entry says a version every few days.

The project has a paper on arXiv, 2610.08699, titled nanoMuse: An Open-Source Personal Agent for Every Device You Own, by Guangyi Liu, Yong Liu and Jiangning Zhang of Zhejiang University, and the news list records that it was third on Hugging Face Daily Papers on 2026-10-08.

The licence is GPL-3.0-or-later, and the project describes itself as free, open source and non-profit, run on the idea that a personal agent should not live only in someone else's cloud.

The Sentinel decides what the agent is allowed to do

The Python package manifest describes the runtime more precisely than the README does, and the sentence worth reading is this one. It is the agent, the Sentinel that decides what may run, the hands that work a phone or a computer, and the web app. Bring your own model.

So the runtime has four parts, and the Sentinel is the one that matters for anyone thinking about safety. The project description says the agent stops to ask before anything you could not undo, and the configuration exposes that as a mode with three values, `ask`, `strict` and `auto`, under the setting `NANOMUSE_SENTINEL_MODE`.

# ask | strict | auto
NANOMUSE_SENTINEL_MODE=ask

`ask` is the default in the sample environment file. The other two settings around it are just as revealing. `NANOMUSE_LLM_TOOL_MODE` takes `auto`, `native` or `prompt` and controls how the model is given tools, so an agent can either use a native tool-calling interface or be told about the tools in the prompt. And `NANOMUSE_VAULT_KEY` is a base64 Fernet key for the credential vault, with a note that the default is a file in the data directory.

That last item matters more than it looks. An agent that operates a phone and a computer needs credentials for the services it touches, and the project stores them in an encrypted vault rather than in the configuration file, keyed by a Fernet key that the operator supplies.

The practical reading is that the Sentinel is the boundary between an assistant and an agent, and it is configurable rather than fixed. A user who wants the agent to act on their own sets `auto`, and one who wants to approve each irreversible step leaves it at `ask`.

Bring your own model, or lean on the community relay

The model story is deliberately flexible, and the environment file is where you choose.

The provider keys are listed first, `DEEPSEEK_API_KEY`, `OPENAI_API_KEY`, `ANTHROPIC_API_KEY` and `OPENROUTER_API_KEY`, and then a set of nanoMuse overrides that take precedence over the config file.

# openai | openai_responses | chatgpt | a catalogue id (deepseek, bailian, zhipu, openrouter, ...)
NANOMUSE_LLM_PROVIDER=openai
NANOMUSE_LLM_MODEL=deepseek-flash
NANOMUSE_LLM_BASE_URL=https://api.deepseek.com
NANOMUSE_LLM_API_KEY=

The comment lists the provider shapes the runtime understands, a set of API dialects on one side and a catalogue of named providers on the other. The `NANOMUSE_LLM_BASE_URL` variable means any OpenAI-compatible endpoint can be used, and the `deepseek-flash` model in the sample is a deliberately small one.

The relay is the other half. The README says that when you sign in you get a free allowance of model use on the community relay, and that the developer pays for it, and that when it is gone you should use your own key, with a link to the own-key documentation. The same relay runs on a server of yours, so nothing has to leave your house.

That is the honest shape of the offer. A community-funded allowance is a way to try the project without bringing a key, and the documentation is clear that it is temporary. For a deployment that has to keep working, the own-key path is the plan, and the relay is the thing you run yourself.

The runtime dependencies explain the rest of the design. `openai` is the model client, `mcp` is the Model Context Protocol support, `fastapi` and `uvicorn` are the app server, `cryptography` backs the vault, `pywebpush` and `qrcode` are for notifications and pairing, `ddgs` and `beautifulsoup4` and `html2text` are for search and page reading, `pypdf` for documents, and `playwright` is an optional extra for the browser tool.

The container is the honest deployment story

The docker-compose file is the clearest description of the runtime in the repository, and its header comment explains the whole model in five lines. The agent sees two mounts, `/data` for memory, goals, vault, audit log and threads, and `/workspace` for its files, and `config/config.toml` is mounted read only, with the instruction to run `nanomuse config init` on the host first.

There are three services, and they are the three ways to use the agent.

cp .env.example .env && $EDITOR .env
docker compose up -d app
docker compose run --rm muse
docker compose run --rm muse run "plan my week"
docker compose up -d daemon

The `app` service runs the web interface on port 8787, the `muse` service is a terminal chat, `muse run` executes a single task, and the `daemon` runs with an interval of 3600 to advance goals on a timer with no UI at all.

That daemon is the piece that makes the claim about keeping working while the app is closed concrete, and it is a service rather than a feature, which is the honest way to build it.

The security posture of the container is worth reading too. The compose file drops all capabilities with `cap_drop: ALL` and sets `no-new-privileges:true`, and there is a commented `read_only: true` with a tmpfs on /tmp, described as making the container filesystem immutable apart from the mounts. The Dockerfile creates a non-root user called `muse` with uid 1000 and chowns /data, /workspace and /app to it, and the comment at the top of the Dockerfile says the agent sees only /data and /workspace.

The Dockerfile also has a build argument for the browser tool, `WITH_BROWSER=0`, and the comment says setting it to 1 bundles Chromium via Playwright and costs about 400 MB more, and a second argument for a regional PyPI mirror, `PIP_INDEX_URL`.

One repository, four surfaces and a demo

The directory layout is what a project that spans platforms looks like when it is one repository.

There is `android/` for the Android app, `web/` for the web console, `site/` and `website/` for the two web properties, `cloud/` for the hosted side, `config/` for the TOML configuration with an example file, `nanomuse/` for the Python runtime, `harness/` for the agent harness, `scripts/`, `tests/` and `docs/`, plus `demo/` with `mobilegym/` and `showcase/`.

The primary language of the repository is Swift, which is the iPhone and iPad app, and the Python package is the runtime. The news entry for 2026-09-25 says nanoMuse was released under GPL-3.0-or-later as an Android app built on OpenMinis 1.13, with the relay, the desktop app and the iPhone app following in the days after.

The install table in the README is the part with the practical detail. The browser entry at demo.nanomuse.dev is described as a nanoMuse on a simulated phone after a sign in, and explicitly labelled a demo, with the apps below being the real thing. The Android build is an APK for Android 8.0 and later on arm64, and every version is signed with the same key so it installs over the last. The iPhone and iPad build is on TestFlight as a beta that passed Apple's beta review. The macOS build is a DMG for macOS 12 and later, for both Apple Silicon and Intel.

The `docs/readme/` directory holds the README in ten languages, and the repository carries an `AGENTS.md`, a `CLAUDE.md` and a `CITATION.cff`, which is the standard set for a project that expects both human and automated contributors.

The non-profit framing and what it asks of you

The project is explicit about what it is and who it is for. It calls itself free, open source and non-profit, and says we will build it together, and it invites issues and pull requests with the argument that a personal agent should not live only in someone else's cloud, so nanoMuse is the open source, low cost alternative: on your own devices, with a model you choose and a relay you can host yourself.

That framing has a consequence for anyone evaluating it. The repository was first released on 2026-09-25, and the news list records a thousand stars on GitHub eighteen days after the first release, with four days on GitHub Trending's Swift list, seventh on October 7 and fourth on October 10. A project that lands a version every few days, from a 1.0.0 that shipped on 2026-10-09, is a project in motion, and the daily use of the word latest in the README is a reminder of that.

The good side of the same fact is that the feedback loop is short. The roadmap document is linked from the news entry and says what comes next, and the contributing guide is at the root of the repository next to the code of conduct.

The licence is GPL-3.0-or-later, and the repository carries a `NOTICE` file and a `THIRD_PARTY_NOTICES.md`, so the third party components in the distribution are accounted for. There is also a `SECURITY.md`, which matters more here than in most projects because the agent holds a credential vault and drives real devices.

One last detail from the environment file is worth repeating, because it is the kind of thing that catches people out. `NANOMUSE_LIVE=0` controls whether the tests marked `live` run against the configured model, so by default the test suite does not spend your model allowance, and you opt in deliberately.

Editorial conclusion

nanoMuse suits a developer who wants an agent that acts on their devices rather than one that only answers, and who is prepared to supply a model key or run the relay on their own hardware. It is the wrong tool for someone who wants a finished product with a support commitment, and the wrong choice if you need a personal agent today, since the project was first released on 2026-09-25 and versions land every few days. Check first the Sentinel mode in your configuration, because `ask`, `strict` and `auto` decide how much the agent may do without a confirmation, and decide on the model provider before you install, since the community relay allowance is described as temporary.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. nano-muse/nanoMuse on GitHub
3. Project website
4. README
5. Releases