Meta released Muse Spark 1.3 on September 2, available with max reasoning through Muse Code and Meta Model API. The update targets a recognizable frustration with coding agents: remembering the original assignment after a conversation gets complicated. Meta’s announcement says the model better retains detailed constraints, handles interruptions across multiple tasks, and asks for help when it gets stuck. S5 Labs has not independently tested those claims.
Our interest is the supervision cost. A developer who has to repeatedly restore a requirement, disentangle two requests, or discover that an agent reported an unfinished task as complete is still doing project coordination. A useful upgrade would reduce that burden while leaving the developer in control of decisions that matter.
What Meta says improved
Compared with Muse Spark 1.2, Meta reports approximately 20% fewer tool calls and 25% fewer tokens in comparisons by its engineers. It also claims improved prompt-injection resistance and better judgment about irreversible actions. The announcement places an open-weights release on the roadmap; this launch provides access through Meta’s products. These details come from the release post.
Readers following the August Muse Code launch will recognize the product. The question for an existing user is whether a model change makes their current tasks easier to finish and review. Fewer calls alone cannot answer that: an agent can also become cheaper by skipping a necessary check.
Read the evaluation setup before ranking the models
Meta’s evaluation methodology combines its own runs, official leaderboard results, and providers’ reported scores, selecting the highest comparable primary metric available. It cautions that its third-party configurations may not deliver those models’ best performance.
Muse Spark 1.3 uses max reasoning, while 1.2 uses xhigh. Their OSWorld 2.0 evaluations use different benchmark versions. Meta’s Terminal-Bench runs use native coding tools, while the GPT-5.6 Sol result comes from OpenAI’s model card. Those scores reflect the surrounding software as well as the model. Meta’s instruction-following index is an internal composite rather than one fixed public task set.
That limits the conclusions a buyer can draw. The methodology is useful disclosure, but a collection of scores from different setups cannot isolate how much improvement comes from the model itself. Nor does it measure the time your developer spends reviewing an acceptable change. A local comparison needs both the finished artifact and a record of the intervention required to get there.
A test that resembles a working afternoon
Our proposed evaluation would start with a bounded change in a test repository: update a settings page, preserve existing keyboard behavior, and leave an unrelated bug alone. Partway through, ask for a short explanation of another file, then revise one requirement from the original assignment. This is an illustrative test design, not a Muse Spark result.
Inspect whether the final change follows the revised requirement and still meets the earlier constraints. Record each corrective message you had to send. Review the diff and run the relevant checks yourself; a confident completion message should not count as evidence that the change works.
Keep permissions identical between runs. To test whether the agent recognizes an approval boundary, ask it to prepare a release while explicitly withholding permission to publish. A model’s willingness to pause is worth observing, but the environment should also prevent unauthorized publication. Our earlier coverage of unsanctioned agent actions examines why that separation matters.
For a team already using Muse Code, 1.3 warrants this kind of comparison. Choose it if accepted changes require less corrective work at an acceptable total cost. If the developer still has to reconstruct the assignment after every interruption, a lower token count offers little relief from the part of the job this release promises to improve.
Sources
- Introducing Muse Spark 1.3 — Meta AI Research
- Muse Spark 1.3 Evaluation Methodology — Meta AI Research