Meta Enters the Coding-Agent Race With Muse Code

How Muse Spark 1.2 compares with Codex, Claude Code, and Gemini—and why multimodal training data and expert review will decide the next frontier.

On August 5, Meta stepped into one of AI’s most consequential product races. Its new Muse Code system can inspect repositories, plan changes, edit files, call tools, run tests, and delegate work to parallel subagents. Underneath it sits Muse Spark 1.2, a coding-optimized model with a one-million-token context window.

The wording matters. Muse Code is Meta’s first public coding agent. It is not the first coding agent in the market.

Anthropic had already made terminal-native agentic development a category-defining experience with Claude Code. OpenAI launched Codex in April 2025 and subsequently expanded it across an app, command line, IDE, and cloud. Google opened Gemini CLI and developed Antigravity around agents that work across the editor, terminal, and browser. Meta is joining a game already populated by formidable systems.

But Meta has not arrived with a copy of the existing playbook. Its bet is more specific: co-train the model and the agent harness, make long-running work inspectable, and let one agent fan out into isolated workers without disturbing the developer’s working copy.

That makes the launch bigger than another leaderboard entry. It is a useful preview of where coding agents are heading—and of the data problem every frontier lab now has to solve.

Meta built a model and an agent as one system

Launch coverage often collapses a model and an agent into the same thing. They are not interchangeable.

A model produces predictions from context. An agent turns those predictions into a working process: it decides what to inspect, calls tools, edits files, runs tests, preserves state, asks for approval, and revises its plan when evidence changes.

Muse Spark 1.2 is the model. Muse Code is the execution environment around it.

According to Meta’s launch announcement, Spark 1.2 was trained for long-horizon work with planning, goal conditioning, context compaction, and asynchronous tool use. Muse Code exposes those capabilities through a terminal agent on macOS and Linux. It can launch child agents in isolated Git worktrees, keep the main working copy untouched, and maintain a local, append-only event log of model calls, tools, approvals, and edits.

That event log may prove to be the most important feature in the release.

When an agent works for minutes—or hours—the final patch is not enough to understand its behavior. A reviewer needs to know which files it inspected, which hypothesis it formed, what failed, why it changed direction, which tools ran, and where human approval entered the loop. Meta describes Muse Code’s event history as replayable and restart-safe, with work resumable after interruption.

Muse Code also ships with explicit operating modes rather than hiding every behavior behind one prompt. Bundled skills include planning, code critique, documentation-grounded review, and taste-oriented interface evaluation. A persistent goal system helps the agent keep longer tasks aligned after context compression.

The result is less like autocomplete and more like an observable software worker.

The important distinction: a capable coding model can propose code. A dependable coding agent must manage tools, state, verification, permissions, and recovery around that model.

A launch-day benchmark is a snapshot, not a verdict

Meta’s published results put Muse Code in the competitive tier immediately. The company reports an 82.9 score on Terminal-Bench 2.1 and 59.3 on DeepSWE 1.1 for the Spark 1.2–Muse Code pairing.

The most useful reading is not “Meta won” or “Meta lost.” The two benchmarks show different strength profiles.

Original benchmark charts: Meta’s Muse Code launch report, August 5, 2026. Meta labels maximum or high reasoning effort where applicable. Results combine models with different agent harnesses and are not an independent evaluation.

Terminal-Bench emphasizes tasks completed through a terminal environment. DeepSWE focuses more heavily on sustained work across a repository. Muse Code edging the Codex pairing on the first while trailing it on the second is exactly why a single score should not become a purchasing decision.

The harness changes the result. So do the available tools, retry policy, context-management strategy, sandbox, reasoning budget, and test environment. A model benchmark cannot isolate all of them, while an agent benchmark intentionally measures many of them together.

And neither score answers the questions that determine production value:

• How often does the patch survive expert review?
• How much reviewer time does it save after corrections?
• Does it recognize ambiguous requirements before editing?
• Can it work safely inside a restricted environment?
• What does a successful task cost in time and tokens?
• Does the agent leave the repository easier—or harder—to maintain?

Benchmarks are an entry ticket. Trust is earned in the review queue.

Muse Code, Codex, Claude Code, and Gemini are making different bets

The leading coding agents increasingly share a baseline: repository search, file editing, terminal commands, test execution, tool calling, and some form of parallel work. Their differences emerge in product shape and operating philosophy.

Meta’s strongest strategic idea is the co-design of model and harness. Its research overview says Spark 1.2 was trained with rejection-sampled agent trajectories and learned around the same primitives Muse Code uses: goals, subagents, context compaction, and tool execution. The agent is not simply a generic wrapper placed around a coding model after training.

OpenAI’s advantage is breadth of surface and orchestration. The Codex app treats agents as parallel workstreams: each task can run in a separate thread and worktree, while the developer reviews changes or hands them back to an editor. Skills and automations extend the agent beyond an interactive terminal session.

Anthropic’s public work emphasizes the human–agent partnership. In a study of roughly 400,000 Claude Code sessions, Anthropic found that people made most planning decisions while Claude made most execution decisions. More experienced developers tended to achieve better outcomes. That finding cuts through the replacement narrative: expert judgment remains a force multiplier, even when the agent performs most of the mechanical work. Anthropic also describes filesystem and network isolation as a way to reduce permission fatigue without removing boundaries.

Google’s angle is extensibility plus multimodality. Gemini CLI is open source, connects to tools through MCP, supports extensions and scripting, and can ground work in Google Search. Antigravity extends the operating surface into the browser, which matters when a coding task includes a visual product behavior rather than a text-only specification.

The competitive question is no longer which agent can edit a file. It is which system can preserve intent across a large task, gather the right evidence, recover from failure, and produce a result that a human can verify efficiently.

What the benchmark misses: software work is already multimodal

A repository is mostly text, but a software task rarely is.

A front-end bug may arrive as a screen recording. A design requirement may be a screenshot with a marked spacing error. An accessibility regression can be exposed by a visual state and a browser trace. A robotics or video application may require the agent to understand source footage before it writes a single line of code. Build output, terminal logs, stack traces, test reports, diagrams, and human comments all provide different kinds of evidence.

Meta demonstrates this directly. In one Muse example, the input is a fly-through video of a home; the agent interprets the footage and builds a marketing and booking website around the property. Whether or not that demo resembles a typical enterprise ticket, it exposes the direction clearly: the coding agent’s input is becoming a multimodal task package, not merely a prompt followed by a repository.

Multimodality changes both training and evaluation. A model can produce syntactically correct code and still fail the actual job because it misunderstood the visual target. A patch can pass unit tests and still introduce a layout defect visible on a narrow screen. A generated site can look plausible while misrepresenting the source video.

The training unit therefore needs to preserve more than a final answer. A high-value coding-agent record can include:

1. Intent: issue text, acceptance criteria, policy, and relevant documentation.
2. Working context: repository snapshot, selected files, dependencies, and environment details.
3. Visual or temporal evidence: screenshot, design frame, screen recording, product video, or image sequence.
4. Agent trajectory: plans, tool calls, searches, intermediate edits, errors, and recoveries.
5. Verification: tests, CI output, browser checks, visual comparisons, and security scans.
6. Human review: accepted or rejected, requested changes, severity, rationale, and final resolution.

Not every task needs every modality. The point is to keep the evidence that explains success or failure—and to keep it linked.

This is the same parent-unit problem explored in Building Multimodal Datasets for AI: related evidence becomes useful when a stable task or case identity keeps every modality, review decision, and release record connected.

Model review is not the last step; it is training data

Coding-agent evaluation often stops at a binary result: the test passed or it failed. That is convenient, but shallow.

A passing test can conceal brittle architecture, incomplete edge-case coverage, an inaccessible interface, or a security shortcut. A failed attempt can contain a valuable partial diagnosis. A reviewer’s correction can identify the exact difference between code that merely runs and code that belongs in the product.

That reviewer signal should be structured.

The operating pattern is covered in Annotation Quality Operations: a correction becomes valuable when it changes the next instruction, workflow, model decision, or release gate—not when it remains an isolated comment.

Consider the difference between two labels:

• rejected
• rejected → requirement misunderstood → mobile navigation state omitted → major severity → corrected after visual review

The second record can train a reward model, improve an evaluation set, route future tasks to the right specialist, or reveal a recurring weakness in the agent. It converts judgment into reusable evidence.

A practical coding-agent ontology might begin like this:

Coding task
├── Primary intent
│   ├── Bug fix
│   ├── Feature implementation
│   ├── Refactor
│   └── Test or documentation
├── Outcome
│   ├── Accepted
│   ├── Accepted with changes
│   └── Rejected
│       └── Failure mode
│           ├── Requirement misunderstood
│           ├── Incorrect implementation
│           ├── Incomplete verification
│           ├── Security or privacy risk
│           └── Visual mismatch
├── Evidence used
│   ├── Code and documentation
│   ├── Screenshot or design
│   ├── Video or interaction trace
│   └── Test or CI output
└── Review
    ├── Severity
    ├── Reviewer rationale
    └── Corrective action

The hierarchy matters because later questions depend on earlier answers. Failure mode is relevant when the outcome is rejected. A visual-mismatch branch can request the affected viewport, component, and reference image. A security branch can require risk category and reviewer sign-off. The annotation interface stays focused because irrelevant fields remain hidden.

For the underlying schema-design method, see Annotation Ontologies: Why They Matter and How to Build Them in Unitlab, including class properties, item properties, required fields, dynamic values, and conditional branches.

The durable data advantage is not raw code volume. It is the linked record of intent, evidence, agent behavior, verification, reviewer judgment, and final outcome.

Preparing multimodal training datasets for frontier coding agents

This is where Unitlab AI fits into the frontier-model workflow.

Unitlab AI is an enterprise multimodal data platform for AI teams to curate, annotate, manage, version, and prepare training data at scale. For coding-agent research, the useful abstraction is not “a folder of screenshots” or “a table of patches.” It is a governed set of multimodal task records that remain traceable from raw evidence to reviewed release.

Here is one practical flow.

1. Curate the evidence in Data Space

In a data curation workflow, stage repository-derived text or JSON, issue descriptions, screenshots, screen recordings, logs, test reports, and reviewer artifacts as Assets. Search, metadata, filters, tags, folders, duplicate inspection, and embedding views help the team find incomplete tasks, repeated failure patterns, and outliers before annotation begins.

Stable identifiers matter. A task_id can connect task-1842.md, task-1842-before.png, task-1842-session.mp4, task-1842-ci.json, and task-1842-review.txt without flattening them into one file.

2. Group each task into one multimodal work item

Unitlab’s auto-grouping rules can group related files by filename pattern. A Custom Layout can then place the issue, visual reference, execution recording, and review evidence into one annotation experience.

This prevents a common data failure: a reviewer labels the patch while the screenshot that defines correctness sits somewhere else. Grouping preserves the context needed for a defensible decision.

3. Version the selected cohort before labeling

Dataset management begins with a clear boundary between working data and reproducible data. A Unitlab Dataset is a mutable working collection until it is published. Publishing creates an immutable DatasetVersion. A project attaches to an exact version rather than silently following later edits.

For evaluation work, that distinction is essential. If Muse Code, Codex, and Claude Code are compared on “the same dataset,” the underlying task set must actually be the same—not a collection that changed between runs.

4. Apply a conditional ontology in one shared workbench

In Unitlab’s multimodal data annotation workspace, projects are typeless: text, image, video, audio, document, and medical resources can coexist in the same project, with the appropriate editor selected for each item. The ontology can include task classes, item-level judgments, required properties, nested conditional properties, and relations.

Teams can define the reusable schema centrally on the Ontologies page or add classes, class properties, item properties, and relations directly while working in the annotation tool. Unlimited conditional depth supports detailed review without presenting every field for every task.

For a screen recording, dynamic properties can record a state that changes across frames—for example, navigation visible, layout stable, or error present. Static item properties can capture the overall outcome, while temporal labels preserve when the defect appeared.

5. Put model proposals and human judgment in one workflow

A Model → Annotate → Review workflow lets a model propose labels, an annotator correct them, and a specialist reviewer approve or reject the result. Rejection is a route back to rework, not a dead end. Instructions, comments, issues, review history, and notifications keep the decision legible.

The operational metric should not be raw labels per hour. It should be accepted, usable task records per hour after correction. That aligns throughput with downstream training value.

6. Release a reproducible training or evaluation snapshot

After review, a Unitlab Release packages a versioned annotation snapshot with preserved ontology and source context. Teams can assign train, validation, and test splits, then export a standard bundle or a task-family format.

The release becomes the handoff point for supervised fine-tuning, preference learning, reward modeling, failure analysis, or internal agent evaluation. When a result changes, the team can identify which data version, ontology, workflow, and review decision produced it.

What frontier teams should measure next

Muse Code’s launch makes the agent race more competitive, but it also makes simplistic evaluation harder to defend. Frontier teams need scorecards that combine capability with the cost of making outputs trustworthy.

At minimum, measure:

• Accepted-task rate: the share of tasks approved after expert review.
• Correction burden: reviewer minutes and edit distance between the agent patch and the accepted patch.
• Requirement fidelity: whether the implementation satisfies textual and visual acceptance criteria.
• Recovery quality: whether the agent uses failures to revise its plan productively.
• Verification coverage: which tests, browser checks, and security checks actually ran.
• Regression rate: failures discovered after the task was accepted.
• Evidence completeness: whether the decision can be reconstructed from the retained record.
• Cost per accepted task: tokens, compute, elapsed time, and human review—not cost per generated token alone.

These metrics do more than rank agents. They identify which training examples deserve higher weight, which failure modes need new data, and where automated graders disagree with experts.

The next frontier is an evidence race

Meta’s entrance matters because it validates the coding agent as a strategic layer, not a side feature. Muse Code combines a strong new model with isolated subagents, persistent goals, replayable history, and a training strategy shaped around the agent itself. Its launch benchmarks show immediate competitiveness, especially in terminal work, while also showing that the field has no universal winner.

Codex brings broad orchestration across app, CLI, IDE, and cloud. Claude Code demonstrates how much expert planning and review still matter. Gemini pushes open, extensible, multimodal agent workflows. Muse Code adds a serious co-trained model-and-harness contender.

The next advance will not come from code alone.

It will come from systems that can learn from requirements, repositories, screenshots, video, tool traces, tests, failures, and expert decisions as one connected record. The labs that curate that evidence well will build agents that are not only more capable, but more reviewable, reproducible, and trustworthy.

Preparing multimodal data for frontier-model training or agent evaluation? Explore Unitlab AI to curate, annotate, review, version, and release the evidence behind dependable AI systems.

Sources and methodology

Product details and benchmark values were checked against Meta’s Muse Code launch post and research overview. Product comparisons use first-party material from OpenAI, Anthropic, and Google. Benchmark numbers are reported as Meta published them and should be interpreted as a launch snapshot, not an independent cross-vendor verdict.