Muse Code: persistent sub-agents for multi-file repository work
The interesting word in Meta's announcement is not "terminal" or "agent". It is "persistent" — and it points at the failure mode everyone else has been losing to.

Published
August 4, 2026
Reading time
3 minutes
Perspective
Analysis
Topics
agents · coding · meta
Meta has introduced Muse Code (beta), a terminal coding agent powered by a new model, Muse Spark 1.2. From the announcement:
Muse Code plans, implements, and validates complex, multi-file changes across large repositories with persistent sub-agents that solve difficult problems faster, more accurately, and with less intervention.
Three phrases in that sentence carry the design.
"Plans, implements, and validates"
A three-phase loop, stated explicitly. Most agent failures happen because these collapse into one another — the agent implements while planning, and never validates because it has no independent notion of done.
Separating them means there is a checkable artefact between stages. A plan you can inspect before code is written is worth more than a summary of code already written.
"Multi-file changes across large repositories"
This is the hard case, and it is the one that defeats single-context approaches. A real change touches an interface, its implementations, its tests and its callers. Getting three of four right produces a repository that does not compile — strictly worse than no change.
Large repositories add the problem that the relevant context does not fit anywhere. The agent has to decide what to look at, which is a retrieval problem wearing a coding-agent costume.
"Persistent sub-agents" — the part worth attention
Sub-agents are not new. Persistent ones are the interesting claim.
Ephemeral sub-agents are spawned, complete a task, return a result and vanish — so everything learned along the way is lost, and the next sub-agent facing the same subsystem rediscovers it. Persistence implies state that survives across the session: a sub-agent that has already understood a module still understands it an hour later.
If that works, it addresses the specific failure that sank the 2023 autonomous-agent wave. Those systems did not fail because they could not call tools. They failed because they could not accumulate understanding, so hour two was no better informed than minute one.
What the announcement does not say
No benchmark numbers. No evaluation methodology. No statement of what "less intervention" is measured against.
That is normal for a launch post and it means the claims are currently unfalsifiable. Muse Spark 1.2 is new, so there is no independent evaluation of the underlying model either.
How I would test it
Not on a curated demo. On a repository you know, with a change that touches at least four files across a module boundary, and a stopwatch.
Then watch minute twenty specifically — the point where the first hypothesis turns out to be wrong. Good behaviour is discarding the approach and saying so. Bad behaviour is increasingly elaborate patches to a diagnosis that was never right, and it is what most agents do.
The wider pattern
Meta shipped this the same week Qwen went live in Command Code and Moonshot published Kimi tooling. Three labs, one interface, seven days — which is faster than any product cycle, so it means each concluded independently that the capability had become dependable.
Whether it has is the open question. Simultaneous launch tells you the labs believe it; it does not tell you it works.
The loop Meta describes
Ephemeral sub-agents discard what they learn, so hour two starts as uninformed as minute one. Persistence is the claim that dotted line represents — and the one worth testing.
Source: @AIatMeta
Continue reading