How Muse Spark 1.2 was trained: co-training, long-horizon work, and a self-improvement loop
“Built for Muse Spark” isn’t marketing shorthand — it describes a training strategy. Three techniques from Meta’s release notes explain why the model and the agent perform better together than either would with a stranger.
A coding-focused update, scaled hard
Muse Spark 1.2 is an update to 1.1 aimed squarely at code: generation, complex debugging, codebase understanding, and end-to-end developer workflows. Meta significantly scaled training compute on coding tasks while widening the diversity of training environments — and kept the model’s general-agent strength intact rather than trading it away. The measurable result, paired with Muse Code: 82.9% on Terminal-Bench 2.1 and 59.3% on DeepSWE 1.1, competitive with the strongest agents in the category.
Technique one: co-training with the harness
Most coding agents are a generic model wearing a wrapper: the harness prompts the model, the model obliges, and the seams show up as retries and misused tools. Meta trained Muse Spark 1.2 with Muse Code instead. The training mix included rejection-sampled harness trajectories — complete agent runs, filtered so only successful ones teach the model — plus recipe optimizations for goals, compaction, and subagents, and integration of Muse Code’s actual toolset.
The consequence is a model that has already seen the situations its harness will put it in: when to fan work out to a subagent, how to phrase a tool call the runtime will accept, what a compacted context looks like. Meta’s claim — better tool use, fewer retries, higher-quality output than a generic wrapper — is a direct prediction of this setup.
Technique two: long-horizon training
Muse Spark 1.2 was extensively trained on tasks that don’t fit in one sitting: whole-repository generation, large end-to-end projects, auto-research. Three learned capabilities hold such work together — planning to sequence the steps, goal conditioning to maintain direction across hundreds of decisions, and context compaction to retain what matters when history exceeds even a 1M-token window. These aren’t bolt-on features; they surface directly in the product as /plan and /goal, and they’re what made the 24-hour kernel run possible.
Technique three: the model that graded its successor
The most interesting detail is the self-improvement loop. Meta used Muse Spark 1.1 to generate challenging coding environments and instruction-following templates, then had it grade candidate solutions on how well they satisfied those requirements. The graded output became a scalable training dataset for 1.2 — the previous generation manufacturing both the exam and the marking scheme for the next. Meta credits this loop specifically for 1.2 following complex instructions more precisely than its predecessor.
Why this matters beyond one release
Each technique compounds the others: co-training makes the harness a training signal, long-horizon training makes bigger tasks learnable, and self-improvement makes the whole pipeline cheaper to scale next time. Meta says larger, more capable models are on the way — and this machinery is presumably how they’ll be built. The full evaluation methodology is published on Meta’s research site; for what the numbers feel like in practice, start with the quickstart.