Meta lists Muse Code among its developer tools as the code-oriented member of the family, and that positioning is close to the entirety of what has been published. No benchmark figures, no stated context window, no described way of working. So rather than dress guesses up as an explainer, this page covers what is genuinely known, what a coding agent changes about agent risk, and the questions that will decide whether it is any good the moment specifics arrive.
This is a short section because it has to be. Meta lists Muse Code among its developer tools, positioned around code. Everything a developer would need in order to decide anything is missing from public material, and the correct response to that is to say so rather than to fill the space with plausible-sounding specification.
If Meta’s documentation now says more than this, it supersedes the page you are reading. That is the normal direction of travel and worth checking before you rely on anything here.
Stated plainly because the alternative is worse: a confident third-party specification for an unspecified product is how bad assumptions enter real projects. Our Meta Model API page takes the same line across the whole line-up.
This site has spent a lot of pages on what agents do to a Mac. A coding agent is the same machinery pointed at a repository, and that changes the risk in three specific ways two of them in your favour.
Everything established elsewhere on this site still applies. An agent that misreads an instruction hands back finished, confident, plausible work; the failures cluster in silent guesses, drift across long runs, and output produced where there was nothing to find. None of that changes because the files happen to contain source code.
What changes is the recovery. A codebase is the one place where the undo already exists, has existed for decades, and most people already have it running.
That is a genuinely better starting position than an agent rearranging your Downloads folder, where recovery means Finder and a backup you hopefully took. It is also the reason the advice for coding agents can be sharper: commit first, and the worst case becomes an inconvenience.
Against that, code has a property no other agent target has. It runs later, somewhere else, in front of other people.
Version control is the recovery mechanism every other agent domain lacks. An agent that renames two hundred files in a repository is a git checkout away from never having happened, provided you committed before you started.
What follows from it: the single cheapest habit in this whole category is committing a clean baseline before any agent run. It converts the worst case from a recovery problem into an inconvenience.
A wrongly renamed file announces itself the moment you look at the folder. Wrong code does not: it can read well, survive review, merge, and surface weeks later in somebody else’s incident. Plausibility and correctness come apart further here than anywhere else an agent operates.
What follows from it: reading the diff is not the same as verifying the behaviour, and an agent that is confidently wrong about code is harder to catch than one that is confidently wrong about a folder.
Code is the only agent domain where “did that work?” has a machine answer. A test suite is an oracle no other kind of task has which is why a repository with real tests is a far better place for an agent than one without, regardless of which agent it is.
What follows from it: your existing coverage is a prerequisite rather than a nice-to-have. An agent in an untested codebase gives you speed and removes your only cheap way of checking it.
Take these to Meta’s documentation when Muse Code is specified, or to any other coding agent you are weighing up today. They outrank benchmark scores, and the first one outranks the other five.
The single most consequential design choice in the category. An agent that writes directly into your working tree can be genuinely faster; an agent that proposes a change for you to accept puts a human between a misunderstanding and your code.
Why it comes first: it determines the blast radius of every other failure. Everything else on this list is a quality question; this one is a safety question.
There is a large difference between an agent that writes code and one that writes code, runs the suite, sees a failure and fixes it. The second is a qualitatively different tool.
Why it matters: this is the feature that uses the oracle your repository already provides. Without it you are the test runner, and most of the promised time saving goes back into your afternoon.
Completing a line, rewriting a function, or making a change that spans a dozen files and a migration are three different products that get described with the same words. Ask which one it actually does well.
Why it matters: the failure modes scale with the unit. A wrong line is obvious; a wrong change across twelve files is where drift hides.
The open file, the files you name, or the project as a whole including the conventions, the helper that already does this, and the reason the odd-looking line is odd.
Why it matters: most unhelpful output from coding tools is not wrong so much as ignorant of context that existed three directories away. A large context window is not the same as having read your codebase.
Ask for the behaviour, not the marketing: does it stop and ask, flag the assumption in the diff, or quietly pick the most plausible option and carry on?
Why it matters: silent guessing is the dominant failure across every agent this site has looked at, and in code it arrives dressed as a clean, readable change that does the wrong thing.
Whether source is sent off the machine, how long it is kept, whether it trains anything, and what that means for work under a client agreement or an employer’s policy.
Why it matters: it is the question developers skip and the one an employer cares about most. For commercial work the answer belongs in writing from the provider, not in a summary from anybody else including us.
None of these can be answered for Muse Code from public material today. That is the honest reason they are framed as questions rather than as a review.
There is one legitimate source of inference: Muse Code sits alongside a model whose numbers are public. That is worth thinking about, provided the thinking stays labelled as thinking.
Spark 1.3’s gains were concentrated in multi-step tool use, and a coding agent is largely an exercise in tool use read a file, edit it, run a command, read the output. If the family shares anything, that is the part worth having. The figures.
Accuracy over long inputs fell from 83% to 79% in the general model. Reading a large codebase is a long-input problem, so if that characteristic carried across it would matter here but a specialised model may well be tuned differently.
Meta lists Muse Code apart from Muse Spark rather than as a mode of it, which suggests specialisation. Suggests, not confirms: product naming and model architecture are not the same thing and often diverge.
Everything above is reasoning from a sibling product. Specialised coding models routinely behave nothing like the general models they are named after, in both directions, so hold all of it loosely and drop it entirely when real figures appear.
Inference presented as specification is how a plausible guess ends up quoted back as a fact three sites later. Every claim in this section is reasoning from a sibling product, and none of it should survive contact with a published figure.
If you have arrived here via a page that stated Muse Code’s context window or benchmark scores with confidence, that is worth a source check before you build on it.
This page will be worth rewriting the day Meta publishes a specification, and the rewrite should delete most of it. That is the intended outcome rather than a weakness.
The code-oriented member of Meta’s Muse family of developer tools. That positioning and the name are close to the whole of what has been published there are no benchmark figures, no stated context window and no published comparison against the general model. The full picture.
Meta lists it among its developer tools. Availability, access model and whether it is generally usable are not things this page can confirm, and they should be taken from Meta’s own developer documentation rather than from any third-party summary.
Unknown, and any page that tells you otherwise is guessing. No benchmark figures for it have been published, so there is nothing to reason from except the family it belongs to which is weak evidence about a specialised model.
Whether it writes to your working tree or proposes a diff you approve. That single design choice decides how much damage a misunderstanding can do, and it matters more than any benchmark score. The other five.
In one way safer and in another way worse. Safer because version control is a real undo that an agent working on your Downloads folder never has. Worse because code runs, so a wrong change can look correct, pass review and fail later. The three differences.
Not stated. Muse Spark is the general-purpose model behind Meta AI, and Muse Code is listed separately, which implies specialisation rather than confirming it. Treat the relationship between them as unpublished.
A little, carefully. Spark 1.3 improved on tool use and regressed on long documents, and both of those matter for coding work. But figures from a general model are weak evidence about a specialised one, and should be held loosely.
That you have committed your work, that tests exist and pass, and that you know whether the agent edits files directly or proposes changes. Those three take a minute and cover most of what goes wrong.
That is a question for the provider’s documentation and, for commercial work, possibly your legal team. Retention and training policy is the part developers skip most often and the part an employer is most likely to care about.
Meta’s own developer documentation. This is an independent guide and carries no endpoints, model identifiers, prices or quotas, because a third-party copy of those is a liability rather than a convenience the reasoning in full.
When the specification lands, six questions will tell you more than any launch post. Until then, the cheapest preparation is a clean commit and a test suite that passes.
Independent guide not affiliated with Meta and not official documentation. Specifications, availability and pricing come from Meta’s developer documentation. What is actually known today.