This guide breaks down what Muse Code and Muse Spark 1.2 are, how they work together, and why their design choices matter for anyone following the direction of AI assisted software development. The details below are based on Meta's official announcement, so readers who want to go straight to the source can reference it directly.
1. What Is Muse Code?
Muse Code is a terminal based coding agent released in beta by Meta. It is designed to take on complex software engineering tasks across large repositories, including planning changes, writing code, and validating the results before handing them back to a developer.
Instead of working as a single model responding to one prompt at a time, Muse Code coordinates multiple persistent subagents for each task. This structure allows it to solve harder problems with more accuracy and less manual intervention from the person running it. It installs directly through the terminal on macOS and Linux, positioning it as a tool built for developers who already work in command line environments.
2. What Is Muse Spark 1.2?
Muse Spark 1.2 is the model that powers Muse Code. It is a coding focused update to the earlier Muse Spark 1.1, with specific improvements in code generation, complex debugging, codebase understanding, and end to end developer workflows. Readers who want the full breakdown of the previous version can check out our dedicated Muse Spark 1.1 article for more context on what changed between releases.
Meta describes this release as one step toward larger and more capable models, suggesting Muse Spark 1.2 is part of an ongoing roadmap rather than a final destination. The model was built with a clear goal: perform well as a general purpose agent while excelling specifically at coding tasks when paired with Muse Code.
3. How Does Muse Code Work?
Understanding Muse Code means looking at three core design choices: its use of background agents, its event based runtime, and the skills it ships with by default.
3.1 What Are Async Background Agents?
Muse Code runs on a simple agent loop, but it is supported by a set of async background agents that remain active for the entire session rather than being created and discarded for individual tasks. This is an important distinction. Agents that spin up fresh for each subtask often repeat work, such as re-reading files or re-gathering context that a persistent agent would already have.
Because Muse Code's background agents stay active throughout a session, they can carry out next steps independently and decide when to report back to the main agent. This reduces latency and cuts down on how much steering a developer needs to provide during long, multi-step tasks. The three named background agents in this release are:
- Photon Sphere
- Embervault
- Avo Lawn
3.2 Why Does Muse Code Use an Event Log for Its Runtime?
Muse Code records every model call, tool run, approval, and edit in a local event log. This log acts as a single source of truth for the entire session, which makes the runtime replay exact and restart safe.
In practical terms, this means that if the system crashes partway through a task, the agent can resume exactly where it left off instead of starting over. For long running coding tasks that may take hours to complete, this kind of reliability is not a minor feature. It is what allows an agent to be trusted with extended, unsupervised work.
3.3 What Skills Come Built Into Muse Code?
Muse Code ships with several default skills that shape how it approaches a task:
- /plan turns a request into an approval gated plan, so a developer can review the intended approach before any code is written.
- /grill stress tests that plan, checking it for weaknesses before execution begins.
- /goal keeps the agent working toward a specified objective across multiple steps.
One example shared by Meta shows a user feeding a home walkthrough video into the terminal as an mp4 file, with Muse Code interpreting the footage and building a visually rich vacation rental marketing and booking page from it. This illustrates that the tool's use cases extend beyond traditional backend or application coding into more creative, content driven development work.
4. What Makes Muse Spark 1.2 Different From Muse Spark 1.1?
Muse Spark 1.2 was not built as a general update. It was shaped around three specific priorities: tighter integration with Muse Code, stronger performance on long horizon tasks, and a self-improvement process that sharpened its instruction following.
4.1 How Was Muse Spark 1.2 Co-Trained With Muse Code?
Meta trained Muse Spark 1.2 alongside Muse Code specifically to ensure the two perform well when paired together. This co-training process included rejection sampled harness trajectories and recipe optimizations covering goals, context compaction, and subagent coordination.
The Muse Code toolset itself was integrated directly into training, which helped maximize compatibility between the model and the harness it would eventually run inside. This is a meaningful detail for anyone evaluating agentic coding tools, since a model trained in isolation from its harness often performs differently than one trained alongside it.
4.2 How Does Muse Spark 1.2 Handle Long Horizon Coding Tasks?
Long horizon tasks, such as generating an entire repository, working through a large end to end project, or running auto research, require more than raw coding ability. They require the model to maintain direction and retain relevant context over extended periods.
Muse Spark 1.2 was extensively trained on these kinds of tasks. It relies on planning to sequence its work, goal conditioning to stay on track, and context compaction to retain the knowledge it needs without becoming overwhelmed by accumulated information. Together, these mechanisms are what allow the model to sustain progress rather than losing coherence partway through a long task.
4.3 What Role Did Self-Improvement Play in Training Muse Spark 1.2?
Meta used Muse Spark 1.1 to generate challenging coding environments and instruction following templates, then had that same model grade candidate solutions based on how well they satisfied the stated requirements. This created a scalable training dataset without relying solely on human labeling.
The result of this self-improvement loop is that Muse Spark 1.2 follows complex, multi-part instructions more precisely than its predecessor. This kind of self-generated training data is becoming an increasingly common technique across the industry as models are used to help train the next generation of models.
5. How Was Muse Spark 1.2 Benchmarked?
Muse Spark 1.2's performance was measured across several evaluations:
- Terminal Bench 2.1
- DeepSWE 1.1
- Meta's internal coding benchmark
These benchmarks assess coding ability and general agent performance separately, which reflects Meta's stated intent to keep both strengths intact rather than trading one for the other.
Reported results show gains in coding specific tasks while maintaining the model's general agent capabilities, aligning with the broader industry trend of building coding models that do not sacrifice reasoning or tool use skills in the process.
6. Case Study: How Did Muse Spark 1.2 Perform on Kernel Optimization?
One of the more demanding tests Meta ran involved GPU kernel optimization, a task that requires sustained, iterative work rather than a single correct answer. The model was tasked with writing, compiling, profiling, and progressively improving kernel performance over more than 1,000 tool calls, in sessions running up to 24 hours.
The benchmark focused on KDA and MLA kernels for NVIDIA Hopper GPUs. Models were not permitted to import third party kernel libraries directly. Instead, they had to apply specialized optimization knowledge to implement the algorithm in Triton from the ground up, rather than simply wrapping an existing solution.
Muse Spark 1.2 paired a chunk parallel preparation kernel with a sequential inter-chunk scan, combining standard fusion and tiling techniques with more specific optimizations, such as re-centering the gated cumulative decay at the chunk midpoint. Over the course of the test, the agent continued to show substantial improvements over the provided baseline, demonstrating sustained reasoning rather than a single burst of early progress.
7. Why Do Persistent Agents and Event Logs Matter for the Future of Coding Tools?
The design choices behind Muse Code point to a broader shift happening across agentic coding tools in 2026. Persistent background agents reduce redundant work and lower the amount of oversight a task requires. Event based runtimes make long sessions resilient to failure instead of fragile. Self-improvement loops reduce the industry's dependence on purely human generated training data.
None of these ideas are unique to Meta, but Muse Code and Muse Spark 1.2 offer a clear, documented example of how they can be combined into a single working system. For teams evaluating agentic coding tools, these are the kinds of architectural details worth examining beyond raw benchmark scores, since they directly affect reliability on real, messy, long running work.
It is also worth noting why this matters beyond convenience. A coding agent that loses context mid-task, or that has to restart from scratch after a crash, becomes difficult to trust with anything beyond short, well defined jobs. By treating reliability and memory as core design problems rather than afterthoughts, Meta's approach signals that the next phase of agentic coding tools will be judged as much on how gracefully they handle failure and long duration work as on how well they perform on a single coding benchmark.
8. Who Should Pay Attention to This Release?
Developers working on large, established codebases stand to benefit most from tools built around long horizon reliability, since those are the environments where multi-step planning and context retention matter most. Teams experimenting with agentic workflows, where a model needs to complete a task with minimal supervision, will also find the background agent and event log design relevant to evaluate, even if they end up using a different tool.
Engineering leaders tracking the direction of AI assisted development may find this release useful less as a product announcement and more as a signal of where investment and research attention are heading across the industry in 2026.
9. How Can Developers Access Muse Code and Muse Spark 1.2?
Muse Spark 1.2 is available now inside Muse Code and through the Meta Model API, with expanded global access compared to earlier releases. Muse Code itself can be installed directly on macOS or Linux through a terminal command, making it accessible to developers already comfortable working outside a traditional IDE.
Meta has indicated that additional harness features and more capable models are planned, suggesting this release is an early step in a longer roadmap rather than a finished product.
10. Final Thoughts
Muse Code and Muse Spark 1.2 reflect where agentic coding tools are heading: systems built to plan ahead, persist through long sessions, recover from failure without losing progress, and improve themselves using their own generated training data. Whether or not a given team adopts this specific tool, the underlying architecture offers a useful reference point for evaluating any agentic coding system in the current landscape. As Meta continues expanding this roadmap, the gap between assisted coding and truly autonomous, long horizon software engineering looks set to keep narrowing.