OpenMuse, the one we could read instead of take apart

OpenMuse is the first personal agent we have looked at that did not need taking apart, because its source is published under an MIT licence and anybody can read it. Every other write-up on this site exists because a product would not say how it worked, 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. There is no list of things we could not establish about the runtime, because the runtime is in the repository.
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 it actually is

The repository was created on 2026-09-15 and its earliest commit lands the same day, so it is genuinely new rather than an older project renamed. As of 2026-09-23 it carries 1,426 stars and 153 forks, is written in TypeScript, is MIT licensed, and was still receiving commits on the day we checked.

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 labels the current state alpha.

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 is the one you want.

The same five questions, asked of a repository

This site asks every product the same five questions: where it runs, how tools are exposed, where memory lives, 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, with Google and browser protocol adapters 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.
How you reach it	One shared codebase for iOS, Android and web.
What we could not establish	Nothing about the runtime. Everything below the hosted persistence boundary, which is a separate service.

That last row is the whole reason this page exists, and it is the next section.

Where it 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 rather than being retried blindly. Anyone who has read our task pages will recognise why that matters: duplicate side effects are the failure that a naive retry produces, and a lease is one of the few honest answers to it.

How tools are exposed

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.

Where memory lives, and where it does not

Application state sits in PGlite or PostgreSQL. The workspace is a mounted volume. 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 part that is not open

The README is straightforward about this, in a section 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, and that no project key is shipped.

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.

It also produces a neat symmetry with the rest of this site. Every teardown here ends with a list of what we could not establish. An open project was supposed to have an empty list. Instead the list has exactly one line on it, and the line is a boundary the project drew itself.

It publishes what 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.

That is an unusual amount of public negative space, and it is worth dwelling on, because it is the thing the closed products almost never do.

Every teardown on this site ends with a list of what we could not establish. Those lists exist because the products would not say. This one published its own version of that list 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, 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 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, 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 is not a teardown in the sense the rest of the site means. Nobody probed anything. We read published documentation and a public repository, which is a much weaker claim to knowledge than the ones on the agent pages, and it deserves to be labelled differently.

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.

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 it work with? Its documentation points at the configured OpenAI, Anthropic or Google provider through CopilotKit, and live Google credentials are required for the mail and calendar features. The exact model is your configuration rather than a fixed part of the product.

Why cover an open project on a site about closed ones? Because it is the control case. Every other page here is an inference from the outside, and this one is not, which makes it useful for seeing which parts of a personal agent are genuinely hard and which were simply undisclosed.