Meta launched Muse Wonder, but its strongest model is not in the API

Meta announced Muse Wonder and Muse Wonder Full on October 12, 2026. Muse Wonder became available that day through the Meta Model API and Muse Code, while the more capable Full version was limited to paid Power and Maximum Muse Code plans. Meta says the standard Wonder model will later reach its Muse personal agent, starting with subscribers.[1][5][6]

The interesting part is not the claim of a new benchmark leader. Meta is distributing one model family through three different doors: an API for builders, a subscription coding product, and Muse for consumers. Its strongest version does not pass through all three. Access, data use, and product boundaries now matter as much as technical capability.

This article is based on Meta's announcement, model page, and live product documentation. I have not run Muse Wonder on my own task set. The benchmark figures are results published or relayed by Meta, not an independent comparison I performed.

This is really three product launches

Muse Wonder is available in the API as `muse-wonder-1.0`. It has a one-million-token context window, accepts text, image, video, audio, and PDF input, and returns text. Meta Model API pricing is $4 per million input tokens, $0.20 for cached input, and $20 for output.[2][3][4]

Muse Wonder Full belongs to the same family but not the same distribution channel. It is not available through the API. It is limited to Muse Code's $50-a-month Power Usage plan and $200-a-month Maximum Usage plan. Meta's model page says those plans provide 20 and 80 times the Everyday Usage allowance, respectively.[2][5]

The third layer is Muse. Meta says Wonder will soon power personal-agent experiences there, with subscribers first in line.[1] One launch therefore creates a premium tier for API revenue, developer subscriptions, and consumer subscriptions.

The distinction matters: saying "I can use Muse Wonder" does not mean I can embed Meta's strongest announced version in a product through an API. You can try Full inside Muse Code, but you cannot currently deploy it through the general Meta Model API.[3]

What does it mean to keep the strongest model inside the product?

Meta says Muse Wonder Full tops some coding leaderboards, including third-party runs of DeepSWE and SWE-Marathon. The broader table on the model page mixes internal composite evaluations with external tests.[2][5] Those results can help decide what deserves a pilot, but they do not settle a product decision.

Access is the reason. Full's claimed advantage is available inside Muse Code. A team that wants to embed a model in a customer application, build its own agent layer, or manage execution through its own infrastructure gets standard Wonder instead. The highest score and the model you can call in production are not the same thing.

This resembles the decision about where local and cloud agents should run. Capability matters, but so do the execution location, audit record, and intervention points. Keeping Full inside Muse Code suggests that Meta is packaging its most expensive capability as an advantage of its own working environment rather than as general infrastructure.

That is not automatically a bad trade. A provider may offer a more coherent experience when the model and working environment were developed together. Portability is the cost. If a pilot succeeds but the same model cannot move into your product, you may have proved the wrong thing.

Data choice is now a product mode

The more consequential detail sits in Meta's data-use documentation. In Standard mode, Meta says the prompts, code, files, context, and model responses are not used to train its models. Muse Code subscribers can also choose Contributor mode, which gives more usage in exchange for permission to use their content to train future Meta models. Contributor mode is on by default for subscribers, although users can turn it off in settings.[3]

API access to Muse Wonder is Standard mode only. Contributor mode is not available for pay-as-you-go Wonder.[3] That makes the API data boundary look simpler. Still, "not used for training" should not be stretched into zero retention, a specific data-residency promise, or automatic compliance with every company policy. Those are different claims.

A settings check may be enough for a personal project. Company use needs a recorded decision: which accounts must stay in Standard mode, where Contributor is prohibited, and how a change will be detected. Setting boundaries around what enters an AI tool becomes product configuration here, not a vague privacy recommendation.

Active Memory needs a new acceptance test

Meta describes both models through Active Memory and Active Focus. The first carries important details across conversations. The second is intended to help the model try alternatives, recover from errors, and check with the user before consequential actions.[1][5]

Those features make sense for long tasks. They also create a new failure path: old, incorrect, or expired information may leak into the next job. More memory does not automatically justify less oversight. Teams need to test what the system remembers and where it pauses for approval.

I would not start the first pilot on a large repository or customer data. I would use a limited task set from the same starting state and measure three things:

1. Does the model finish the job, or merely work longer and create more review?
2. Is context carried from an earlier session accurate and still valid?
3. Does it pause before touching a critical file, external service, or publication step?

Measure the cost of accepted, completed work rather than token volume. For code, verify the output independently of the model's explanation. If the process itself is unclear, a longer-running model will not repair it; the work and approval boundaries need redesign.

What changes now?

For an independent builder, Muse Wonder has a low integration barrier. Meta says an existing OpenAI SDK client can start by changing the base URL and model identifier.[5] That makes it practical to test standard Wonder on a small, reversible task.

For teams, the decision has more parts. If you are building a product through the API, evaluate standard Wonder against your own acceptance tests. If you test Full in Muse Code, record the access difference before treating the result as evidence for an API deployment. For sensitive work, do not leave Standard versus Contributor mode to individual preference; make it workspace policy.

Muse Wonder is a substantial launch, but the more durable story is not Meta's highest reported score. The company is splitting capability by distribution channel and turning data contribution into a mode that buys more usage. Model evaluation now needs four questions at once: Which version can I access? Where can I run it? How may my data be used? Can I carry a successful pilot into my own product?