Meta's Muse Code: cheap, fast, and wrong in interesting ways

A new coding agent, and the number that matters is not the benchmark

Meta has released Muse Code in beta: a terminal coding agent aimed at large repositories, powered by a coding-focused model called Muse Spark 1.2. Anyone who has used a modern agentic CLI will recognise the shape of it immediately, down to the way it reads local skills and rules from disk.

The published benchmarks do not put it in first place anywhere, and the comparison set is conspicuously selective. That is less damning than it sounds. We have spent enough time with cheap, fast models to know that leaderboard position and daily usefulness are only loosely related. The genuinely interesting numbers here are the price and the throughput.

What it claims to do

The pitch is built around scale, which fits a company that famously rebuilt its version control on Mercurial rather than accept Git's performance at their repository size. Three claims stand out:

• Persistent background agents that stay alive for the session and accumulate context, instead of starting cold on every task.

• Parallel fan-out into isolated worktrees, so several sub-agents can work at once without touching your checkout or colliding with each other.

• An append-only event log written before every model call, tool run and edit, so a crash resumes exactly where it stopped rather than losing the work.

That third one is the most quietly sensible feature in the release, and the one we would most like to see everywhere else.

The pricing is the actual product

Standard pricing sits at roughly $1.25 per million input tokens and $4.25 per million output. Then there is the contributor tier: about 10 cents in and 20 cents out, a gap of ten to twenty times, in exchange for Meta keeping what you send. Measured on the commonly cited independent intelligence index, the model lands around 54, up meaningfully from earlier releases in the same line, roughly level with the upper mid-tier and clearly behind the current frontier.

Speed is where it separates itself. Observed throughput through OpenRouter averages near 190 tokens per second, several times what most frontier models deliver. Combined with the contributor price, the cost per unit of work is close to a rounding error.

Fast, and confidently wrong

In practice the split is stark. A codebase architecture summary in under thirty seconds. A small game rebuilt in 2D in under three minutes and in 3D in under five, where a frontier model took over an hour. Both builds were broken: camera controls inverted, movement wrong, no understanding that objects collide. Several correction passes did not fully fix them.

Worse, asked to research the CLI it was itself running inside, it latched onto an unrelated product from search results and ran an entire investigation on that assumption before admitting the target was wrong. Its integration plan for a real codebase scored roughly 4.8 out of 10 against about 7 for a frontier model in independent review, and the implementation it eventually produced did not work.

It has learned how to act like a modern agent without having learned what modern agents know.

Where it genuinely earns its keep

One result reframes the whole model. Pointed at a repository's open pull requests, it indexed and reviewed 222 of them in under five minutes for about ten cents, producing a prioritised list with clickable links, merge-conflict status and per-item confidence scores. That is a better artefact than several more expensive models produce without being nagged into it.

The lesson is that this is not a model for shipping code. It is a model for code-adjacent analysis: triage, categorisation, log spelunking, summarising, pulling signal out of noise. Work where being wrong occasionally is cheap and being fast is worth a lot.

How we think about this at Birdhouse

Three things we take from this release:

• Route by job class, not by leaderboard. The expensive model earns its price on work that has to be merged. Triage and summarisation do not need it, and paying frontier rates for them is waste.

• A discount paid in source code is a governance decision, not a billing one. A ten to twenty times saving is real, but client code cannot go to a training tier because it is cheaper. That call belongs to the client, in writing, before anyone installs anything.

• Reliability beats capability at the margins. Aggressive rate limits, hit even on the paid tier while using the parallel sub-agent feature the product is built around, do more damage to a workflow than a few benchmark points ever will.

The closed-source CLI and missing SDK make this hard to fold into an existing setup, which is a strange choice from a company whose reputation was built on giving tooling away. Still, the direction is right, and a model this cheap and this fast changes what is worth automating. Not the merge. Everything around it.