Meta Muse Code and Muse Spark 1.2: Developer Guide

Meta released two tightly coupled products on August 5, 2026: Muse Code, a beta terminal coding agent, and Muse Spark 1.2, the coding-focused model that powers it. The important idea is not another chat interface. Meta is pairing a model trained for long software trajectories with a restart-safe harness whose background agents persist for an entire session.

That architecture targets the expensive middle of repository work: building a plan, preserving discoveries, making coordinated changes, surviving interruptions, and proving the result. It also creates new review obligations. Persistent agents can carry useful context for longer, but they can also preserve a bad assumption for longer.

What Meta launched

Muse Code accepts repository-scale engineering tasks and is designed to plan, edit and validate across multiple files. Meta's launch materials emphasize four pieces:

1. a simple main-agent loop;
2. specialized asynchronous agents that remain available during the session;
3. an append-only local event log for calls, tools, approvals and edits; and
4. built-in workflows for planning, challenging a plan and pursuing a completion goal.

Meta labels Muse Code a beta. That word matters: its process model is documented, but operational details such as stable versioning, enterprise controls, usage limits and support commitments may change.

How Muse Code works

Persistent background agents

Many coding harnesses spawn a child for one narrow task, collect an answer and discard that context. Meta describes a different default. Muse Code's specialized background agents remain active throughout a session, carry out next steps, and decide when to communicate with the main agent.

The potential benefit is less repeated discovery. An agent that has already mapped the test layout or traced an API boundary need not start from zero for every follow-up. Persistence also allows the main agent to continue while research or validation runs asynchronously.

The trade-off is coordination state. A persistent worker can become stale after the main branch changes, race another worker for the same file, or retain an interpretation that later evidence disproves. A useful evaluation therefore records:

• which agent owned each part of the task;
• what repository revision each agent inspected;
• whether workers shared a worktree or used isolated worktrees;
• how conflicting edits were detected;
• when the main agent invalidated stale conclusions; and
• which checks ran after integration, not merely inside a child task.

Replay-exact local event log

Meta says every model call, tool run, approval and edit is appended to a local event log. The log is the runtime's source of truth, allowing a crashed process to resume where it stopped rather than reconstructing state from a prose summary.

This is a meaningful reliability feature for long jobs. It is not the same as deterministic execution: external APIs, package registries, tests, clocks and mutable repositories can return different results on replay. Teams should verify that recovery records the environment and does not silently rerun a destructive operation.

Bundled operating skills

The launch article names three default workflows:

• /plan creates an approval-gated plan;
• /grill challenges that plan; and
• /goal continues toward an explicit completion condition.

These are useful controls only when the gates are concrete. “Tests pass” is weaker than a named command, expected exit code and changed-file review. “Deploy works” is weaker than an immutable artifact identity plus an external health check.

Why the model and harness were co-trained

Muse Spark 1.2 is a coding-focused update to Muse Spark 1.1. Meta says it increased coding training compute, expanded training-environment diversity and retained general-agent capability. More unusually, Meta says the model was co-trained with Muse Code.

Training included rejection-sampled harness trajectories and optimizations for goals, compaction and subagents. In practical terms, Meta is arguing that an agent model should learn the specific control surface it will use rather than being dropped into an arbitrary collection of tools after training.

That can improve fit, but it complicates comparisons. A result from Muse Spark 1.2 inside Muse Code measures the combined model-harness system. It does not show that the model alone would produce the same result in another scaffold, or that Muse Code would produce the same result with another model.

Meta also reports training on whole-repository generation, large projects and autoresearch. For a kernel-optimization case study, the company says the agent iterated for more than 1,000 tool calls and up to 24 hours, compiling and profiling Triton implementations for NVIDIA Hopper GPUs. This is evidence of the intended horizon, not a general guarantee that every long run converges.

How to read the benchmark claims

The public benchmark panels make one limitation visible: nearly every bar pairs a different model with a different harness. The internal panel names models but does not identify a harness.

Meta's methodology says coding and agentic benchmark comparisons use self-reported results when available, with internal evaluations used otherwise. For internally run third-party agentic evaluations, Meta uses its own common framework and cautions that its agent tools and system prompts may not be tuned to proprietary competitors. Do not turn a cross-harness chart into a model-only leaderboard.

Artificial Analysis reports a separate pre-release evaluation: an Intelligence Index of 54 and an 80% Terminal-Bench result, compared with Meta's 82.9% Muse Code system result. The harnesses and runs differ, so 80% is independent model evidence—not a failed reproduction of Meta's chart.

A stronger internal test keeps the repository, task, budget, model, permissions and verification commands fixed. Change only the harness—or only the model—then repeat enough trials to expose variance.

Install and evaluate safely

Meta publishes this installer for macOS and Linux:

curl -fsSL https://dev.meta.ai/install.sh | bash

A safer organizational process downloads and reviews the script, records its checksum, then runs it in a disposable environment. Do not pipe a remote script directly into a privileged shell on a production host.

Start with a clean, non-sensitive repository clone:

git clone https://github.com/your-org/your-repo.git muse-eval
cd muse-eval
git switch -c eval/muse-code
# Launch Muse Code only after checking the installed binary and account settings.

Keep cloud credentials, signing keys, production environment files and private datasets outside the working directory. Run the agent as an unprivileged user, restrict network access when feasible, and checkpoint before granting write permission.

Pricing, data use, and security boundaries

Muse Spark 1.2 is a hosted model, not a downloadable open-weights release. Meta's pricing page lists two API IDs with different economics and data terms:

Contributor access is paid, requires billing, and is described as available only in select countries; Meta did not publish a country list in the materials reviewed. Web grounding is billed separately at $2.50 per 1,000 searches. Teams should confirm live rates, retention rules and eligibility before sending proprietary code.

Meta's permissions documentation says Muse Code uses Seatbelt on macOS and bundled Bubblewrap on Linux. That sandbox is not universal containment: MCP tools are not sandboxed, hooks run outside the agent sandbox and approval layer, and --yolo disables both approvals and sandboxing. Do not enable that mode on a workstation with production credentials. If parallel subagents will edit files, use the documented worktree-isolation option; otherwise they share the lead workspace and may collide.

A practical evaluation workflow

Use tasks that reflect your actual engineering queue, not only polished demos.

1. Define a bounded task card

Include the goal, allowed paths, forbidden paths, named checks, time or cost budget, and completion evidence. Add one task with ambiguous requirements to test whether the agent asks rather than invents.

2. Separate planning from execution

Use /plan, inspect affected boundaries, then use /grill to probe migrations, rollback, security and test gaps. Reject plans that claim success without a reproducible gate.

3. Observe the agent topology

Record how many persistent workers run, their responsibilities, whether their findings remain accurate after edits, and whether the main agent merges evidence rather than merely concatenating reports.

4. Interrupt and recover

Stop the process during a reversible task, restart it, and inspect the event log. Confirm it does not repeat a write, approval or external side effect. Verify the repository state independently.

5. Score the artifact

Measure functional correctness, regression rate, changed-line relevance, review effort, elapsed time, tokens or billed usage, and recovery quality. A finished chat is not a finished engineering task.

Limits and open questions

• Beta stability: interfaces and behavior may change.
• System-level comparisons: the launch benchmarks mix models, harnesses and evaluation details.
• Internal benchmark opacity: one displayed coding evaluation is Meta-internal.
• Long-run cost: persistent workers and thousand-call trajectories can increase compute even when they reduce human steering.
• Permission boundary: a restart-safe agent can also restart unsafe work unless approvals and idempotency are designed carefully.
• Operational details: live product documentation should control on retention, regional eligibility and enterprise controls.

Muse Code's persistent specialists, goal workflows, compaction-aware training and replayable state make it worth a controlled evaluation. The same continuity can enlarge the blast radius of a bad instruction, so permissions and recovery tests should be part of the trial—not post-launch cleanup.

FAQ

Official sources

• Meta AI Research: Introducing Muse Code and Muse Spark 1.2 — architecture, co-training, case study, installation and availability
• AI at Meta launch thread — announcement, product examples and official benchmark media
• Muse Spark evaluation methodology — benchmark configurations and comparison caveats
• Artificial Analysis: Muse Spark 1.2 — independent pre-release model evaluation with a distinct harness
• Meta Model API pricing and rate limits — Standard and Contributor prices, quotas and data-use terms
• Muse Code permissions — platform sandboxes, approvals and --yolo warning
• Muse Code extensions — worktree isolation plus MCP and hook boundaries
• Muse Spark 1.1 evaluation report — predecessor deployment and safety context