Muse Wonder Full isn't the model in the API

Meta launched Muse Wonder and Muse Wonder Full on 12 October 2026, but the stronger Full model isn’t available through the Meta Model API. It requires a qualifying Muse Code subscription. That changes how I read the launch: Full’s best results can justify testing Full, while an API integration needs evidence about the Wonder model it can actually call. [1] [2]

Can you use Muse Wonder Full through the API?

No. Meta Developers explicitly says that Full is available only through Muse Code subscriptions, and that choosing max on ordinary Wonder does not select it. The API model is muse-wonder-1.0. Full is a higher-capability variant with a different access route, not another name for Wonder’s highest reasoning setting. [2]

This distinction matters before any benchmark comparison. If I am choosing a model for an existing API agent, the Wonder column is the relevant starting point. If I am choosing a terminal agent and willing to subscribe, Full belongs in the comparison, together with Muse Code’s tools and limits.

The subscription is also tied to the Muse Code credential created during onboarding. Meta’s subscription documentation says that this credential is for Muse Code only; additional API keys are billed separately on pay-as-you-go. Buying the plan doesn’t turn Full into a model for an arbitrary API client. [6]

That is a more useful distinction than treating this as another version of Muse Spark 1.3’s launch and benchmark confusion. Here, Meta documents the split clearly. The reader still needs to keep the two model names attached to the right results.

What do the Muse Wonder benchmarks actually show?

The difference between Wonder and Full is small on one coding test and larger on another. Meta Developers reports almost identical DeepSWE 1.1 results, while Full leads by 4.4 percentage points on SWE-Marathon. That supports looking at the tasks individually rather than assuming that every Full result describes a large upgrade. [3]

Full’s lead is 0.2 percentage points on DeepSWE, compared with 4.4 on SWE-Marathon. I wouldn’t use the first gap to argue for a meaningful advantage without uncertainty estimates or repeated runs. The second gives me a more specific reason to test Full on a substantial project that takes many steps to finish.

Meta’s model card explains why the rows need separate readings. DeepSWE 1.1 contains 113 tasks across 91 repositories, graded with functional and regression tests. Meta attributes the Wonder and Full results to Datacurve. SWE-Marathon instead measures substantial projects with executable project tests, and the card attributes that row to Abundant AI. [4]

The same card says that SWE-Marathon’s competitor results use products such as Codex and Claude Code, so the whole row is not a controlled comparison using one shared harness. A harness is the software around the model: its tools, instructions and execution loop. That doesn’t erase the results, but it changes the question they answer. They compare evaluated systems, rather than isolating model quality. This is the same issue behind similar benchmark scores hiding different practical capabilities. [4]

How much does the Muse Wonder API cost?

Meta Developers lists Wonder at $4 per million uncached input tokens, $0.20 per million cached input tokens and $20 per million output tokens. There is no Contributor mode discount for Wonder on the API, and the published pricing applies without a long-context premium. These are Wonder’s rates, not a token price for Full. [5]

A hypothetical request with 100,000 uncached input tokens and 10,000 output tokens costs $0.60: $0.40 for input plus $0.20 for output. If the entire input qualified as cached, the same token counts would cost $0.22. Those examples exclude separately billed tools and any further requests. Meta prices web search grounding at $2.50 per 1,000 queries, on top of token charges. [5]

For an agent, the useful cost comes from the whole attempt. Repeated tool calls send more context, unsuccessful approaches consume tokens, and a correction can require another run. A price list tells me what the tokens cost. It doesn’t tell me how many tokens Wonder will need to deliver a change I can accept.

I therefore wouldn’t attach Wonder’s API rates to Full’s strongest score and call the combination a bargain. That joins the result of one model to the price of another. Nor would I divide a monthly subscription price by an assumed task allowance: the result would depend on actual usage and the plan’s limits. The distinction between token prices and measured task cost also matters in the GPT-6.1 Sol comparison.

Does Active Memory replace context management?

Meta AI Research describes Active Memory as carrying relevant information across conversations, while Active Focus describes continuing toward a goal through blockers and changes. Those are useful capabilities to evaluate, but the descriptions alone don’t tell me how a particular API agent will preserve its project state. [7]

The integration still needs a clear answer to a practical question: what information will the model receive when work resumes? A model that can retrieve a requirement is helpful only if the system stores that requirement and makes the right information available. I would test that with a changed requirement and a conflicting older note, then inspect which one the agent follows.

That is why I would keep explicit context management for coding agents in place while testing Wonder. A large context window and a memory claim do not make a repository’s current instructions, accepted decisions or unfinished work self-evident. The useful outcome is an agent that resumes with the right constraints, not one that merely recalls a sentence.

What would make Full worth a subscription?

Full would earn its place for me by finishing difficult work with less correction than the API-accessible alternative. The larger SWE-Marathon gap gives me a reason to test that on long tasks, but I would measure accepted results and elapsed time before assigning it a role.

I would start with a known repository change, keep the starting commit and acceptance tests fixed, and record both failed attempts and successful ones. For Wonder through the API, I would keep token and tool charges. For Full in Muse Code, I would record subscription usage, waiting and the edits I had to make afterward. That preserves the difference between the model I call and the product I subscribe to.

Before putting private code into that trial, I would also check Contributor mode. Meta’s subscription documentation says it is on by default and allows training on submitted content in exchange for more usage. It can be turned off, and Full remains available on qualifying plans in either mode. That choice belongs in the trial setup because it changes the terms under which the code is processed. [6]

My first question for any impressive Muse Wonder result is therefore the exact model name. Once that is clear, I can choose a test that matches the access I actually have and find out what it costs to finish my work.