---
title: "OpenMuse: reading the source instead of guessing"
description: "OpenMuse is an open personal agent we can read rather than probe. What its source says about where it runs and what it stores, and the one part that is not."
url: https://personalagentbench.com/openmuse/
last_updated: 2026-11-05
---

# OpenMuse, the one we could read instead of take apart

OpenMuse is an open source personal agent, and the first we have looked at that did not need probing, because its [source is published on GitHub](https://github.com/CopilotKit/openmuse) under an MIT licence and anybody can read it. The four closed-product teardowns describe behaviour observed from outside, so somebody had to find out from the outside. This one publishes the answer. That makes it useful for a reason that has nothing to do with whether you would run it: it shows what these products look like when the architecture is not a secret, which gives you something to hold the closed ones against.

- It is not Meta's Muse, and it is not affiliated with it. It is a separate open source project that borrowed the name, built by the CopilotKit team.
- Reading source instead of probing changes what we can tell you. Repository access does not establish deployed behaviour, security properties or hosted-service internals; we did not run a deployment. The pinned review linked below retains explicit unknowns.
- The interesting finding is not in the code, it is in the requirements. Conversation persistence needs a hosted service that the MIT licence does not cover.
- It has not been through our exam and has no score here. This page describes an implementation, it does not rank one.

## What OpenMuse actually is

The repository was created on 15 September 2026 and its earliest commit lands the same day, so it is genuinely new rather than an older project renamed. GitHub's API on 5 November 2026 showed about 6,200 stars and 890 forks, up from 1,426 and 153 when we first checked on 23 September, with the latest push the day before. It is written in TypeScript and MIT licensed.

Its own description calls it a personal agent with a browser, terminal, files, and work that keeps going, built with CopilotKit and AG-UI. The [README](https://github.com/CopilotKit/openmuse/blob/main/README.md) labels the current state alpha, "for self-hosting and building on."

It has siblings. CopilotKit also publishes [OpenBot](https://github.com/CopilotKit/OpenBot), open source "AI coworkers that each get a computer of their own", and [OpenDots](https://github.com/CopilotKit/OpenDots), created on 29 September, the day OpenAI launched the product we cover on [OpenAI Dots](https://personalagentbench.com/openai-dots/). Each borrows the shape of a commercial product, as OpenMuse borrows Muse's.

And it has namesakes. [openmuse.ai](https://openmuse.ai/) is a collection of LoRAs and art for open video models, and openmuse.chat is a multi-model chat interface. Neither is this project. A Reddit post in r/SideProject also announces a separate app called Open Muse for iPhone, Mac and Android; we could not open it, so we know only its title. A third, [open-muse.dev](https://www.open-muse.dev/), appeared since: a hosted open-source alternative built on a separate diggerhq/openmuse repository, not the CopilotKit one.

The name matters for one reason only: it is not the Meta product, and reading this page as a review of Meta's Muse would be a mistake. If that is what you came for, the [Muse teardown](https://personalagentbench.com/agents/muse/) is the one you want, and [is Meta Muse open source?](https://personalagentbench.com/is-meta-muse-open-source/) covers what Meta itself has opened.

## OpenMuse setup requirements and verification limits

We have not deployed it, so this is what the README asks of you rather than a report of doing it. The [quick start](https://github.com/CopilotKit/openmuse/blob/main/README.md#quick-start) needs Node 24, pnpm and a CopilotKit Intelligence project key, which you get by logging in with CopilotKit's command line tool. The local sample app needs no model, no Google account and no Docker, and runs on fictional data. Before setup, read the [telemetry opt-out instructions](https://github.com/CopilotKit/openmuse/blob/main/docs/TELEMETRY.md). Hosted Intelligence persistence is required in the documented setup; we have not verified a persistence opt-out. This setup account follows the README on the main branch, which keeps moving; the code review linked further down is pinned to commit 1ac68f3. Neither is a tested installation recipe.

For real work you add three things. A model provider key: the default is OpenAI's GPT-5, and the README says Anthropic or Google work if you change the model setting and supply that provider's key. Google OAuth credentials with the Gmail and Calendar APIs enabled, for the mail and calendar features. And optionally the browser worker and the Linux computer, which run as separate services or through Docker Compose. The README also has a Deploy to Render button that sets up the API, the web app and a private browser as three services.

It says plainly that a deployment has one owner protected by a shared access key and "is not a multi-tenant authentication system", and asks you to use HTTPS and restricted network access for a remote host.

## The same six questions, asked of the OpenMuse repository

This site asks every product the same six questions: where it runs, how tools are exposed, where memory lives, what you get to approve, how you reach it, and what we could not establish. Those questions were designed for products that will not answer them. Pointing them at source code is a different exercise, and a much quicker one.

| Question | What the repository says |
| --- | --- |
| Where it runs | Its own server, a task worker, and a browser worker. Persistent Chromium plus an optional Linux container with a persistent workspace volume. |
| How tools are exposed | A CopilotKit runtime streaming AG-UI events (messages that keep the interface in step with the agent), with Google and browser protocol adapters (connectors translating actions into each service’s format) kept in their own package and a stored action review step in front of them. |
| Where memory lives | PGlite or PostgreSQL for application state, a persistent volume for the workspace, and a hosted service for conversation history. |
| What you get to approve | A stored action review step between deciding and doing, with approvals, saved receipts, pause, resume, cancel and retry listed as first-class features. |
| How you reach it | One shared codebase for iOS, Android and web. |
| What we could not establish | Deployed behaviour, security assumptions, complete approval coverage, external side-effect recovery, memory erasure, runtime egress and hosted persistence internals; we did not deploy it. |

The [source comparison pinned to commit 1ac68f3](https://personalagentbench.com/open-source-personal-agents/#openmuse) adds a narrower implementation review to this documentation-led account. It establishes Google proposal review without applying the same gate to the inspected computer-command path. Sources: [apps/server/src/actions.ts](https://github.com/CopilotKit/openmuse/blob/1ac68f3909f2478ab6280883f1ab5ea65eb5719d/apps/server/src/actions.ts#L59-L148), [apps/server/src/computer.ts](https://github.com/CopilotKit/openmuse/blob/1ac68f3909f2478ab6280883f1ab5ea65eb5719d/apps/server/src/computer.ts#L416-L488). The hosted persistence boundary is discussed below. REA, the code-graph tool described on that page, mapped imports, storage and request call sites; conclusions about approval paths, defaults and telemetry were confirmed by reading the source.

## Where OpenMuse runs

The repository splits into an API server, a browser worker, and an optional computer. The browser worker is a token-protected Playwright service holding persistent profiles, so a session survives between tasks. The computer is a nonroot Linux container image with a bounded filesystem helper and a persistent volume attached.

Two details are worth pulling out because they are design positions rather than plumbing.

You can take over. The README says you can open the agent's browser or terminal and continue the work yourself. That is a different relationship from the products that hand you a summary and no way in.

Interrupted work recovers through SQL leases: database locks that let a worker claim a task, then expire so another worker can recover it after a crash. Anyone who has read our task pages will recognise why that matters: [duplicate side effects](https://personalagentbench.com/tasks/cancel-a-subscription/) are the failure that a naive retry produces, and a lease helps recover workers but does not alone prevent duplicate external side effects; the end-to-end idempotency strategy was not verified.

## How OpenMuse exposes tools

Capabilities arrive as adapters in their own package, with a review step recorded between deciding and doing. Approvals, saved receipts, pause, resume, cancel and retry all appear in the feature table as first-class surfaces rather than as things a support article promises.

Compare that with what the closed products do. One separates a permission sheet from its tool definitions and loads schemas only when needed. Another ships a command line and refuses to run an action until its manual has been read. Those are more inventive than adapters plus a review step, and they had to be discovered by probing. Here the equivalent design decision is a directory you can open, which is the honest advantage of reading over guessing.

## The part of OpenMuse that is not open

Most of the memory is yours. Application state sits in PGlite or PostgreSQL, the workspace is a mounted volume, and personal context is editable in the app: name, tone, avatar, and memories you can change. Conversation history is the exception, and it is the finding worth the page.

The README is straightforward about it, in its [Rich Threads section](https://github.com/CopilotKit/openmuse/blob/main/README.md#copilotkit-rich-threads), which most readers will never reach. Every deployment requires a CopilotKit Intelligence project key on the API server, for conversation persistence and replay. The README then says plainly that Intelligence is a separate service, that it is not included in this repository's [MIT licence](https://github.com/CopilotKit/openmuse/blob/main/LICENSE), and that no project key is shipped. Its deployment notes add that because chat threads are stored by Intelligence, a thread can still load after you sign back in even when your own disk was never attached.

So the phrase self-hostable carries an asterisk. You can run the server, the browser worker and the Linux computer yourself, read every line of what they do, and change any of it. The record of what you and the agent said to each other persists through a hosted service operating under different terms from the rest.

This is disclosed, not hidden. The project says it in its own documentation and draws the licence boundary explicitly. It is on this page because it is the single fact most likely to matter to somebody choosing an open implementation for control, and least likely to be read.

There is a second boundary, in the README's section on tracking. The CopilotKit SDK sends runtime telemetry to PostHog, and the README says telemetry "defaults to full capture", with opt-outs documented separately. Deployments are asked to keep a telemetry ID so runtime usage can be joined to the Intelligence signup account. That is also disclosed, and also easy to miss.

Every teardown here ends with a list of what we could not establish. Published source still leaves deployment, recovery and security properties unverified. The hosted persistence and telemetry boundaries are explicit examples, not an exhaustive list. Complete approval coverage, memory deletion and effective runtime egress also remain unestablished in the pinned review. Sources: [apps/server/src/db.ts](https://github.com/CopilotKit/openmuse/blob/1ac68f3909f2478ab6280883f1ab5ea65eb5719d/apps/server/src/db.ts#L1-L31), [apps/server/src/db.ts](https://github.com/CopilotKit/openmuse/blob/1ac68f3909f2478ab6280883f1ab5ea65eb5719d/apps/server/src/db.ts#L154-L180), [apps/server/src/engine/service.ts](https://github.com/CopilotKit/openmuse/blob/1ac68f3909f2478ab6280883f1ab5ea65eb5719d/apps/server/src/engine/service.ts#L138-L155), [apps/server/src/config.ts](https://github.com/CopilotKit/openmuse/blob/1ac68f3909f2478ab6280883f1ab5ea65eb5719d/apps/server/src/config.ts#L141-L142), [apps/server/src/config.ts](https://github.com/CopilotKit/openmuse/blob/1ac68f3909f2478ab6280883f1ab5ea65eb5719d/apps/server/src/config.ts#L26-L28), [apps/server/src/config.ts](https://github.com/CopilotKit/openmuse/blob/1ac68f3909f2478ab6280883f1ab5ea65eb5719d/apps/server/src/config.ts#L145-L159), [apps/server/src/agent.ts](https://github.com/CopilotKit/openmuse/blob/1ac68f3909f2478ab6280883f1ab5ea65eb5719d/apps/server/src/agent.ts#L55-L68).

## What OpenMuse says it cannot do yet

The feature table in the README describes what runs in the current alpha, and then the documentation says what does not.

Graphical desktops and autonomous checkout are named as future work. Health, bank and social connectors, device push notifications, voice, generated executable tools, and automatic reservations and payments are on the roadmap rather than in the product. The OpenBot adapter ships disabled, pinned and contract-tested against upstream interfaces, with live session bridging and computer backend wiring listed as unfinished. There is a [separate document for what has been verified](https://github.com/CopilotKit/openmuse/blob/main/docs/VERIFICATION.md), and the gaps are in the [roadmap](https://github.com/CopilotKit/openmuse/blob/main/ROADMAP.md).

That is an unusual amount of public negative space, and it is the thing the closed products almost never do: it published its own list of what is missing without anybody asking.

Read the marketing for any personal agent and you will find claims about what it can do, arranged so the edges are hard to locate. Finding the edges is most of the work behind [our method](https://personalagentbench.com/how-we-take-them-apart/), and it is why the exam is built around the awkward cases rather than the demo ones. A roadmap that names the gaps is doing voluntarily what we otherwise have to reconstruct.

It also means the honest summary of this project is narrower than its ambition. It is an alpha with real infrastructure, a clear licence boundary, and a published account of its own incompleteness. That is a better starting position than most, and it is not the same thing as a finished product.

## What an open implementation tells you about the closed ones

The useful comparison is not feature against feature. It is which problems everybody has to solve.

Persistent browser profiles, a container for file work, an approval step before consequential actions, recovery for interrupted tasks, and somewhere durable to keep what the agent learned. Those appear in this repository and they appear, in different forms, in every product we have taken apart. That is evidence they are structural to the category rather than the choices of one team.

Where the implementations diverge is the interesting part, and the [teardowns](https://personalagentbench.com/agents/) are where the divergence is documented: a dedicated machine per user against a leased sandbox, markdown you could open against compartmentalised stores, a web surface against a message thread. Seeing one implementation in full makes those choices legible as choices, which is harder when every example is a black box.

## What this page is not

It is not a score. OpenMuse has not been through our exam, it is not on the [scorecard](https://personalagentbench.com/), and nothing here says how often it finishes a task, because we have not measured that.

It is not a recommendation. Alpha software with a hosted dependency is a specific kind of proposition and whether it suits you is not a question this site answers.

And it was read, not probed. Our [landscape list](https://personalagentbench.com/landscape/) marks OpenMuse "read from source", because we examined published code and documents rather than a running copy. But the examination was reading published documentation and a public repository. That tells you what the code is meant to do, not what a running copy did, which is a different claim from the ones on the [agent pages](https://personalagentbench.com/agents/).

## FAQ

**Is OpenMuse the same as Meta's Muse?** No. It is a separate open source project from the CopilotKit team, published under an MIT licence, with no affiliation to Meta. It shares part of the name and some of the ambition. For the Meta product, see the [Muse teardown](https://personalagentbench.com/agents/muse/). It is also not [nanoMuse](https://personalagentbench.com/nanomuse/), a different open-source project that runs the agent on your own phone and computer rather than on a server.

**Is OpenMuse really self-hostable?** The server, browser worker and Linux computer run on your infrastructure and their source is MIT licensed. Conversation persistence and replay require a CopilotKit Intelligence project key, and the README states that Intelligence is a separate service not covered by that licence. Whether that counts as self-hosted depends on what you needed self-hosting for.

**Has it been benchmarked here?** No. It has no score on this site and no completion rate, because it has not been through the exam. This page describes what its source says about how it is built, which is a different kind of claim from the ones on the scorecard.

**What models does OpenMuse work with?** The README's default is OpenAI's GPT-5, and it says Anthropic or Google work through CopilotKit if you change the model setting and supply the matching key. Live Google credentials are required for the mail and calendar features.

**Where is the OpenMuse GitHub repository?** At [github.com/CopilotKit/openmuse](https://github.com/CopilotKit/openmuse). The README there has the quick start, the licence boundary and links to the roadmap.

**Why cover an open project on a site about closed ones?** Because it is the control case. The four closed-product teardowns rely on outside observations; this page instead describes public source, with deployment behaviour untested, which makes it useful for seeing which parts of a personal agent are genuinely hard and which were simply undisclosed. Our [open-source personal-agent comparison](https://personalagentbench.com/open-source-personal-agents/) extends that approach to other repositories, including the dedicated [Hermes Agent review](https://personalagentbench.com/hermes-agent/) and hub sections for [ZeroClaw](https://personalagentbench.com/open-source-personal-agents/#zeroclaw) and [NanoClaw](https://personalagentbench.com/open-source-personal-agents/#nanoclaw).

## More on Muse

- [**Meta Muse teardown**](https://personalagentbench.com/agents/muse/)
- [**Meta Muse review**Meta Muse review roundup: what reporters who used it found, every reported incident, and how each one compares with our own teardown of Muse.](https://personalagentbench.com/meta-muse-review/)
- [**Is Meta Muse open source?**Is Meta Muse open source? The agent, app and cloud VM are closed. Muse Spark Open has open weights under a restrictive licence; Wonder and Ember have none.](https://personalagentbench.com/is-meta-muse-open-source/)
- [**nanoMuse, public record**nanoMuse is an open-source personal agent in the shape of Meta Muse, on your own phone and computer. We have not tested it: what is public, and who said it.](https://personalagentbench.com/nanomuse/)

---

Published by Personal Agent Bench (https://personalagentbench.com), run by the Zentor team. Zentor builds agent software of its own, so its products are not on the scorecard and will not be added.