Meet Muse Spark 1.2 and Muse Code, the first coding agent from Meta

Today we're releasing Muse Spark 1.2 and an early beta of Muse Code, a purpose-built coding agent optimized for long-horizon, multi-agentic coding workflows and transparent auditability: every subagent it spawns, every tool call, every steer and cancel, is observable and replayable through the event log.

We're excited to release Muse Code to developers today, because the fastest way to build a great coding agent is with the people who use it every day to build things that matter.

We're also excited to announce that today we're expanding global access to our public preview, so developers around the world can start building with Muse Spark in Muse Code and Meta Model API.

Muse Code is a one-command install in terminal to get started:

In this blog post, we're going to cover the capabilities that enable developers to get started and maximize the unique agentic patterns Muse Code is built around. Each technical section maps to a runnable recipe in the Meta Model Cookbook.

For the full research story detailing how we trained the model, evaluated it, and built the self-improvement loop, head to the AI at Meta blog.

TL;DR

• Muse Spark 1.2 is now available across Muse Code, Meta Model API, and OpenRouter through today's expanded global access.
• Install Muse Code with one command and authenticate in your browser at dev.meta.ai. Available now in beta.
• These cookbooks are written to help developers get the most out of Muse Code. The ones we cover in this blog post and recommend checking out first:
• Fan work out: this recipe is designed to show you how Muse Code distributes one large job across several subagents, each running in parallel in its own isolated git worktree and how they can be controlled from a single point. (Cookbook: Agent fan-out).
• Bundled skills: Muse Code comes with a few trusted and tested playbooks built in. This recipe runs four of them end to end to show you what each one does and when to use it. (Cookbook: Bundled skills).
• Goal tracking: See how Muse Code keeps an agent on a multi-step task from concept to merge. (Cookbook: Goal tracking).
• We now have two pricing tiers based on model ID for developers to select based on their token cap and spend preferences.
• /model to muse-spark-1.2-contributor: rate-limited by tokens in a rolling 5-hour window, not by request count, may be used to improve our products.
• /model to muse-spark-1.2: standard Model API pricing
• We're also beginning to accept requests for zero data retention. Contact Meta sales to request this.

Muse Spark 1.2 is a moderate improvement over Muse Spark 1.1 and optimized for the work that coding agents get handed most, such as multi-file refactors, long debugging sessions and tasks that run well past a single prompt. Muse-spark-1.2 is now available across Muse Code, Meta Model API, and OpenRouter through today's expanded global access.

Three areas where we've seen the biggest improvement:

• Co-trained with the harness. Muse Code was in the training loop from day one, so tool calls succeed and plans execute cleanly. Crucially, we trained across multiple harnesses, so while the model is at its best in Muse Code, it still generalizes to other coding agents you already use.
• Built for long-horizon work. Trained on whole-repository generation and other long-running tasks, it uses planning, goal conditioning and context compaction to hold direction over hours, plus asynchronous and parallel tool calls, so work continues while results are still pending.
• Whole-project context. A 1M-token window holds dependency graphs, legacy code and thousands of files in one session.

Here's how Muse Spark 1.2 stacks up against the models in its class:

Muse Code starts on a contributor tier with rate-limiting by tokens in a rolling 5-hour window rather than by request count, so you can use the agent day to day. Pricing is determined by model ID, so developers can pick the right tier based on their needs:

• model to muse-spark-1.2-contributor: rate-limited by tokens in a rolling 5-hour window, not by request count. Available in select countries.
• model to muse-spark-1.2: standard Model API pricing

When you need more tokens, swap the model to muse-spark-1.2 to run on standard Model API pay-as-you-go pricing: $0.15 / 1M cached input, $1.25 / 1M input, $4.25 / 1M output. We're also beginning to accept requests for zero data retention. Contact Meta sales to request this.

The recipes cover the core patterns that help developers get the most from Muse Code:

• Agent fan-out: Split one big job across multiple subagents each in its own worktree, so nothing collides mid-flight and your working copy stays clean.
• Bundled skills: Put a rough idea in, and get a grilled, taste-checked feature out. This recipe shows the built-in playbooks doing the work.
• Goal tracking: Set your goal and Muse Code keeps an agent on task, so what you originally wanted is what gets merged.

If you're interested in diving into more Muse Code and Model API cookbooks, check them out here.

Muse Code runs on Model API, but you can start within your terminal by installing the package and authenticating in the browser when prompted before getting your first session off the ground.

curl -fsSL https://dev.meta.ai/install.sh | bash

That's it. Once you install the package and finish auth, you're free to get started in any of your project directories by entering muse in your terminal.

• Muse Spark is a reasoning model. It thinks before it answers; those tokens are billed as output. /effort dials the thinking up or down so you don't have to pay more for deep reasoning on straightforward tasks.
• Your tone, format and other standing rules can be set in a system message so you don't have to repeat them every time you send a prompt.

Muse Code is built around a simple pattern: when a job is split into several different tasks, they're fanned out automatically to separate agents. The parent agent spawns a write-capable child per task, and each child gets its own git worktree, so parallel children never collide on the same files. Your working copy is never touched and you don't set any of this up — Muse Code does it all automatically.

Launch with isolation on, from inside a git repo:

The sample lives in bastion_breaker/ in meta-models cookbooks on GitHub. It is a playable game with a pure-simulation core (game/engine.py, no pygame) so the rules are testable without a window and a thin pygame render layer on top.

cd bastion_breaker
pip install -r requirements.txt
SDL_VIDEODRIVER=dummy python3 -m pytest tests/ -q     # headless, no window 

The world rule under test: the player breaks one brick per shot; the enemies hide behind the brick bastion and must not break it. The sample ships with that rule broken on purpose. tests/test_rules.py has three checks, and exactly one fails on the shipped code.

The failure is visible on screen too: the enemy's own fire chews notches out of the wall it is supposed to hide behind (left). The fixed build keeps the wall intact and lets enemy shots pass through (right).

So the full list of features is:

1. Fix the enemy-laser-destroys-bricks bug
2. Add high-score persistence
3. Make bricks multi-colored by row
4. Add a brick-shatter particle effect
5. Add a combo multiplier
6. Add a power-up drop from broken bricks

Then hand the parent the whole batch in one prompt, each feature will automatically be taken care of by its own subagent:

This repo (Bastion Breaker) is a brick-out x space-invaders game. World rule: the player breaks bricks, but ENEMY lasers must NOT destroy bricks. There is a bug where enemy lasers do destroy bricks (game/engine.py _resolve_laser). Fan this work out to parallel subagents, each in its OWN isolated git worktree. 
                  
Spawn one write-capable subagent WITH worktree_isolation for EACH task: (1) fix the enemy-laser-destroys-bricks bug, (2) add high-score persistence, (3) make bricks multi-colored by row from assets/bricks/*.png, (4) add a brick-shatter particle effect, (5) add a combo multiplier, (6) add a power-up drop from a broken brick. Spawn all 6 now, then call subagent_status and show me the roster.

The parent spawns six children. On this host the concurrency limit works out to four, so four run immediately; tasks 5 and 6 are admitted, queue and start as slots free.

Each child gets its own worktree and branch and subagent_status returns the roster:

The isolation is real on disk and the runtime creates each worktree under .muse/worktrees/ in detached-HEAD state, checked out from the parent's HEAD with no manual git worktree command. In the recipe's run, the child that fixed the bug passes the full suite inside its own worktree while the parent's master still fails that same test, untouched. The lifecycle is visible in the event log: each worktree walks operation_requested → prepared → lease_active → workspace_scope_activated, carrying its base_commit, base_ref: HEAD, and cleanup_policy: remove_if_clean.

When a child finishes, its result drains back to the parent automatically once the parent's turn is idle, or you can block on one with subagent_wait. Each child commits its work on its own branch, so the parent can review or merge them one at a time. Here is the multi-colored-bricks feature (task 3) running with the bug already fixed in that same worktree:

TL;DR: one prompt fans a batch of tasks out to parallel subagents, each in its own git worktree and you steer or stop any of them from a single command center (Cookbook: Agent fan-out).

We know handing work off to a swarm of subagents can feel a bit worrying; you can never be 100% sure exactly what they're going to do. That's why we've built Muse Code to log everything including sessions, agent spawns, actions, and every decision a subagent made. When you're wondering which child did what and when, you can just look it up instead of having to spend time hunting down what went wrong.

It's plain JSONL on your disk, so you can grep it:

Each worktree's lifecycle is in there too (operation_requested → prepared → lease_active → workspace_scope_activated), carrying its base commit and cleanup policy. Sessions also persist across closing your laptop, so you can pick a run back up where you left it.

The same log is what enables the muse resume command. With resume, if your session gets killed or crashes, the next session reads the log and carries on from the last recorded step. Everything the agent did is already on disk so you don't have to re-prompt it to get back up to speed.

TL;DR: every action lands in a replayable per-session event log you can audit with jq and it's the same log that gets you back working fast after a session crash or accidental shutdown.

Muse Code ships with a small set of opinionated playbooks so even a rough one sentence idea can get you going fast. The bundled skills include:

• /taste: an anti-slop filter: a flat checklist of visual defaults not to use, so generated UI stops looking machine-made.
• /grilling: interviews you one decision-forcing question at a time until the design holds up.
• /grill-with-docs: the same interview, but it writes the settled decisions into your project docs as durable decision records, not chat scrollback.
• /plan: grounds a plan in your real files, names the key decisions with a recommendation for each, saves it to .agents/plans/ and stops for approval. No code changes.

All four are explicit-invocation only. Muse Code won't reach for /grill just because a design looks shaky. And a skill loads its full instructions only for the turn you invoke it on; the TUI marks it with a Loaded skill <name> built-in line, so you can see exactly which turn a skill shaped.

In the full recipe, we walk through a demo where /plan reads the actual code before planning, and catches that an unvalidated deposit would let a negative transfer slip past the overdraft protection being designed. Exactly the kind of decision that needs to be surfaced before you build instead of after.

TL;DR:/plan, /grilling, /grill-with-docs, and /taste ship built in, fire only when you ask and scope to the turn you invoke them on (Cookbook: Bundled skills).

We built Muse Code to be the best way to run Muse Spark 1.2, with real parallelism, context that finds you and a log of everything it did.

We're excited to bring expanded global access to developers with Muse Spark 1.2 and Muse Code. Install it, hand it a failing test and tell us what breaks.