Meta’s Muse Wonder Full: A Coding Agent Tested Against Opus and Sol

Meta has released Muse Wonder Full, and after testing it early I think the company has a model that can compete with the leading coding agents. That does not mean it wins every benchmark or that I would abandon the tools I already use. It does mean there is another serious option worth examining.

I know people will wonder whether Meta paid for this opinion. It did not. I got early access, and the video has a separate sponsor, but my assessment comes from the work I ran with the model.

There are two versions with confusingly similar names: Muse Wonder and Muse Wonder Full. The ordinary Wonder is faster, around 120 tokens per second in my experience; Full is closer to 50. They are not interchangeable when interpreting the examples that follow.

The standard model has an API price, but Full is available through a subscription and did not have published API pricing when I made this video. The subscription is inexpensive compared with many alternatives, but I have not established its usage limits. That makes an overall cost comparison premature.

For standard Wonder, the listed price is $4 per million input tokens, $20 per million output tokens, and $0.20 per million cache reads. Those figures apply to the standard model, not to Full. I am much more interested in what Full can actually do than in the naming.

The first weakness is 3D. In the tractor and Fish Slap examples, the game mechanics can work while the three-dimensional objects look bad. Meta itself acknowledges that spatial 3D work is a weak point, so a polished interactive game demo is not the reason to choose this model.

I suspect some labs have access to a similar specialized training environment or dataset for 3D tasks. That is speculation, but it would help explain why a model can be strong in general coding and still fall behind on this particular kind of demo. A single visual test should not stand in for general intelligence.

The value proposition also depends on how much the subscription allows you to use Full. I cannot yet tell you where the limits are, so treat the attractive price as an incomplete piece of the decision rather than a measured cost per task.

On my SkateBench naming test, Full scored about 95%, while standard Wonder was around 81%. The screenshot is a snapshot of a run in progress, and this benchmark measures a narrow naming task. It is useful evidence, but it is not a complete ranking of coding ability.

If your main goal is beautiful user interfaces or 3D visual polish, my examples are less encouraging. The more interesting results appear when I give the model a real repository, ask it to investigate, and read the reasoning and changes it produces.

I asked it to audit a slow Thunderstore mod index. Its response separated the healthy CDN behavior from the less effective index caching, then ranked concrete issues. The report was short and readable, which matters when the purpose is to act on findings rather than admire a long answer.

My usual AGENTS.md asks models to accommodate my ADHD and use short, simple English. Without that instruction the model can be more verbose, but even so I found its writing distinct and easy to follow. I had expected a Meta model to sound more like Claude; this one often does not.

I also tried the models on Lust, a Rust project, by running tasks with Muse and Opus and asking a panel of judges to compare the changes. This is a small experiment with model judges, not a controlled measurement of every task the models might do.

In one comparison, the judges preferred the Opus result, 41 to 30, and Opus's result was about two and a half times faster. Muse's version had a bug. That is an important counterexample to an overly simple story that Full always matches the best alternative.

Across the work, Muse was nevertheless producing many of the landed changes, including useful tests, reviews, and fuzzing probes. I found it useful to have the models exchange plans: Opus could take on a riskier design while Muse handled more conventional fixes and review work.

Both quality and speed depend on the particular assignment, and we still lack Full's API price. One model's own grade of another model is interesting to read, but it is not an independent cost or quality measurement.

Full also feels like a good commander for other agents. I value delegation that asks workers to read the actual code and return evidence, rather than treating a search snippet as proof. The way it assigns work and synthesizes the results has been pleasant to use.

There is a subjective trap here. Like someone reviewing speakers who gets excited by a new sound, I may like the model's different writing style partly because it is unfamiliar. I want to distinguish that preference from evidence that it actually makes better engineering decisions.

After a few days, it has also seemed to make fewer silly mistakes in my own work. That is a personal observation over a short period, not a published error rate. You can use different models together instead of forcing every assignment through one of them.

One remote-update bug illustrates why I like its approach. I had multiple agents investigate the same problem. Opus needed some direction but found the issue and opened a pull request; that was a legitimate, useful outcome.

In my run, Sol dropped the important qualifier that the check concerned new servers and removed an npm check, leading it toward the wrong behavior. It also encountered a question-tool proxy error. These are observations from this run, not a claim that the model always fails this task.

Muse traced the failure to an HTTP request: trace headers were triggering a CORS preflight. It also found an existing pull request removing those headers, so it reported the cause without adding new code in its worktree. That concise diagnosis avoided creating a competing change unnecessarily.

In my informal T3 architecture evaluation, Opus led and Full was close to Astra, while standard Wonder performed considerably worse. The judges can favor themselves or models in their own family, and none found everything. These scores describe this test setup, not an objective universal leaderboard.

The Lakebed evaluation was less favorable to Full: I saw roughly 5.75 for Full, compared with 9 for Sol and about 8.5 for Sonnet. A different benchmark changes the ordering, which is exactly why I would not use a single score as a purchasing decision.

In a TypeScript-to-Rust task, Full was around Fable's level in the comparison while finishing faster, at roughly 17 minutes. Again, without Full API pricing, speed and token counts do not tell us the dollar cost of completing the work.

The token-efficiency figures I looked at were close: approximately 53,800 tokens per task for Full and 54,200 for standard Wonder. That similarity is useful context, but it does not prove that the two versions cost the same or that either is cheaper than a competitor.

For another comparison, I reviewed findings from eight pull requests. Opus reported 23 findings, of which I counted 21 valid, one possible and one wrong, plus eight nits. Sol reported nine findings, seven valid and two invalid, with no nits.

Muse reported 16 findings, including five novel ones and a few higher-severity issues. Some findings overlapped with the other models. This is a small sample and the validity judgments are mine, but it shows why multiple reviewers can complement each other.

I then asked the models to prioritize work on T3. Opus used ten delegates and took about half an hour; my interrupted Muse run was roughly 17 minutes in total. The timing is approximate, but the output is useful to compare as a real planning exercise.

The basic theme in the recommendations was reliability: fix the issues that make existing features fail before piling on more features. That is a more useful prioritization principle than counting how many ideas an agent can produce.

Muse organized the investigation around claims and critics, including attempts to disprove the highest-priority claims. I liked that its synthesis was direct: it made the order of work and the supporting evidence easier to inspect.

For example, it recommended sampling the pull-request backlog before judging it, and addressing quota and payload consumption. The point is not that every recommendation must be accepted; it is that an agent should show enough of its reasoning for a human to evaluate the priorities.

It also distinguished root causes, such as scope-related stranding, from per-scope patches, and separated simpler priority-one work from the larger structural issues. I found this report easier to read than the alternative, though that readability preference is subjective.

My conclusion is that Full is a real, usable model. I still prefer Opus for the hardest work and for review in many cases, and Full has obvious weaknesses. But the fact that its strengths show up in actual repositories, delegation and investigation makes it worth trying.

I do not have enough information about Full's usage limits or eventual API price to recommend canceling a Claude subscription. Try it against your own work, compare the results and limits, and keep the tools that actually help. More capable competing labs are good news for developers.

The useful question is not whether a new model has won forever. It is where its strengths and weaknesses show up in practice, how reliably it handles the tasks you care about, and whether its eventual price makes sense for that work.