# Wonder and Wonder Full launched through different access paths

How Muse Wonder and Wonder Full's initial access routes require a variant-by-surface matrix rather than one family-wide availability claim.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-10-12
Original announcement: https://about.fb.com/news/2026/10/introducing-muse-wonder-models/
Canonical URL: https://retrivium.ai/retrospectives/wonder-full-access-matrix/

## A family announcement contained different routes

[The September 2, 2026 Spark 1.3 release](https://research.meta.ai/blog/introducing-muse-spark-1-3) and [September 8 Muse introduction](https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/) preceded [the October 12 Wonder announcement](https://about.fb.com/news/2026/10/introducing-muse-wonder-models/). The family did not launch every variant through every surface. Its initial access description can be represented narrowly:

| Variant | Announced initial surface |
| --- | --- |
| Wonder | Meta Model API and Muse Code |
| Wonder Full | Muse Code subscribers |

The same announcement described later Muse product rollout as forthcoming. That is a roadmap statement, not a completed deployment observation.

## A model name does not identify the interface

An illustrative team evaluates Wonder through an API integration and sees an appealing demonstration of Wonder Full in a coding product. Those are not interchangeable observations. The product may provide tools, state and review behavior that the team's integration does not have. The larger variant's presence in that product also does not establish an API endpoint for it. A selection record should therefore include variant and surface together, preserving the actual system that the team can evaluate rather than a generalized family label.

## Access and suitability remain separate

A supported access route is a prerequisite for direct testing, not evidence that the model suits a particular workload. Conversely, a promising published capability does not create access through a desired interface. A planning discussion can retain both facts without inventing local results for an unavailable combination. This avoids an architecture that depends on an assumed endpoint or a product behavior the application cannot reproduce. The distinction is about the evidence needed for a decision, not a recommendation to choose one variant over the other without evaluation.

## An illustrative access matrix

A practical evaluation record lists each candidate variant beside the intended surface, observed account access and task-specific test status. A row can remain untested even when a related row has strong results. If availability later changes, the row receives a new dated observation rather than inheriting the sibling's score. No account entitlement or future schedule is asserted here. The artifact makes uncertainty visible and prevents a family-level announcement from silently becoming proof of a particular integration's readiness.

## Preserve the launch boundary in later summaries

The October event is meaningful because it introduced a new family with specific initial routes and future product intentions. A later expansion would add to that history rather than change what was initially announced. The retrospective lesson is to make availability a matrix of variant and surface, with direct observations distinguished from plans. That lets readers understand which comparison was possible at the time and which remained a hypothesis, while avoiding unsupported claims that every named model was immediately available everywhere.

## Related reading

- [Recording integration availability](/journal/provider-api-contract-deprecation-migration/)
- [Separating tested system variants](/journal/inference-benchmark-method/)