Muse Code, Examined: What Replayable Subagents Mean for Coding Agents
On 5 August, Meta released Muse Code in beta, a terminal-based coding agent that plans and validates changes across an entire repository. The capability claims are familiar by now. The detail that matters to an engineering leader in a regulated enterprise is quieter. Each model call and file edit is written to a local event log before it executes, and if the agent crashes it resumes from that log. Meta has made the agent's working history a first-class artefact, and that changes what can be asked of a coding agent after the fact.
What Muse Code offers
Muse Code installs with one command on macOS and Linux and works from the terminal. Work begins with a plan that a developer approves, and bundled commands let the developer stress-test that plan before the agent drives the task to completion. The agent is powered by Muse Spark 1.2, a coding-focused update with a one-million-token context window.
Large jobs are split across parallel subagents, each working in its own isolated git worktree, so concurrent changes do not overwrite one another. Specialised subagents persist through a session and accumulate context instead of starting over with each task. In a launch demonstration, Mark Zuckerberg described the agent producing six features for a game at once without collisions, an anecdote worth reading as an illustration of intent.
Pricing follows the model's two tiers. The standard tier costs about USD 1.25 per million input tokens and USD 4.25 per million output tokens, with prompts excluded from training and zero data retention available on request. A much cheaper contributor tier allows Meta to train on prompts and completions.
Where the design holds
The write-ahead event log is the most useful idea in the release. When a coding agent changes a payments service, a reviewer eventually asks why a particular line changed and what the agent knew when it made the change. A log that records each model call and edit, in order, answers that question from evidence. It also turns a crash into an interruption, because the agent resumes from a known point instead of repeating work or leaving a half-applied change.
Worktree isolation is equally sound engineering. Parallel agents writing to the same branch produce conflicts that a person has to untangle, and isolating each subagent keeps every change reviewable on its own. The plan-approval step puts a human decision at the start of the work, where it costs least.
Where the load stays with the team
Parallelism multiplies output, and output has to be reviewed. Six features delivered at once are six diffs for a senior engineer to read and approve, and the time saved in generation can reappear as a queue in review. Teams adopting any parallel coding agent should measure review hours alongside lines produced, or the productivity gain will be counted twice and the cost not at all.
The event log is local to the developer's machine. That is useful for the developer and insufficient for an enterprise that needs to show an auditor how a change to a regulated system was produced. Unless the log is collected centrally and retained with the pull request, the audit surface exists in principle and disappears when a laptop is reimaged.
The contributor tier needs a policy before anyone uses it. An engineer choosing the cheaper tier for a personal experiment could send proprietary source code into a training pipeline. Enterprises should restrict Muse Code to the standard tier, with zero data retention requested, until legal has reviewed the terms. The release is also a beta, and Meta has said larger models are coming, so behaviour will change under teams that adopt it early.
Where it fits
Muse Code suits engineering teams that want a terminal-first agent for repository-wide changes and are prepared to treat its event log as part of their change record. It fits regulated codebases once two conditions are met: the log is shipped to central storage with each pull request, and the standard tier with zero data retention is the only tier permitted. It fits poorly where review capacity is already the bottleneck, because more parallel output will lengthen the queue.
The broader signal from this release is welcome. A coding agent that records its own reasoning trail before it acts gives engineering leaders something they have lacked: a way to reconstruct how a change came to exist. The question for any CTO is whether that record will be retained and reviewed, or left on a laptop. An agent whose history travels with its code is one that can deliver outcomes that survive scrutiny.
Related: Data Architecture
Tell us the number you need to move.
…outcomes that survive scrutiny.