What Muse Code actually is, in sixty seconds
Meta shipped Muse Code on 5 August 2026 alongside Muse Spark 1.2, and its own docs define it in one sentence: a coding agent "for the terminal and CI, built on Muse Spark," that "plans, edits, and runs commands to do a task, with approvals and an OS sandbox on from the first run."
It is Meta's first entry in the terminal AI coding tools category, arriving well behind Claude Code, Codex and Devin.
The install is one line and the binary is a single native executable named muse:
curl -fsSL https://dev.meta.ai/install.sh | sh
muse --version
| What | Value |
|---|---|
| Binary | muse |
| Interactive launch | muse inside a project directory |
| Headless launch | muse exec "<prompt>" |
| Default model | muse-spark-1.2 |
| Context window | 1,048,576 tokens |
| Platforms | macOS and Linux (Windows is not mentioned in the docs) |
| CI auth | META_API_KEY |
| Status | Early beta, public preview |
Two structural details matter more than the install. First, Meta frames the agent and the raw API as a build-versus-buy split in its own words: "Call the API directly when you build your own agent or app. Run Muse Code when you want a ready-made coding agent." Second, trusting the workspace on first run is the gate on everything project-local. Trust it and Muse Code loads the repo's skills, rules and hooks; decline and it does not, which quietly means an untrusted checkout cannot inject instructions into your run.
The problem with every number you have seen
Here is the thing that reframed the whole launch for me. Meta published four benchmark charts, and on two of them the harness changes between the bars.
On the Terminal-Bench 2.1 and DeepSWE charts, Muse Spark 1.2 runs in Muse Code and Muse Spark 1.1 runs in mini-swe-agent. The harness names are there, printed in small grey text under each bar, so this is disclosed rather than hidden. But it means the gap on those charts is a model change and a harness change added together.
The control is sitting right there in the same post. Meta Internal Coding Bench is the one chart with no harness named under the bars, and on that chart the move is 68.3 to 70.6, a gain of 2.3, against roughly +6.7 and +6.3 on the two harness-swapped ones. Same model, a third of the improvement, as soon as the wrapper stops changing.
Meta is not hiding the mechanism either. Its own bullet says so plainly:
"Co-trained with the harness. Muse Code was in the training loop from day one, so tool calls succeed and plans execute cleanly. Crucially, we trained across multiple harnesses, so while the model is at its best in Muse Code, it still generalizes to other coding agents you already use."
That last clause is the claim I would most like to see tested, because the only hands-on report I could find from outside Meta's harness says the opposite:
"It's useless. Tried with OpenCode + OpenRouter and it couldn't complete an simple task. It stuck using grep/search tools. I think Muse Spark was so heavily RL'd on the Meta harness that it make it useless or very token inneficient to use in other harness like Opencode."
One negative report is one negative report, and I would not build a verdict on it alone. But it points the same direction as Meta's own control chart, and there is no counter-evidence: across roughly 220 comments on the launch thread there is not a single side-by-side hands-on comparison of Muse Code against Claude Code or Codex on a real repository. Anyone writing a confident "Muse Code versus X" verdict right now is working without data.
The harness-neutral read comes from Artificial Analysis, which benchmarks everything on the same rig. There, Muse Spark 1.2 sits 7th of 20 on the Intelligence Index at 56.76, at $0.3992 per task, and nothing on that board scores higher at a lower cost per task. Meta's own framing agrees, calling 1.2 "a moderate improvement over Muse Spark 1.1." The Muse Spark 1.2 breakdown has the full benchmark table, including the three benchmarks where it regressed against 1.1.
What the harness actually does
Strip the model question out and Muse Code is much more interesting, because the parts Meta built around the model are the parts nobody else ships quite this way.
Subagent fan-out with real git isolation
This is the headline engineering feature and it is fully automatic. Meta's description: "when a job is split into several different tasks, they're fanned out automatically to separate agents. The parent agent spawns a write-capable child per task, and each child gets its own git worktree, so parallel children never collide on the same files."
The isolation is on disk, not conceptual. Worktrees land under .muse/worktrees/ in detached-HEAD state, checked out from the parent's HEAD, each carrying a cleanup_policy: remove_if_clean. Children commit to their own branches so the parent reviews or merges them one at a time, and subagent_status returns the roster. In Meta's own worked example the child that fixed a bug passes the full test suite inside its worktree while the parent's branch still fails that same test, untouched.
Two honest caveats. The concurrency limit is host-derived, not a published constant, and in Meta's own demo six spawned children became four running and two queued. And Esc interrupts the turn only, it does not stop background terminals or subagents, so the panic reflex does not reach them, /stop does. If you are comparing implementations, subagent orchestration and Claude Code sub-agents cover how other agents split work, and git workflows covers the branch hygiene side.
An event log you can actually grep
Meta made auditability a launch claim rather than a footnote: "every subagent it spawns, every tool call, every steer and cancel, is observable and replayable through the event log." The implementation is unglamorous in the best way. Plain JSONL on disk, one session.jsonl per session, under a date-partitioned path:
F=~/.local/share/muse/sessions/$(date +%Y/%m/%d)/*/session.jsonl
jq -c 'select(.payload.event.kind | test("reminder")) | .payload.event' $F
Because the session is event-sourced and append-only, a crashed run replays cleanly on muse resume, rebuilding the conversation and closing the interrupted turn. The same log powers /export trajectory, muse trace inspect and reattach. There is a --no-session-log flag for muse exec if you need it, and it forfeits resume, export and reattach.
The safety rule buried in the resume docs is the sharpest sentence in the whole doc set, and it is worth quoting because it is an admission most vendors would have edited out: resume "does not de-duplicate work that was in flight," so a write_file interrupted mid-execution is recorded with an unknown outcome and the agent is told to verify actual state before retrying. That is the correct behaviour, and it is also a reminder that a replayable log is a forensic tool, not a preventive one. This is the same distinction that separates monitoring a coding agent from OpenAI Trace Grading, and it is why AI monitoring and alerting is a starting point rather than an answer.
A sandbox that fails closed
Approvals and sandboxing are both on unless you opt out, and the sandbox is OS-enforced: Seatbelt on macOS, a bundled bubblewrap helper on Linux. Writes are confined to the workspace and a temp directory, the rest of the filesystem is read-only, and .git, .muse and .agents stay read-only inside the workspace so the agent cannot rewrite its own history, configuration or memory.
Three details raise this above the usual guardrail marketing:
- It refuses rather than degrades. "Muse Code refuses to run a shell command when it can't confirm that the sandbox is active." A Linux host without a working bubblewrap fails every shell command as an environment error.
- Shell commands are reviewed stage by stage. A compound command is split into sequential stages, and if you reject the held stage, "nothing runs, not even the safe stages before it." That atomicity is a real design decision, not a default.
- Network egress defaults to per-destination approval, not "off".
--sandbox-network proxy-onlyis the default, and the first connection to a new host, port and protocol triple stops for review.
The approval modes are on-request (default), untrusted and never, selected with --approval-mode, and a separate approval judge reviews prompt-bound calls automatically unless you pass --approval-judge off. Escape hatches are honest about what they cost you: --yolo disables both layers and forces workspace trust, which means the checkout's own AGENTS.md, rules and skills become live instructions. Meta's warning is blunt: "Never use it on a workstation with access to real credentials or infrastructure."
Where the design does show its limits: there is no published rule-file format or storage path for allow and deny rules, the docs never state what happens when you decline workspace trust, process spawning is not named as a restricted category, and macOS verifies Seatbelt once at session startup rather than per command. None of that makes the model unsound, but it is the difference between a guardrail and a guarantee, which is the same gap that red teaming and adversarial testing exist to probe. Prompt-level threats sit outside all of it, which is where something like Lakera lives.
Should you actually run it?
Six situations, and the honest answer for each. Pick the one that sounds like you.
What are you actually trying to do?
This is the best case for Muse Code. The contributor tier is $0.10 in and $0.20 out, and the one first-hand value verdict on the launch thread came from exactly this profile: "rough around the edges. But combined with almost free model it's actually pretty good."
Catch: contributor is US-only at the moment, rate-limited to 100 requests per minute, and your code is training data. One developer reported being cut off without warning for "policy violations".
Not today. Artificial Analysis puts Muse Spark 1.2 7th of 20 at 56.76, and Meta itself calls 1.2 "a moderate improvement" on 1.1. Its own launch charts compared against OpenAI's mid-tier model rather than the top one, which several commenters read as telling.
Catch: the harness is still worth a look even if the model is not your pick, because the isolation and log design are ahead of the field.
This is where the product is clearly differentiated. Sandbox and approvals on from the first run, fail-closed enforcement, stage-by-stage shell review with atomic rejection, and per-destination network approval by default. muse exec plus META_API_KEY is a real CI entry point, not an afterthought.
Catch: a Linux runner without a working bubblewrap helper fails every shell command outright, so test your image before you wire it into a pipeline.
Possible, but do not assume the benchmark numbers travel. Meta says the model "still generalizes to other coding agents you already use", and it is on OpenRouter. But Meta's own harness-neutral chart shows a +2.3 gain instead of +6.7, and the one hands-on report from OpenCode was that it stalled on grep and search loops.
Catch: budget an evaluation run before you migrate anything. This is the single least-tested claim in the launch.
There is no spend cap. Not a soft one, not a hard one. The best available control is an email alert, and the payment threshold rises as you pay rather than capping anything. Five of the six agents people compare Muse Code against ship both a flat plan and some form of ceiling.
Catch: the full cost mechanics, including the three defaults that all ship expensive, are in the pricing teardown.
Standard tier only, and get the retention answer in writing. Contributor tier content "may be used to improve our products". Zero data retention is a separate commitment from not-training, and it is sales-gated rather than self-serve.
Catch: sign-in runs through Meta's consumer identity stack, which is a second procurement conversation on its own. Email login exists, but two developers hit a verification selfie prompt.
Where it is rough right now
Meta called this an early beta and the launch thread bore that out. None of these are dealbreakers on their own, and together they are a fair picture of what week-two adoption felt like.
Sign-up runs through Meta's consumer identity stack. This was the second-largest complaint cluster after pricing, and it is a procurement problem more than a technical one:
"Will someone at Meta for the love of God make it so none of this stuff goes through Facebook.com? You want customers but most corporate firewalls block social media. Also, a lot of devs do not want their work stuff tied up to their facebook account."
There is a workaround, posted in the same thread: email login on dev.meta.ai works without linking Instagram or Facebook. But two separate commenters reported a verification selfie prompt on new account creation, and for both of them it was a hard stop.
The contributor tier has geography and enforcement edges. One commenter reported being locked out mid-project:
"Pointing out for others: without warning I was restricted from using the contributor model because of "policy violations". I was working on Kaggle research and some Apple Security work at the time."
There is no spend limit. This is covered properly in the Meta Muse Code pricing teardown, but it belongs in a review because it is the thing that stopped people from finishing setup:
"Unfortunately I find this too high risk, I entered my credit card, but can not set a limit. The best I can do is get an email alert. I feel like I am one oopsie away from getting a 100 dollar bill."
Beta bugs are real but ordinary. One user reported the TUI exiting immediately with "The cursor position could not be read within a normal duration" after a successful login. That is a beta bug, not a design flaw.
Nobody at Meta has said they use it. A direct question early in the launch thread, asking whether Muse Code is being adopted internally, never got an answer from anyone claiming inside knowledge. That absence is soft evidence at best, and I would not weight it heavily, but for a tool whose pitch is "the fastest way to build a great coding agent is with the people who use it every day," it is a conspicuous silence.
The trust question, fairly stated
Roughly half the launch discussion was not about capability at all. It was about whether Meta can be believed on the paid tier, and it is a real two-sided argument rather than a pile-on.
The pricing itself drew real praise for being legible:
"What are you talking about? This is one of the most honest offers ever made by a corporation. "We'll use your data, and we'll compensate you for it." Where is the problem?"
And the strongest defence of the paid tier came from someone with no stake in Meta:
"The fact that Facebook has so much experience taking advantage of people's private data is one of the reasons I believe them when they say they won't be doing it when you pay them for that service."
The counter-position is not that the contract is bad, it is that a contract is only worth the enforcement behind it:
"However, even if they were to surprise me by being perfectly meticulous about the letter of the rules from now on, I have so little trust in them that I would expect some technicality somewhere in the language of the contract."
Two checkable facts sit under that argument. Zero data retention and "we don't train on your input" are different commitments, and Meta's launch post says it is only "beginning to accept requests" for the former, through sales. And the $20 credits handed out at the Muse Spark 1.1 launch later acquired fine print stating that content used with free credits may be used for product improvement, which was not present when the credits were issued. Both are worth knowing before a compliance review, and neither is an accusation.
Muse Code against the agents people actually compare it to
The capability comparison does not exist yet, as covered above. The commercial one does, and it is where Muse Code is most clearly the outlier. Every figure below is from the vendor's own pricing page, checked 18 August 2026.
| Agent | Flat plan | Hard spend ceiling | Headline metered rate | Free tier | Notable |
|---|---|---|---|---|---|
| Meta Muse Code | None | None | $1.25 in / $4.25 out per Mtok; contributor $0.10 / $0.20 | None | Only one shipping automatic per-subagent git worktrees |
| Claude Code | Pro $20, Max 5x $100, Max 20x $200 | Settable monthly limit | Opus 5 $5 / $25; Sonnet 5 $2 / $10 | No | Anthropic publishes an expected spend per developer |
| OpenAI Codex | Go $8, Plus $20, Pro from $100, Business $25/user-mo | Org limit hard-errors; project limit is a soft threshold | Per model | No | Two different ceiling behaviours, do not blur them |
| Gemini CLI | Bundled with Google AI plans | API Tier 1 capped at $250 | Per model | 60 req/min, 1,000 req/day | Carries a deprecation banner naming an 18 June replacement |
| Cursor | Pro $20, Pro Plus $60, Ultra $200, Teams $40/user | Yes, and it stops AI features | Per model | Limited | "When a limit is reached, AI features stop for that user until the next billing cycle" |
| OpenCode | Free, bring your own key | Whatever your provider enforces | Your provider's rate | Yes | Its own Zen rate card lists Muse Spark 1.2 at Meta's standard price |
The row that matters: five of these six ship both a flat plan and some form of ceiling, and Muse Code ships neither. Anthropic even publishes an expected monthly spend per developer. Meta publishes no equivalent sentence anywhere, which for a metered product with automatic subagent fan-out is the gap I would want closed before a team rollout.
For a wider view of the field, the agentic coding CLI guide covers the rest of the category, and GPT 5.3 Codex is the closest review to this one in spirit.
The verdict
Install it if you run agents in CI and containment is your first-order concern, or if you want a cheap agent for side projects and the contributor tier's terms do not bother you. On those two jobs Muse Code is either the best or tied for the best thing available, and the sandbox design in particular is ahead of where I expected a first release to land.
Skip it if you need a spend ceiling before you will put a card down, if your organisation cannot route developer sign-in through Meta's consumer identity stack, or if you were hoping the benchmark numbers would follow the model into a different harness. That last one is the review's actual finding: Muse Code and Muse Spark 1.2 are sold as separable and behave like a bundle. Meta says the model generalises. Its own control chart says two thirds of the gain does not.
Wait if you are evaluating for a team. It is an early beta, the contributor tier is geographically limited and enforced opaquely, and the internal-adoption question is unanswered. Those all resolve with time, and none of them are about the engineering.
I want to be clear about what I am not claiming. I have not run Muse Code against Claude Code on a real repository, and neither has anyone whose write-up I could find. Anyone telling you which one wins is telling you a preference. What is checkable is the mechanism, and the mechanism says the wrapper is where Meta put its best work.
What this actually means if you are buying AI that takes actions
Here is why a coding-agent review ended up on a support-automation blog. The design question Muse Code is answering is the same one every buyer asks me: what stops it when it is wrong?
Meta's answer is a good one for code. Confine the blast radius, gate the risky calls, and write everything down so you can reconstruct what happened. It works because a bad commit is recoverable, and a git worktree makes it more recoverable still.
That answer does not transfer cleanly to a support queue, because a wrong reply has already reached a customer by the time it lands in your log. I have watched this happen in both directions. An IT manager at a restaurant chain running draft-approval workflows on eesel put it about as plainly as it can be put when the agent emailed a report he never asked for:
"Why did you email this report? I did not ask for that. DO not email these reports."
Nothing in a log would have prevented that. An approval gate would have. And the other half of the lesson comes from a real-traffic trial eesel ran on an e-commerce inbox: the agent hit 93% triage accuracy and 100% spam detection, but agents still rewrote almost every draft, and when I broke down why, only about 5% of the rewrites were the AI being factually wrong. The rest was length, tone, and data the agent had never been connected to. The model was almost never the bottleneck. The surrounding system was, which is exactly the thing this whole review has been about.
Shopping for an AI agent that touches customers instead of code? eesel runs on your real past tickets before it replies to a single live one, so you see the exact answers it would have given and pick which ticket types it is allowed to handle on its own. Same instinct as Meta's sandbox, applied one step earlier in the chain. Try eesel free, or read how teams set confidence thresholds and human-in-the-loop review before going autonomous.
If you are earlier in that decision, build vs buy is the right frame to start from.
- The failure mode a log alone will not catch: AI hallucinations in support
- The practical tooling starting point: AI ticketing system
- The grounding step underneath all of it: knowledge base training
One more thing worth watching
Meta promised open weights for Muse Spark and has not shipped them. Alexandr Wang said "soon" on X on 10 August 2026, with no licence and no date, though the smaller Muse Glimmer 30B did ship under Apache 2.0. If the weights land, the harness-versus-model question this review is built on becomes answerable by anyone with a GPU, because you could run the same model in three harnesses and measure the difference yourself. Until then, Meta AI is asking you to take the bundle on faith.
Related reading
- Rest of the Muse family: the Muse Spark 1.2 pricing breakdown
- The wider model field, with rate cards side by side in the API cost comparison
- Agent safety in a tool that has been shipping longer: OpenAI safety best practices
- Where coding agents meet support: AI agents for customer service
Sources
Meta's own properties
- Muse Code launch post
- Muse Spark 1.2 research
- Muse Code overview docs
- Permissions and safety docs
- Interactive session docs
- Muse Spark model page
- Meta Model Cookbook
Community
Frequently Asked Questions
Is Meta Muse Code any good?
How does Muse Code compare to Claude Code?
Does Muse Code train on your code?
What is the Muse Code sandbox and is it on by default?
.git, .muse and .agents stay read-only inside the workspace so the agent cannot rewrite its own history or memory. It also fails closed. This is the strongest part of the product and it sits in the same design space as Claude Code security.Can I use Muse Spark 1.2 in another coding agent?
Does Muse Code work on Windows?
How much does Meta Muse Code cost to run?
Should support teams care about Muse Code?
Article by
Alicia Kirana Utomo
Kira is a writer at eesel AI with a Computer Science background and over a year of hands-on experience evaluating AI-powered customer service tools. She focuses on breaking down how helpdesk platforms and AI agents actually work so that support teams can make better buying decisions.
