How to Use Muse Code

Muse Code in one minute

Muse Code is Meta's beta terminal coding agent, powered by Muse Spark 1.2. 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 model behind it 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 is the new purpose-built working shell around the newer 1.2 model.

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.

Meta has not published a native Windows install instruction in the launch post. Do not assume that an unofficial workaround has the same support status.

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 three built-in skills 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 own case study ran more than 1,000 tool calls over runs lasting up to 24 hours while the model wrote, compiled, profiled, and improved 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 promise that every Muse Code task can or should run for 24 hours.

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. “ai code review” gets about 1,300 US Google searches a month with a $63.85 CPC. “ai code review tools” adds 590 searches a month and is up 50% year over year. Existing willingness to pay is visible too: CodeRabbit lists Pro at $24 per user per month and Pro Plus 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 because Meta has not published a headless Muse Code or CI integration contract in the launch material.

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.

“legacy application modernization services” gets about 880 US Google searches a month. Its $52.40 CPC signals valuable buyers, although search interest is down 55% 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.

“visual regression testing” gets about 320 US Google searches a month with a $20.82 CPC. The market is smaller and search interest is down 34% 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.

• It is beta software. Treat the interface, limits, and behavior as changeable.
• Meta's official install instruction names macOS and Linux, not native 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 24-hour Meta case study is evidence of long-horizon training, not a service-level promise for your task.
• The launch post does not state a separate Muse Code price or publish media file-size limits. Check the live Meta developer dashboard before budgeting a production workflow.
• 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.