DevNews

Meta Ships Muse Code, a Terminal Agent for Large Repos

On this page
  1. Sub agents get their own worktrees
  2. The event log
  3. Read the pricing page as a contract, not a price list
  4. What we would do
  5. Sources and further reading

Meta released Muse Code on August 5, a terminal coding agent for macOS and Linux that plans, writes and validates changes across large repositories. It runs on the Muse Spark 1.2 model, installs with a single command, and fans work out to sub agents in isolated git worktrees so parallel jobs never touch your working copy. The part worth reading twice is the pricing page. The standard tier costs 1.25 dollars per million input tokens and 4.25 per million output, and Meta says prompts on that tier are not used for training. The contributor tier costs about a tenth of that, and what you hand over instead of money is your code.

The short answer

Muse Code is Meta's first coding agent: a terminal tool that plans, writes and validates changes across large repositories, built on the Muse Spark 1.2 model and installed with one command. For big jobs it fans out to sub agents running in isolated git worktrees, and it keeps a local event log so an interrupted run can resume. Pricing comes in two shapes. The standard tier is pay as you go with no training on your prompts. The contributor tier costs roughly a tenth as much and requires permission to train on everything you send.

Aug 5Muse Code launched in public beta for macOS and Linux
$1.25 / $4.25standard tier, per million input and output tokens
~10xcheaper on the contributor tier, paid for with training rights
Answer card: Meta launched Muse Code in beta on August 5 2026, a terminal coding agent for macOS and Linux built on Muse Spark 1.2, which spawns sub agents in isolated git worktrees and offers a contributor pricing tier roughly ten times cheaper in exchange for permission to train on your prompts and completions.
Muse Code at a glance. Sources: Meta's launch materials as reported by CNBC, TechCrunch and VentureBeat, August 5, 2026. PNG

There is now a coding agent from every company large enough to have a model, and the interesting question has stopped being whether they work. Meta's entry arrived on August 5 under the name Muse Code, in public beta, for macOS and Linux, installed with a single curl command and driven entirely from a terminal. No desktop application, no editor plugin at launch.

The capability description is the standard one at this point: it takes a task, plans the change, writes the code and validates the result, across a repository large enough that you would not want to describe it by hand. It runs on Muse Spark 1.2, a coding focused refresh of the model Meta moved to after Llama, and Meta's AI leadership has been direct that cost is the pitch. Their AI chief framed it as an option that is compelling "especially from a cost perspective."

Two parts of the design are worth more than the launch coverage gave them.

The announcement post from Meta's CEO, August 5, 2026.

Sub agents get their own worktrees

When a job is large enough, Muse Code splits it across parallel sub agents, and each one gets an isolated git worktree rather than sharing your checkout.

This sounds like plumbing and it is, but it is the plumbing that decides whether parallel agents are useful or a liability. A worktree is a second working directory attached to the same repository, with its own checkout and its own index. Two agents in two worktrees cannot overwrite each other's files, cannot fight over the index, and cannot leave your own uncommitted work in a state you did not ask for. Meta cites an internal run that built six features at once without collisions, which is the entire point of the number: the failure mode being avoided is not slowness, it is corruption.

Anyone can wire this up with git worktree add and a shell loop, and plenty of teams already have. Making it the default behaviour instead of an exercise for the reader is a real improvement, and we would expect the other agents to converge on it.

The event log

The second piece is a local log of what the agent did, recorded step by step: model calls, tool invocations, approvals you granted, edits it made. Its advertised purpose is crash recovery, and a long run that dies at minute thirty five without losing thirty five minutes of work is genuinely worth having.

The better use is review. A diff tells you what changed. It does not tell you why the agent thought that was the task, which of your approvals it was acting under, or what it read before deciding. On an eleven file change that distinction is the difference between reviewing a patch and reviewing a decision. Read the log before you merge anything you would be embarrassed to have shipped.

Terminal card comparing the Muse Code pricing tiers: installing the beta on macOS or Linux, the standard tier at 1.25 dollars per million input tokens with no training on prompts, and the contributor tier at roughly a tenth of the price with training rights granted and a sixty request per minute limit.
The two tiers, side by side. The cheap one is not free, it is paid in a different currency. PNG

Read the pricing page as a contract, not a price list

The standard tier is conventional: 1.25 dollars per million input tokens, 4.25 per million output, 0.15 per million for cached input, with rate limits of three thousand requests and four million tokens per minute per team. Meta states that prompts and completions on this tier are not used to train its models.

The contributor tier is where it gets interesting. Roughly 0.10 per million input and 0.20 per million output, cached input at fractions of a cent, and a rate limit of sixty requests per minute. The consideration is explicit: you permit Meta to train on your prompts and completions. Reporting has called it the cheapest tier on the market, and on the raw arithmetic it is.

Here is what makes this different from a normal discount. A coding agent does not see a question, it sees your repository. Source, configuration, internal hostnames, comments that explain why a workaround exists, the shape of a system nobody outside your team has described in public. If you work under a client agreement, an NDA, or an employment contract with an IP clause, the contributor tier is not a purchasing decision an engineer gets to make alone. That is not a criticism of Meta, which has documented the trade plainly. It is a note that the tier was designed for individuals and experiments, the sixty request limit says so, and it should stay there.

What we would do

Try it on something real and unimportant, on the standard tier, and read the log.

The parts of Muse Code we would actually copy are architectural rather than proprietary. Isolating parallel agents in worktrees is correct and you can do it today with whatever agent you already run. Keeping a durable per step record of an agent session is correct and mostly missing elsewhere. Those two ideas will outlast any particular product's pricing.

On the tier question, our position is simple. If the code is yours and the stakes are low, the contributor tier is a good deal and you should take it. If the code belongs to a client or an employer, the price is not the number on the page.

Sources and further reading

Frequently asked questions

What does the contributor tier actually cost me?

Money, no. Confidentiality, yes. On the standard tier Meta charges 1.25 dollars per million input tokens, 4.25 per million output and 0.15 per million cached input, and states that prompts and completions there are not used to train its models. The contributor tier drops that to roughly 0.10 per million input and 0.20 per million output, which is about twelve times cheaper on the way in and twenty times cheaper on the way out, and the condition is explicit permission for Meta to train on what you send. A coding agent sees your whole repository: source, configuration, comments, internal service names, the shape of your architecture. If any of that is under a client agreement or an employment contract, the cheap tier is not a pricing decision you can make on your own. It is also rate limited to sixty requests per minute, so it was built for individuals and experiments rather than a team pipeline.

What is the point of running sub agents in separate worktrees?

It removes the single worst failure mode of parallel agents, which is two of them editing the same file in the same checkout. A git worktree is a second working directory attached to the same repository, checked out at its own commit, with its own index. Give each sub agent one and their edits are physically separated until something merges them. Meta says a test run built six game features concurrently without collisions, and that number is the whole argument: without isolation, concurrent agents on one checkout produce a mess that costs more to untangle than doing the work serially. You can build this pattern yourself with any agent and a shell script, and plenty of people have. Having it as the default behaviour rather than a thing you remember to set up is the actual product improvement.

Why does a local event log matter for an agent?

Because long agent runs fail halfway through, and without a record you start over. Muse Code writes a local log of model calls, tool invocations, approvals and edits as it goes, so a crashed or interrupted session can be resumed rather than restarted. Two things fall out of that. The obvious one is time: a forty minute run that dies at minute thirty five does not cost you forty minutes twice. The less obvious one is review. An agent that made eleven file changes across a repository is hard to audit from the diff alone, because the diff shows you what changed but not what the agent was trying to do or which of your approvals it was acting on. A per step log is the closest thing to a paper trail these tools currently offer, and it is worth reading before you merge anything substantial.

Should I switch from whatever agent I use now?

Not on the strength of a launch post. Muse Code is in public beta, it runs on macOS and Linux only, and it is a terminal tool with no desktop application, so the surface it competes on is narrow and familiar. The honest reasons to try it are cost on high volume workloads and the worktree fan out if you regularly run parallel tasks. The honest reasons to wait are that the model behind it, Muse Spark 1.2, is new enough that independent benchmarks have not caught up, and beta pricing on any of these tools historically moves. Our suggestion is the one we give for every agent: point it at a real but non critical repository, give it a task you already know the answer to, and read every line it produces before you let it near anything that matters.

Does it need my whole repository uploaded somewhere?

It needs to send whatever it reads, which on a large repository accumulates fast. That is true of every hosted coding agent, not a quirk of this one, and it is why the tier question above is not academic. The agent runs locally in your terminal, but the model does not: prompts, file contents it decides to read and the results of tool calls all travel to Meta's API. The standard tier and the contributor tier differ only in what happens to that data afterwards. If your organisation has a rule about where source code may be processed, that rule applies here in exactly the same way it applies to any other hosted agent, and the answer does not change because the tool runs in a terminal instead of a browser.