How to Use Muse Code

Muse Code in one minute

Muse Code is Meta's terminal coding agent, with Muse Spark and Muse Wonder models available. It is designed for complex work across large repositories, not just completing the next line in an editor.

The useful mental model is a construction foreman with a standing crew and a flight recorder. The main agent keeps the objective in view. Persistent background agents stay active through the session and handle supporting work without repeatedly starting from zero. A local event log records every model call, tool run, approval, and edit, so Meta describes the runtime as replay-exact and able to resume after a crash.

The Muse Spark 1.2 model has a 1 million-token context window, which is the amount of material it can consider at once. Meta also co-trained Muse Spark 1.2 with the Muse Code toolset and focused its training on whole-repository generation, large projects, debugging, and other long tasks. That pairing matters more than a benchmark score because the model learned inside the same kind of working environment you use.

For the model-level history, see the earlier Muse Spark 1.1 review. Muse Code remains the purpose-built working shell around these models.

Which model to pick inside Muse Code

Since October 12, 2026, Muse Wonder runs in Muse Code and on the Meta Model API; Muse Wonder Full runs only inside Muse Code with a qualifying subscription. Model access and monthly prices below were verified against Meta's pages on October 13, 2026.

• Muse Spark 1.2: a practical choice for bounded coding and debugging tasks. Meta describes Spark 1.2 as optimized for coding workflows, with more reliable tool use and improved first-attempt accuracy.
• Muse Wonder: pick it for difficult changes across many files or prolonged agent work. Meta emphasizes planning, delegation, error recovery, and computer use on its Wonder model page.
• Muse Wonder Full: reserve it for your hardest engineering tasks. Meta positions it as its most advanced model for critical developer workflows; access requires Power Usage or Maximum Usage.

Meta also lists Muse Spark 1.3 on every Muse Code plan and recommends it for new Spark work; 1.2 remains available. The model availability docs establish the access below, and the Muse Code product page states the monthly prices exactly:

Use /models to switch within a session. Start with a bounded task and move up when its complexity warrants it; a higher plan does not replace review. Subscription availability and benefits can vary by region.

How to use Muse Code

The safest first run is small enough to inspect but large enough to test the agent's workflow. Pick one real bug with a failing test, one contained feature with clear acceptance criteria, or one migration step that can land as its own pull request.

1. Install the official launcher

Meta publishes one command for macOS and Linux:

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

The official installer creates a launcher named muse and puts it in ~/.local/bin by default. After installation, open the repository you want to work on in your terminal and run muse there. On first run, review the workspace trust prompt and sign in through the browser or provide an API key.

Meta also publishes a Windows PowerShell installer:

irm https://dev.meta.ai/install.ps1 | iex

2. Give it an outcome, not a vague request

A strong task names five things: the outcome, the files or subsystem in scope, what must stay unchanged, the command that proves success, and when the agent should stop.

That prompt gives the agent a finish line. “Improve the orders service” does not.

3. Use the planning skills and goal command in order

Start with /plan. It turns the objective into an approval-gated plan, so you can catch a wrong interpretation before code changes begin.

Use /grill when the plan carries real risk. It stress-tests the plan until the weak assumptions are visible. Ask it to challenge migration order, missing tests, rollback steps, security boundaries, and anything the plan quietly assumes.

Use /goal after the plan holds up. This tells the agent to work toward the specified completion condition. The point is not to remove judgment. It is to keep a long run pointed at the evidence you chose.

4. Review the proof, not the confidence

When the run finishes, inspect the diff, the commands it ran, the test output, and any behavior it could not verify. A green test suite proves only what those tests cover. For a first run, keep deployment, credential changes, destructive migrations, and production access outside the agent's reach.

The prompt shape that makes long runs useful

Long context is not a substitute for a crisp brief. It simply lets the agent carry more relevant material without losing the thread. Give Muse Code a compact operating contract:

The best proof is executable. A failing test that must pass is stronger than “make it robust.” A screenshot plus a visual regression check is stronger than “make it look right.” A migration with a reversible checkpoint is stronger than “modernize this app.”

Seven real use cases, ranked by who benefits most

The biggest winners are teams with large repositories, good automated checks, and work that can be split into verifiable pieces. Muse Code's persistent agents and restart-safe log matter most when a task lasts long enough for ordinary chat context to become a liability.

1. A product team turning a scoped issue into a reviewed pull request

A SaaS team can hand Muse Code a bug report, the affected package, a failing test, and the command that proves the fix. It can plan, inspect the repository, make the change, and validate it. The payoff is shorter time from triage to a reviewable patch, while the human reviewer keeps control of scope and merge.

2. An enterprise team modernizing one legacy seam at a time

A platform group can define one boundary, such as replacing an old authentication adapter while preserving its public contract. Background agents could trace dependencies and tests while the main agent keeps the migration sequence coherent. The payoff is a smaller, auditable unit of modernization instead of one dangerous rewrite.

3. A maintenance team chasing a bug across a monorepo

An engineer can provide the error, reproduction steps, logs, and the command that fails. Muse Code is built for complex debugging and codebase understanding, so a team could use it to trace the defect across packages, add a regression test, patch the cause, and rerun the evidence. That cuts the repetitive search work without outsourcing the final judgment.

4. A web team turning a visual brief into a working prototype

Meta demonstrates an MP4 fly-through supplied in the terminal, which Muse Code interprets to create a vacation-home marketing and booking page. A design-led team could use the same pattern for a visual product brief, then inspect the rendered result and code together. The payoff is a faster first implementation, not automatic design quality.

5. A library owner planning a dependency upgrade

A maintainer can ask for an upgrade plan that maps affected imports, compatibility breaks, tests, and rollback points before any edit. /grill is especially useful here because a dependency change often fails at the edges, not in the first file touched. The payoff is a migration plan tied to evidence rather than a blind version bump.

6. A QA team converting flaky failures into stable tests

A QA engineer can give the agent a flaky test, recent failure logs, and a rule that production behavior must not change. The agent could investigate the race, repair the test or implementation, and repeat the focused suite. The payoff is turning intermittent failures into a reviewable diagnosis instead of repeatedly rerunning CI.

7. A performance team iterating on a measured hotspot

Meta's published kernel-optimization case study describes the model writing, compiling, profiling, and improving GPU kernels. A specialist team could apply that loop to a well-instrumented hotspot with a fixed benchmark. The payoff comes from rapid measured iteration. The case study is not a runtime or performance guarantee for your task.

What you could build with Muse Code

Three products fit the capability and current demand. The first is the strongest because it has a clear buyer, measurable proof, and a small first version that can live beside an existing pull-request workflow.

1. A review-to-repair gate for pull requests, the strongest bet

Build a reviewer that does not stop at comments. It reads a pull request in repository context, reproduces the issue, proposes a patch, runs the relevant checks, and hands the author both the finding and a reviewable fix.

Demand is already commercial. DataForSEO estimates “ai code review” at about 1,300 US Google searches a month with a $55.73 CPC. “ai code review tools” adds 590 searches a month and is flat year over year. Existing willingness to pay is visible too: CodeRabbit lists Essentials at $24 per user per month and Team at $48, billed annually.

The smallest sellable version is human-triggered: check out one pull request in a disposable environment, run a fixed review prompt, execute the repository's tests, and return a patch plus evidence. Start locally to validate the workflow, then use Meta's documented headless and CI mode, muse exec, when the checks are ready to automate.

The catch is competition. A generic comment bot has no moat. The product needs a narrow edge, such as framework-specific checks, a low false-positive rate, policy evidence, or repair quality that saves a senior reviewer real time.

2. A migration control room for legacy systems

Build a guided workspace that breaks modernization into approval-gated slices, attaches tests and rollback rules to every slice, and keeps a human decision log beside the generated patches. Engineering leaders and specialist modernization firms would pay for visibility and control, not another chat window.

DataForSEO estimates “legacy application modernization services” at about 880 US Google searches a month. Its $68.07 CPC signals valuable buyers, although search interest is down 64% year over year. That makes this a focused sales product, not a broad self-serve acquisition play.

The MVP handles one migration pattern in one stack. It inventories the target seam, produces a /plan, challenges it with /grill, runs one approved change, and packages the diff, tests, and rollback notes. The catch is domain knowledge: weak tests and undocumented business rules can make a technically clean migration wrong.

3. A visual bug-to-patch desk

Build an intake tool where a product manager supplies a screenshot or short video, points to the repository, and receives a reproduced visual defect, a patch, and before-and-after checks. Meta's MP4-to-site example makes the input pattern credible, while Muse Spark's coding and multimodal training support the reasoning path.

DataForSEO estimates “visual regression testing” at about 320 US Google searches a month with a $16.11 CPC. The market is smaller and search interest is flat year over year, so the sharper offer is not another screenshot-diff tool. It is a repair workflow for teams that already know a visual regression exists.

The MVP supports one browser stack, one viewport set, and one repository at a time. The catch is input ambiguity. Meta does not publish Muse Code media-size limits in the launch post, and a video that shows a symptom may not reveal the underlying state or accessibility problem.

What Muse Code does not solve

Muse Code makes long software tasks more manageable. It does not make them automatically correct.

• Treat the interface, limits, and behavior as changeable; check the current documentation before automating a workflow.
• Meta supports macOS, Linux, and Windows, but voice input and session messaging are unavailable on Windows.
• The local event log improves recovery and auditability, but it does not replace repository permissions, secret isolation, or human review.
• The 1 million-token context window is capacity, not judgment. Irrelevant context can still distract a run.
• A Meta case study is evidence of long-horizon training, not a service-level promise for your task.
• Muse Code has paid subscriptions and pay-as-you-go billing. Wonder Full requires Power Usage or Maximum Usage; additional API keys are billed separately. The launch post does not publish media file-size limits.
• Subscriptions default to Contributor mode, which lets Meta use your content to train models in exchange for more usage. You can turn it off in settings.
• A generated patch still needs tests, security review, and a responsible owner before it ships.

This is also why asynchronous agents need clear checkpoints. The same design question appears in managed agents that continue after you disconnect: persistence is useful only when the system knows what requires a person.

FAQ

If you want one of these workflows built around your repositories and approval rules, see AI agent development.