Meta released Muse Code in beta on August 5, 2026, introducing a terminal-based coding agent intended to plan changes, write code and validate results across large software repositories.
The company’s launch announcement (https://research.meta.ai/blog/introducing-muse-code-and-muse-spark-1-2) says Muse Code runs on macOS and Linux and is powered by Muse Spark 1.2, a coding-focused update to its Muse Spark model. Muse Spark 1.2 is also available through Meta Model API.
The release adds another option for teams evaluating agentic coding tools, but its practical value will depend on more than model output. The design choices around task coordination, state recovery and human approvals are at least as important for long-running repository work.
Persistent agents support longer tasks
Muse Code uses a main agent alongside specialized background agents that remain active throughout a session. According to Meta, those agents can gather information, take next steps and decide when to report findings back to the main agent.
That persistence differs from starting a new helper for every isolated step. It may reduce repeated repository discovery during a long task, although Meta’s claims about lower latency, improved accuracy and reduced intervention have not yet been independently validated.
TechCrunch independently reported (https://techcrunch.com/2026/08/05/meta-launches-muse-code-an-ai-agent-for-large-code-bases/) that Muse Code is in beta and is being positioned for complex work across large codebases. Teams should still test whether its task decomposition fits their repository structure, review practices and development environment.
A local event log is the runtime’s source of state
Meta says Muse Code appends every model call, tool run, approval and edit to a local event log. The company describes this log as the source of truth for replaying a session and resuming work after a crash.
That architecture addresses a real operational problem: long-running agents need recoverable state if a terminal closes, a process fails or a task spans multiple work periods. The design does not, by itself, prove that generated changes are correct. Teams still need version-control boundaries, review checkpoints, tests and limits on the tools an agent may use.
Muse Code also includes bundled skills for creating an approval-gated plan, stress-testing that plan and iterating toward a defined goal. These are workflow controls, not guarantees that the resulting plan or implementation is safe.
Muse Spark 1.2 remains vendor-evaluated
Meta describes Muse Spark 1.2 as an improvement in code generation, debugging, codebase understanding and end-to-end development workflows. It says the model was trained for long-horizon tasks and co-trained with the Muse Code harness.
The announcement includes benchmark and GPU-kernel optimization results, but those results come from Meta’s own evaluations and methodology. They should not be treated as independent proof of comparative performance or production reliability.
Muse Code itself is also explicitly a beta. The supplied release material does not establish a Windows version, mature production-support expectations or enough operational evidence to recommend replacing established engineering controls.
What teams should evaluate
An initial trial should focus on a bounded, reversible repository task. Engineering teams should examine the proposed plan, inspect every diff, run the project’s own tests and confirm that approval boundaries survive restarts.
They should also review what the local event log contains, where it is stored and whether it could retain sensitive source code, prompts or tool output. Access to repositories, credentials, deployment systems and external services should remain limited to what the task actually requires.
Muse Code’s persistent-agent design is technically notable, but the beta label matters. The useful question is not whether it can produce an impressive demonstration. It is whether a team can understand, constrain, review and recover its work inside a real software-delivery process.
