Meta entered directly into the programming agent fray with Muse Code, released in beta on August 5, 2026. The tool runs in the terminal, uses the new Muse Spark 1.2 and was introduced for software engineering tasks that involve planning, code changes and validation in large repositories.
The launch deserves attention, but it still does not authorize a conclusion like “new rival better than Codex or Claude Code”. Part of what's interesting about Muse Code is the architecture of the agent, not just the model. And some of the advantages touted by Meta—like accomplishing difficult tasks faster, with greater precision, and less intervention—remain launch claims that need practical, independent validation.
What Meta actually released
Muse Code is a terminal programming agent, initially documented for macOS and Linux. Meta connects you directly to Muse Spark 1.2, an update to the model that targets code generation, complex debugging, understanding codebases, and end-to-end development flows. According to the company, the model and agent were trained together to work better as a system.
The most concrete elements of the announcement are:
- Asynchronous subagents persist throughout the session. Instead of creating a new worker for every small task, Muse Code keeps specialized agents active and allows them to advance parts of the work and report results to the main agent.
- Local event log. Model calls, executed tools, approvals and edits are added to a log that serves as a source of runtime state.
- Resume after failures. Meta claims that this design allows you to reconstruct the state and continue work where the agent left off after an interruption.
- Built-in job commands. /plan produces a plan subject to approval, /grill tries to find problems in that plan, and /goal works toward a defined goal.
- Training for long tasks. Muse Spark 1.2 is trained on generating complete repositories, large projects, and other long-running streams using scheduling, goal conditioning, and context compression.
There is an important distinction here: subagents are described as persistent throughout the session. The ability to survive a failure is associated with the runtime registration. Treating the two things simply as “permanent memory” would be exaggerating what the documentation claims.
Persistent logging may be more important than it seems
Programming agents who work for minutes or hours face a different problem than a chatbot that responds in a few seconds. If the process breaks after hundreds of actions, repeating all the work costs time, tokens and may produce a different result.
Muse Code attempts to address this problem structurally. Your local log is append-only: new actions are added to the history, including tool runs and edits. Meta describes this runtime as capable of reproducing state and resuming a task after a failure.
It's an interesting feature, but “restart-safe” still needs to be tested in less convenient conditions than a demonstration. A useful test should deliberately stop processes at different times: during an edit, after a failed test, while subagents work in parallel, and after context compression. What matters is not just opening the session again, but knowing whether the agent maintains previous decisions, correct files and work dependencies without repeating steps or introducing inconsistencies.
24-hour tasks are evidence, but not proof of everyday use
To demonstrate long-running work, Meta published a GPU kernel optimization experiment in which the system made more than 1,000 tool calls and was able to work for up to 24 hours. The agent wrote, compiled, averaged, and re-optimized implementations for NVIDIA Hopper GPUs.
This shows that the runtime can sustain an extensive cycle within the evaluation environment used by Meta. It does not alone demonstrate that a developer will have the same gain when migrating an application, investigating an intermittent bug or modifying a monorepo with slow tests and external dependencies.
“Long-horizon” should also not be measured only by the time that the agent continues to run. An agent can remain active for hours and still waste steps. For a serious comparison, the result needs to consider useful progress, regressions, amount of human intervention, cost, and ability to notice when a strategy has stopped working.
Launch benchmarks have a relevant caveat
Meta compared Muse Spark 1.2 to other models in assessments such as Terminal-Bench 2.1 and DeepSWE 1.1. In these tests, however, the same agent was not necessarily used for all models: Muse Spark 1.2 ran with Muse Code, Claude Opus 5 with Claude Code and a GPT model with Codex, among other combinations.
This choice measures something close to the complete product — model plus harness — but makes it more difficult to attribute the difference solely to the model. Meta itself recognizes that its environment may not be specifically tailored to third-party proprietary systems and, therefore, the results may not represent their best performance. At DeepSWE, the company also informs that its test is not identical to the official leaderboard, which uses a common harness.
This caveat should accompany any numbers-based headline.
There is already an independent signal in favor of Muse Spark 1.2 as a model: Artificial Analysis placed it close to the leading models in its intelligence assessment, highlighting cost efficiency, according to a report by Barron's. This is relevant, but does not amount to an independent assessment of Muse Code as a programming product.
Pricing also needs to be compared per task, not per token
At launch, Muse Code adopted per-use billing. For standard Muse Spark 1.2, the published price was $1.25 per million input tokens and $4.25 per million output tokens. Meta has also created a very discounted Contributor modality, which can be used to improve its products.
The number looks attractive when placed next to the API fees of more expensive models, but it still doesn't show how much it costs to to complete a task.
An agent that charges less per token can consume much more context, produce more output, perform more retries, or keep multiple subagents working simultaneously. In the opposite direction, a more expensive model may solve the problem in fewer calls. For real work, the most useful unit of comparison is something like “cost per job accepted after testing and review,” not just “price per million tokens.”
The comparison is even less direct with Codex and Claude Code because both are also offered within subscriptions. Codex is currently included in different ChatGPT plans, while Claude Code is part of Claude Pro and other eligible plans; Both also have charging or consumption mechanisms that vary depending on modality and volume.
Subagents and parallelism do not automatically make Muse Code unique
The Muse Code design reaches a market that has already moved in this direction.
OpenAI describes Codex as an environment for multi-agent flows, with agents working in parallel, integrated worktrees, and background execution. Worktrees allow independent tasks to act on isolated copies of the same repository without immediately changing the main checkout.
Claude Code also has subagents with separate contexts, parallel execution, isolation by worktrees and mechanisms for resuming sessions. Its documentation states that tool messages and results are kept locally in session files and that changes made by editing tools have checkpoints that can be restored.
So the more interesting question is not whether Muse Code “has subagents”. It's whether your combination of model, orchestration, persistence, and compression produces a measurable difference when all three products are given the same work.
What needs to be tested before a Muse Code vs. Codex vs.. Claude Code
A useful comparison should use identical repositories and tasks, criteria defined before execution, and more than one attempt when there is variability. Among the points that deserve measurement are:
- Completion rate: Does the implementation meet the specification and pass testing without human remediation?
- Regressions: How many defects or unnecessary changes appear outside the requested scope?
- Long lasting: Is the quality maintained after dozens or hundreds of actions?
- Recovery: After a forced stop, does the agent actually continue without losing decisions or repeating work?
- Parallelism: subagents reduce total time without increasing deadlocks, search duplication, or rework?
- Human intervention: how many approvals, corrections and redirections are needed to reach the accepted result?
- Cost per result: how much was spent until the task actually passed the tests?
- Time to solution: parallelism and fast models decrease the real clock or just increase concurrent activity?
- Data governance: which modality can be used with private code and what conditions change when choosing a reduced price option?
The same set should include small and large tasks. An agent that excels at a large migration may be prohibitively expensive or slow for a three-file fix; another may excel at localized changes and lose direction on multi-hour jobs.
What can we say about Muse Code today
Muse Code is not just a new interface for a model. Meta built its own harness, integrated subagents, created a recoverable runtime and trained Muse Spark 1.2 taking this environment into account. This makes the beta technically more interesting than simply placing the model behind a terminal prompt.
It's also too early to declare a winner. The claims about less intervention, greater precision and advantage in long jobs come mainly from Meta; its own methodological documents show why a straightforward reading of the benchmarks can be misleading. There is still considerable overlap between the announced capabilities and resources already existing in Codex and Claude Code.
The best reading at this point is that Meta has placed a plausible competitor in the category. The potential difference lies in the combination between Muse Spark 1.2 and Muse Code, the design for long tasks and the cost per use. Knowing whether this turns into a practical advantage requires precisely what a beta should receive now: reproducible tests on real code, measuring results, cost and the need for supervision.
