Meta's Muse Code Bets on Cheap Tokens, Not Top Benchmark Scores

What Meta actually shipped

• Muse Code entered beta on 5 August 2026, from Meta Superintelligence Labs. It is a terminal coding agent for macOS and Linux, installed with a single shell command.
• It runs on Muse Spark 1.2, and plans, implements and validates multi-file changes across large repositories.
• The architectural signature is persistence: asynchronous background subagents that stay alive for the whole session rather than spawning per task, fanned out in parallel into isolated git worktrees.
• Approvals and an operating-system sandbox are on by default, rather than being an opt-in hardening step.
• Pricing, as of 6 August 2026: US$1.25 per million input tokens, US$4.25 per million output, US$0.15 per million cached input. All prices in this article are US dollars. Pay as you go. No seat fee.
• It does not top the benchmarks. On Meta's own published figures, Muse Spark 1.2 scores 82.9% on Terminal-Bench 2.1, against 86.7% for Claude Code on Opus 5 and 81.8% for GPT-5.6 Terra on Codex.

We have already covered the Muse Spark 1.2 model. This is a different decision. What Meta shipped on 5 August is a harness and a business model, and the harness is the less surprising half. Read the announcement from Meta's research blog alongside TechCrunch's write-up and the framing is consistent: this is an agent for large code bases, priced by the token, entering a field that has spent a year converging on flat monthly subscriptions.

That is the whole story. Muse Code loses the headline race and might still win the invoice.

Meta published the benchmarks it lost

Give Meta credit for the disclosure before picking it apart. Claude Opus 5 outscored Muse Spark 1.2 on all three coding evaluations Meta published. Meta printed those results itself, in its own launch material, which is not the normal behaviour of a launch blog and is worth more than another chart with a cropped y-axis.

Under four points behind the leader is not a humiliation. It is, however, a pattern. Meta has now been a few points behind for two model generations, and that consistency tells you more than either individual result.

A gap that has held for two generations

Go back to April 2026. On figures reported at the time, the original Muse Spark scored 77.4 on SWE-Bench Verified, against Claude Opus 4.6 at 80.8 and Gemini 3.1 Pro at 80.6 — a 3.4-point deficit to the leader, and third place rather than second. Four months later, on a different benchmark and a newer model, the deficit is 3.8 points. The two gaps are not measured on a common scale, so the arithmetic does not transfer; what carries across is the pattern of landing just short of the leader rather than level with it.

You can read this two ways. The generous reading is that Meta is holding pace with a field that is moving quickly, which is not nothing. The unsentimental reading is that Meta has not closed a gap it has now had two attempts at, and a lab that consistently arrives second has to compete on something other than capability. Pricing is the obvious something. Whether that reflects genuine efficiency or a willingness to buy adoption is a question the balance sheet answers, not the benchmark table — and it is why the crowded state of the coding agent stack going into 2026 matters more to this launch than the score does.

Why 3.8 points costs more when nobody is watching

If you sit at the keyboard while the agent works, a 3.8-point gap in first-pass success is an irritation. You notice the failure immediately, you correct the prompt, you move on. The cost is a minute of your attention.

Unattended, the same gap behaves differently, and the difference compounds in a direction most cost models miss. Treat the benchmark as a rough proxy for first-pass success: 82.9% implies roughly 17 failures in every hundred runs, against roughly 13 for the leader. That is four extra failures per hundred. Every one of those failures is billed — you paid for the input and output tokens and got a diff that does not pass. Then you pay again for the retry.

Fold a single retry into the illustrative task cost below and Muse Code's $2.10 becomes about $2.46 in expectation. Still cheap. But the token bill is the small half of the loss. The expensive half is that four extra failed pipeline runs per hundred each land in someone's morning, and an engineer investigating a failed automated change is the most costly line item in the entire workflow. This is precisely why cost per completed task beats cost per token as a planning unit: a cheap model that needs two attempts is not cheap, and a cheap model that needs a human to arbitrate the second attempt is not even in the same category.

Persistent subagents and isolated worktrees

Strip out the pricing and this is the genuinely interesting engineering decision in the release, and the one most likely to be copied.

Most agent harnesses spawn a subagent when they need one and tear it down when the delegated job finishes. It is a clean model. It is also forgetful: each new subagent starts cold, rebuilds its picture of the repository from scratch, and pays for that context again. Muse Code keeps its background subagents alive for the whole session. They accumulate understanding of the code base as the session progresses rather than rediscovering it every few minutes.

The second half is the git worktree fan-out. Parallel agents that share one working tree are a well-known way to produce garbage: two subagents editing overlapping files, a half-applied refactor, a test suite that fails for reasons unrelated to either change. Isolated worktrees remove the failure mode structurally rather than through coordination. Each subagent gets its own checkout of the same repository, works without contending for the file system, and its output is merged deliberately. Anyone who has already adopted git worktrees for parallel coding agents by hand will recognise the pattern immediately — Meta has simply made it the default rather than a technique you assemble yourself.

Now the cost, which the launch material spends less time on. Persistent subagents burn tokens for as long as they are alive, and parallel ones burn them concurrently. On a subscription that opacity is invisible — you hit a rate limit occasionally and otherwise stop thinking about it. On a metered bill, concurrency is a spending decision, and your agent makes it on your behalf several times an hour.

The billing model is the actual product

Here is the tension in one line: Muse Code is a metered per-token agent entering a market that has standardised on flat-rate subscription agents. Claude Code comes bundled into Anthropic's $20 Pro plan, with Max tiers at $100 and $200. Codex ships inside a $20 ChatGPT Plus subscription. Muse Code has no seat price at all — you pay for what you consume, and nothing when you do not.

A single task, three price tags

Coverage of the launch has centred on one worked comparison, and it is a useful anchor provided you treat it as exactly that. For an illustrative single task consuming one million input tokens and two hundred thousand output tokens, the arithmetic lands at roughly $2.10 for standard Muse, $4.40 for Terra and $10 for Opus 5.

Two caveats matter more than the numbers. First, it excludes cached-input savings, which is where a metered agent does its best work — at $0.15 per million, a run with eighty per cent cache hits on the input side falls well under the headline figure. Second, and more importantly, it compares metered rates for all three, which is not how most people buy Claude Code or Codex. Those come inside a subscription, and a subscription does not care how many tokens you spend until you hit its limits. Comparing a per-token price against a bundled one is comparing a taxi fare with a travelcard.

Where the break-even sits

So do the travelcard arithmetic instead. Hold the illustrative task at $2.10 and ask how many of them a monthly plan absorbs before the metered option becomes cheaper.

The break-even points fall out cleanly: about nine tasks a month against the $20 tier, about 48 against $100, and about 95 against $200. Ninety-five tasks a month is a little over four a working day. That is a real threshold, and it is lower than most engineers guess — a developer genuinely living inside an agent all day will pass it without noticing, and the shift we are seeing towards agents that run continuously rather than on request pushes the arithmetic towards subscriptions for interactive work. Push the cache-hit rate up and the picture changes again: at eighty per cent cached input the same task costs about $1.22, and the $200 plan is then worth roughly 164 tasks.

Two teams, two answers

Consider a Bengaluru startup with six engineers that runs agents mostly through continuous integration: a nightly dependency-upgrade pass, an automated test-repair job, a migration sweep that fires when a schema changes. Say 800 automated runs a month against maybe 30 interactive sessions. At the illustrative rate that is roughly $1,680 of metered spend — and, crucially, there is no seat to buy, because a pipeline is not a person. Subscription plans are sold per human at a keyboard. Metered billing is not merely cheaper here; it is the only shape that fits.

Now a London scale-up with twenty full-time engineers, each using an agent conversationally throughout the working day. Twenty seats on the $200 Max tier is $4,000 a month, fixed and forecastable. Twenty engineers running 150 tasks each is 3,000 tasks, or roughly $6,300 metered — more than half again as expensive, before anyone has a bad week and leaves four background subagents running over lunch. The subscription wins, and it wins twice: on price, and on the fact that nobody has to think about it.

Neither team is wrong; the workload shape is doing all the work in that decision. The move worth avoiding is standardising a whole organisation on one agent because it won a benchmark, then discovering that the CI pipeline and the pair-programming session had opposite requirements all along. Running two agents is not indiscipline. It is what the billing models are asking you to do.

What we would do this week

Install it, because it costs a shell command and you learn more from an hour of use than from a week of comparison tables. Point it at a real repository rather than a toy one — the large-code-base claim is the specific claim, and it is the one worth testing.

Then measure four things, in this order. Cache-hit rate on input tokens, because it moves the price more than anything else on this page. First-pass success on your own code, because Terminal-Bench does not describe your repository and Meta's number is not yet independently confirmed. Concurrency, because persistent parallel subagents spend money while you are reading something else. And your true tasks-per-engineer-per-month figure, because that single number decides the metered-versus-subscription question and almost nobody has measured it.

Keep the approvals and the sandbox on. They are on by default for a reason, and an agent that spawns parallel workers into multiple worktrees is not the tool on which to discover what your shell aliases do under automation.

The honest summary is that Meta has not built the best coding agent, and has said so with unusual clarity. What it has built is one of the first serious terminal agents priced for workloads that a per-seat subscription cannot serve — unattended, bursty, automation-driven work where the customer is a pipeline rather than a person. If that describes your workload, the 3.8-point benchmark gap is a rounding error against the structural fit. If it does not, and you have twenty engineers with an agent open all day, you already have the right answer and this launch has not changed it.