TL;DR

OpenMuse (CopilotKit/openmuse) is an MIT-licensed, self-hostable personal agent that CopilotKit announced on September 22, 2026, exactly two weeks after Meta shipped Muse. The pitch is the same as Meta’s: ask for an outcome, let the agent work in its own browser, terminal and files, review the risky steps, and come back to a result. The difference is that the whole thing runs on your server, under a licence you can read, with a model and provider you choose.

It is a template, not a product. CopilotKit says so in the first line: “Clone this template and customize it however you want.” You get an Expo app for iOS, Android and web, a Hono API with a durable task engine, a Playwright browser worker with persistent Chromium profiles, an optional Docker Linux “computer”, reviewed Gmail and Calendar adapters, PDF form filling and public-page watchers.

Key facts as of 2026-10-01:

  • Stars: 3,504 (460 forks) 16 days after the repo was created on 2026-09-15; last push 2026-09-29
  • Licence: MIT for the repo, but every mode requires a CopilotKit Intelligence project key, which is a separate hosted service that is not covered by the licence
  • Stack: TypeScript monorepo; Node 24 LTS, pnpm 11.19.0, PGlite (embedded Postgres) by default, PostgreSQL optional
  • Models: OpenAI (default openai/gpt-5), Anthropic or Google via provider keys; any OpenAI-compatible Responses endpoint via OPENAI_BASE_URL
  • Status: self-described alpha; the project’s own VERIFICATION.md says live-model and real-Google-account acceptance are “pending”

Verdict: the most complete open-source answer to Meta Muse so far, and a far better starting point than wiring a browser agent, a job queue and a mobile app together yourself. But read the word alpha literally, and know that the “open-source personal agent” still phones home to CopilotKit’s cloud for thread persistence unless you merge a community PR.

Quick reference

Repogithub.com/CopilotKit/openmuse
Stars3,504 (2026-10-01), created 2026-09-15
LicenceMIT (CopilotKit Intelligence service excluded)
LanguageTypeScript (Expo / React Native, Hono, Playwright)
RequirementsNode 24 LTS, pnpm 11.19.0, CopilotKit Intelligence key; Docker optional
PlatformsiOS, Android, web
One-click deployRender Blueprint (3 services, Standard plan minimum)
Default modelopenai/gpt-5; Anthropic and Google supported
Local sample modeRuns with no model, no Google account, no Docker, fictional data

What OpenMuse is, and what it is not

CopilotKit is the company behind AG-UI, the agent-to-UI streaming protocol, and OpenBot, the governed “AI coworker” platform it open-sourced on September 18. OpenMuse is the consumer-shaped sibling: one owner, one phone, one agent that reads your mail, watches prices and fills in forms.

The architecture is three processes plus a client:

flowchart TD
  Client[Expo / React Native / Web] -->|AG-UI + authenticated API| API[Hono + CopilotKit runtime]
  API --> Tasks[Durable task worker]
  API --> Threads[CopilotKit Intelligence]
  API --> Store[(PGlite or PostgreSQL)]
  Tasks --> Review[Stored action review]
  Review --> Google[Gmail / Calendar adapters]
  Tasks --> Browser[Chromium worker + persistent profiles]
  API --> Computer[Optional Docker Linux computer]
  • apps/server is the API, the CopilotKit runtime, the task engine, action reviews, files and persistence. The task worker runs in-process by default and coordinates through SQL leases, so an interrupted job is picked up again after a restart.
  • apps/worker is a token-protected Playwright service. Each thread gets a persistent Chromium profile, so a login survives between tasks, and the app can open a live screenshot console (“Take control”) when the agent hits a captcha or a checkout.
  • apps/computer is a nonroot Linux image with a read-only root filesystem, dropped capabilities, no host mounts, no Docker socket, no model keys and no network. The agent gets a /workspace volume, bounded 30-second commands and saved exit receipts.
  • apps/mobile is the shared Expo UI with CopilotKit’s headless chat hooks.

What the September 16 verification record says is actually exercised: chat with streamed AG-UI events and inline email, browser, PDF, plan and finance cards; durable tasks with pause, resume, cancel, retry and approval; Goals with public-page watchers for text changes and USD price thresholds; AcroForm PDF filling; a CSV spending tracker; and Gmail/Calendar adapters where every send or event change waits for a stored review.

What it is not: a graphical desktop, an autonomous shopper, a multi-user product, or a voice assistant. The roadmap lists all of those as future work, with the line “No dates or third-party API access are promised.”

Setup: sample mode in five minutes

The local sample app needs no model, no Google account and no Docker. It uses a fictional mailbox and fictional documents, which is the right way to learn the task-review loop before giving anything real credentials.

git clone https://github.com/CopilotKit/OpenMuse.git openmuse
cd openmuse
pnpm install --frozen-lockfile
cp .env.example .env
npx copilotkit@latest login
npx copilotkit@latest project select
# paste the generated server-only key into .env as CPK_INTELLIGENCE_API_KEY
pnpm dev

In a second terminal:

pnpm dev:web

The UI is at localhost:8081, the API at localhost:8787/api/health. The README’s suggested first tasks are worth doing in order: send “Complete the permission slip” in Chat and follow the task through fictional form values, a saved PDF and a prepared reply; create an availability watch in Goals → Track; then Menu → Delegate task → Finance with the example transactions.

Note the two npx copilotkit lines. Even in sample mode, OpenMuse will not open a chat thread without a CopilotKit Intelligence project key. More on that below.

Turning on a real model and the browser

The .env.example is well commented. The minimum for real delegated work:

AGENT_BACKEND=model
MODEL=anthropic/claude-sonnet-4-5     # or openai/gpt-5, google/...
ANTHROPIC_API_KEY=sk-ant-...

# Browser worker
BROWSER_WORKER_URL=http://127.0.0.1:8790
WORKER_TOKEN=<random, 32+ chars, identical on API and worker>

Then install Chromium and start the worker:

pnpm --dir apps/worker exec playwright install chromium
pnpm dev:browser

Or run it in Docker with the bundled compose file:

docker compose --env-file .env -f infra/compose.yaml up --build -d

Now “Check out Hacker News for cool stuff” or “Summarize copilotkit.ai” will stream browse_web tool calls into the chat as cards with a real page preview, and Take control opens the same Chromium session. For an OpenAI-compatible gateway (LiteLLM, OpenRouter) set OPENAI_BASE_URL and MODEL=openai/vendor/model.

The Linux computer

docker build -t openmuse-computer:local apps/computer
COMPUTER_ENABLED=true pnpm dev

Open Computer → Terminal → Start computer and run python3 --version. On macOS, docs/COMPUTER.md recommends a dedicated Colima VM (colima start openmuse --cpus 2 --memory 3 ...) selected with DOCKER_CONTEXT=colima-openmuse, so OpenMuse never touches your main Docker context.

Two constraints matter in practice. The terminal is not an interactive PTY: no vim, no npm init prompts, nothing that waits on a keystroke. And terminal networking is disabled by design; the only way out to the web is the browser worker. That is a sane security choice for an agent that reads untrusted email, but it means “clone this repo and run the tests” is not a task OpenMuse can do today.

Live Gmail and Calendar

Set WORKSPACE_MODE=live, an OPENMUSE_ACCESS_KEY of 24+ characters, a base64 TOKEN_ENCRYPTION_KEY of 32 random bytes, and a Google OAuth web client with ${PUBLIC_API_URL}/api/google/callback as the redirect URI. Then connect read access under Apps → Gmail and grant write access separately. Credentials are encrypted at rest; every send and every calendar change still requires its own stored review.

Deploying to Render

The repo ships a render.yaml and a Deploy-to-Render button. It creates three services:

ServicePlanRuns
openmuse-apiStandard, 1 GB disk at /var/dataHono API + in-process task worker
openmuse-webStatic siteExpo web export, EXPO_PUBLIC_API_URL baked in at build
openmuse-browserPrivate service, Standard, 1 GB diskPlaywright + Chromium, reachable only on the private network

You supply CPK_INTELLIGENCE_API_KEY and OPENAI_API_KEY; Render generates OPENMUSE_ACCESS_KEY (your login) and TOKEN_ENCRYPTION_KEY. Two gotchas from the README: Standard is the smallest plan that boots, because at 512 MB the process runs out of memory loading PGlite’s embedded Postgres before it binds a port; and a redeploy without the disk wipes the database, PDFs and signing key. The Blueprint does not start the Docker computer or Google connectors.

Community reaction

OpenMuse did not get a Hacker News thread of its own. The attention came from X, LinkedIn and newsletters: CopilotKit’s launch post framed it as “an open source personal assistant that works with ANY agent harness,” AlphaSignal covered it as “a self-hosted personal agent with its own browser,” and ScriptByAI used the headline most people will search for, “open-source Meta Muse alternative.” The stars (3.5K in two weeks) say the positioning landed.

The context is the Meta Muse backlash. The Muse launch thread reached 666 points with the top comment “I really don’t want to share all my personal life information with Meta like this,” and a second thread (163 points) on a journalist’s claim that Muse read his iMessages produced the line that doubles as OpenMuse’s thesis: “Agent sandboxing/access control is one of the biggest problems to be solved before this technology really should go mainstream.”

The more useful signal is in the pull-request queue, which is where self-hosters are telling CopilotKit what they actually want:

  • PR #94 (2026-09-30): “run chat fully offline with CopilotKit Intelligence optional.” It adds a local mode that persists threads with a DurableAgentRunner and in-process SSE when no Intelligence key or URL is set. This is the PR to watch; if it merges, the biggest caveat in this review goes away.
  • PR #93: switches the model adapter from the Responses API to Chat Completions because multi-turn tool loops break on LiteLLM-fronted Vertex and Groq models (“Turn 1 streams fine; the tool-result follow-up turn dies”).
  • PR #88: bring-your-own MCP server from Apps → MCP connections, with per-tool enablement and read-only defaults. Today, adding an integration means editing code.
  • PR #84: optional Parallel web search for chat and tasks.

Of the 58 open items on 2026-10-01, almost all are PRs, not issues, and a cluster of perf(server) ones suggest early self-hosters are already paying for the “load the whole workspace snapshot” pattern.

Honest limitations

  1. The Intelligence dependency. “Every deployment requires CPK_INTELLIGENCE_API_KEY,” and the README is explicit that Intelligence “is a separate service and is not included in this repository’s MIT license.” Your conversation history lives in CopilotKit’s cloud. For a project whose headline is privacy-respecting self-hosting, that is a real contradiction until PR #94 or equivalent lands.
  2. Alpha means alpha. VERIFICATION.md lists 154 passing tests, real Chromium and Docker smoke tests, and iPhone captures, but it also says live-model quality, real Google accounts, Rich Threads replay, Android devices and the OpenBot bridge are all “pending.” The demos run a scripted “AI Mock” model.
  3. Single owner. One deployment, one person, one shared access key. There is no multi-user auth, retention controls, or export; the roadmap puts “deployment hardening” in the future column.
  4. No autonomous checkout, no interactive sites. The browser reads public pages and hands interactive work back to you. Reservations, purchases and customer-service flows are roadmap items. Meta Muse checks out through Link by Stripe; OpenMuse stops at the cart.
  5. No OCR, limited forms. PDF filling works on supported AcroForms only; scanned documents are not handled.
  6. Resource footprint. PGlite alone needs more than 512 MB; with a Chromium worker and a Docker computer you are running three services with persistent disks.
  7. Name collision. There is a separate diggerhq/openmuse that posted a Show HN with the same “open-source alternative to Meta’s personal agent” tagline. Make sure you are cloning CopilotKit/openmuse.

OpenMuse vs the alternatives

OpenMuseMeta MuseOpenBotOpenClaw
LicenceMIT (+ hosted Intelligence)ProprietaryMITMIT
HostingYour server / RenderMeta Secure VMYour serverYour server
TargetOne person, phone-firstConsumers, US onlyTeams of agents, governanceDevelopers, automation
BrowserPersistent Chromium, takeoverOwn browserChromium per agentManaged Chrome profile
TerminalNonroot Linux, no networkNoShell per agentHost or sandbox exec
Email/CalendarGmail + Calendar, reviewedMany connectorsVia MCPVia skills/MCP
CheckoutNoLink by StripeNoNo
PriceFree + model tokensFree; $20 / $100 tiersFree + tokensFree + tokens

If you are choosing between the three open options: OpenBot is for several agents behind a policy gateway, OpenClaw is a developer harness you talk to over Discord or Telegram, and OpenMuse is the only one that ships a native phone app with mail, documents and goals as first-class objects. For a wider look at the commercial field, see best AI personal agents 2026.

Should you use it?

Yes, as a template, if you want to build a personal agent product and would rather start from a working Expo app, durable task engine and sandboxed browser than from a blank file. The security boundaries are thought through, and the verification doc is unusually honest about what has not been tested.

Not yet, as a daily driver, if what you want is “Meta Muse but private.” The Intelligence key sends your threads to CopilotKit, the Google connectors have not been accepted on real accounts, and the agent cannot finish a purchase or reach the network from the terminal. Check back when PR #94 merges and the roadmap’s “Integration acceptance” boxes start getting ticked.

FAQ

Is OpenMuse really open source if it needs a CopilotKit key?

The repository is MIT licensed and you can read, modify and redistribute all of it. But CopilotKit Intelligence, the hosted service that stores and replays conversation threads, is required in every mode and is not part of that licence. A community pull request (#94) adds a fully local mode; until it merges, treat OpenMuse as open-source software with a proprietary dependency.

Can OpenMuse use Claude or a local model instead of GPT-5?

Yes. Set AGENT_BACKEND=model and MODEL=anthropic/claude-... with ANTHROPIC_API_KEY, or a Google model with GOOGLE_API_KEY. For Ollama, LiteLLM, OpenRouter or any OpenAI-compatible endpoint, set OPENAI_BASE_URL and MODEL=openai/vendor/model. Note PR #93’s report that multi-turn tool calls can fail through some gateways with the default Responses adapter.

Does OpenMuse need Docker?

Not for the basics. Chat, tasks, documents, Gmail and the browser worker run with Node and pnpm alone (the browser needs a Playwright Chromium install). Docker is only required for the optional Linux terminal and file workspace, and for the compose-based browser worker.

Can OpenMuse buy things for me like Meta Muse?

No. The browser worker reads public pages, takes screenshots and imports PDF downloads; when a site needs a login, a captcha or a payment, OpenMuse hands you the live session with “Take control.” Autonomous reservations and purchases are on the roadmap with no date.

How does OpenMuse keep the agent from doing damage?

Three layers. Every email send and calendar change goes through a stored review you approve in the app. The browser runs in a separate token-protected worker with its own profiles and no access to your host. The optional terminal runs as a nonroot user in a read-only container with no network, no host mounts and none of your API keys; commands are capped at 30 seconds and every result is saved as a receipt.

Sources