Written by AI agents, curated and verified by me.
Muse Code: not the new agent, the event log
- Coding Agents
- Agentic Engineering
- Verification
- Meta
On 5 August, Meta released Muse Code, a coding agent for the terminal, powered by Muse Spark 1.2. That makes a third terminal agent from a major lab, alongside Claude Code and Codex. The launch itself is not the news. Three concrete design decisions are: a local event log that makes a run repeatable, a plan that needs approval before any work happens, and a bundled skill whose only job is to take that plan apart. My thesis: the competition is moving from the model to the harness, and that is where it is decided whether a run can be checked afterwards.
What is Muse Code?
Muse Code is a terminal agent in beta, shipped by Meta for macOS and Linux via an install script. According to the announcement it takes on complex software engineering tasks across large repositories: planning changes, writing code, validating the results. It can coordinate multiple persistent subagents to do so.
The architecture is described in deliberately plain terms: a simple agent loop plus a set of async background agents. What differs from many other implementations is their lifetime. These specialised agents stay active throughout the session instead of being spawned for individual tasks and thrown away. Meta’s reasoning is that this avoids gathering the same information over and over. The background agents carry out next steps and decide themselves when to report back to the main agent. That is said to reduce latency and the need to steer on difficult, multi-step tasks.
Why is the event log the most interesting part?
Because it turns a run into something you can read back. Muse Code keeps a local event log to which every model call, tool run, approval, and edit is appended. Meta calls it the single source of truth for the runtime and describes the consequence like this: execution is replay-exact and restart-safe, and after a crash the agent can resume precisely where it stopped. That, they say, is what lets long-running tasks survive failures.
Meta sells this as robustness. For day-to-day practice the second property matters more. A run that can be replayed exactly is a run you can inspect step by step afterwards. When an agent hands you a result after four hours, the question is rarely whether it compiles. The question is where it made an assumption you would not have made. A log that records approvals and tool calls in the same order is the basis for answering that.
Two caveats belong with it. First, Meta describes the log as runtime design, not as an audit trail. The announcement says nothing about format, retention, export, or access. Second, it is local. On your own machine that is an advantage; in a team that shares responsibility for a result, it is a file on one computer. Whether it becomes usable evidence is not decided by the announcement but by what you do with it.
What do /plan, /grill and /goal do?
Muse Code ships with several default skills. /plan turns a task into an approval-gated plan. /grill stress-tests that plan until it holds up. /goal works toward completing the specified objective.
The order is the point. The approval sits before the work, not after it, and between the two there is a step that attacks your own plan. That is an unusual place for verification. Most tools check the result: tests, diff, review. Muse Code also checks the intent before cost accrues. On runs that go for hours, that is the cheapest place for a misunderstanding to surface.
But a stress-tested plan is not a verified change. Approving a plan means you approved a plan, not the diff that comes out of it. The risk of a good upfront gate is that it feels like acceptance. It is not. Responsibility for what ends up in the repository stays with the human who started the run.
And the model?
Muse Spark 1.2 is a coding-focused update to Muse Spark 1.1, with improvements in code generation, complex debugging, codebase understanding, and end-to-end developer workflows. Meta says it significantly scaled up training compute on coding tasks and widened the diversity of training environments. Training covered long-horizon tasks, including whole-repository generation, large end-to-end projects, and auto-research.
The coupling is notable: model and agent were co-trained, using trajectories from the harness itself plus recipe work for goals, context compaction, and subagents, along with integration of the Muse Code toolset. That explains why the numbers in the announcement transfer to your setup even less well than usual. What gets measured is a pair of model and scaffolding, not a model. The announcement shows bar charts for Terminal-Bench 2.1, DeepSWE 1.1, and an internal Meta coding benchmark. The text states no figures, and I will not quote any I cannot source.
The kernel optimisation case study is more concrete. Meta had the model optimise GPU kernels over more than 1,000 tool calls and up to 24 hours, KDA and MLA on NVIDIA Hopper cards, against a provided baseline. The model was not allowed to import third-party kernel libraries and had to implement in Triton. The MLA measurement ran against a PyTorch reference at batch size 1, 64 heads, sequence length 8192, and latent dimension 512. The interesting part is less the improvement than the duration. 24 hours of autonomous work is exactly the case where a restart-safe log stops being a comfort feature.
What does this mean for your work?
First, judge a new agent not by what it can do but by what it leaves behind. The question “can I reconstruct a run after it finished?” separates tools more sharply than any leaderboard. Muse Code answers it technically with yes, and that is why this launch is more than another entry on a list.
Second, beta stays beta. Installation runs through a script piped from the network into your shell. Read it before you run it, and give the agent an environment with clear limits: its own checkout, restricted credentials, a machine you can afford to lose. An approval gate in the plan does not replace that.
Third, the pattern repeats. With Codex Remote it was human approval; with orchestration in Claude Code it was hardening the scaffolding. Muse Code starts at the same place. That is the line in agentic engineering: reliability does not live in the model, it lives in the architecture around it. An event log is one piece of that architecture, not a substitute for your verification.