I would choose access before the leaderboard: a score cannot deploy an unavailable model. A beginner can make this decision without predicting GPU memory or memorizing benchmark names. First ask where the model will run, what it may read, and who may approve its actions.
Meta introduced Muse Wonder and Wonder Full on October 12, 2026. Both target work involving several steps, but they do not share every access path. Meta’s launch announcement establishes the release; the product documentation defines what developers can use.
An API—an application programming interface—is a way for your software to request a model response. Muse Code is a coding product with its own tools, plan rules and settings. Ordinary Wonder is available through both; Full is limited to qualifying Muse Code subscriptions. They are not simply two GPU sizes you can interchange behind an application.
- Choose the accessible product and model variant before comparing scores.
- A model proposes; an agent’s surrounding software supplies tools, state and permissions.
- Count all attempts and check the active data-use mode, not just the token rate.
- Use a small controlled task to inspect results, corrections and approval boundaries.
First, separate a model from an agent
A model turns supplied information into a response. An agent is a system that repeatedly asks a model what to do, runs permitted tools, and feeds the observations back. The model might suggest reading a file; the surrounding software decides whether that file is accessible and performs the read. The same distinction applies when a model proposes a code edit, a browser action or a message.
The harness is that surrounding software: prompts, tools, state handling, validators and stopping rules. A validator is a check of the result, such as a test suite or an invoice total. Changing the harness can change the outcome even when the model name stays the same. Figure 1 makes this separation visible.
Read Figure 1: Follow the loop above the approval boundary; proposing and executing are separate.
A concrete starting example
Imagine a small test repository in which a function adds invoice lines but forgets tax. Supply a fictional invoice, the expected total and a test that currently fails. An agent reads the allowed files, proposes a patch and runs the test. Passing the test establishes that particular check, not that every business rule is correct. A reviewer still inspects the diff before a merge. This is an illustrative workflow; Tech Trend Insight has not run a Muse Wonder trial.
The question is now concrete: can the configuration you can actually access complete this task under the same rules as your current tool? That is more useful than asking whether the family name is generally intelligent.
Access determines which model is under evaluation
Start with the documented model availability and Muse Code plan rules, not an assumed hardware tier.
The October 12 launch made Wonder available through Model API and Muse Code, while Full reached Muse Code subscribers. Announced future consumer experiences are not evidence of current access for every account.
The developer documentation adds the operational distinctions:
| Requirement | Surface | Available model | Evaluation consequence |
|---|---|---|---|
| Model behind a custom application | Meta Model API | muse-wonder-1.0, Standard mode only |
Test ordinary Wonder directly |
| Coding workflow using pay-as-you-go or any Muse Code plan | Muse Code | Muse Wonder | Do not inherit Full’s results |
| Coding workflow on a qualifying subscription | Muse Code Power Usage or Maximum Usage | Muse Wonder Full | Treat Full as a separate product choice |
Meta expressly states that Wonder Full is not offered through Model API. It also states that selecting max reasoning on ordinary Wonder does not select Wonder Full.
Read Figure 2: Choose your product path first, then see which model it reaches.
What muse-wonder-1.0 exposes through the API
Meta’s current model catalog defines the following interfaces and capabilities.
Meta documents muse-wonder-1.0 for complex software engineering and long-horizon agentic work. The API contract includes:
A token is a piece of text counted by the service, not necessarily a word. The context window is how much supplied information a request can contain. Reasoning effort controls work by the selected model; it does not select Full. An endpoint is the interface your application calls.
- Inputs: text, images, video, audio, and PDFs
- Output: text
- Context window: 1,048,576 tokens
- Reasoning effort:
minimalthroughmax - Capabilities: tool calling, structured output, search grounding, and computer use
- Endpoint families: Responses, Chat Completions, and Messages
These are documented interfaces and capability claims, not proof that an existing agent will retain its completion rate, recovery behavior, latency, or cost after a model-ID change. Meta’s model card warns that prompts, tools and the surrounding software can affect performance. Its general caveats about numerical precision do not establish a supported local Wonder checkpoint.
Availability can also vary by country. A hosted service may change, so preserve a small regression sample and repeat it after a model, prompt or tool change.
Tool calling proposes an operation to the application; structured output follows a requested data format. Search grounding adds retrieved web material. These features need independent checks. A large context window does not promise permanent memory.
Pricing and data treatment belong to the surface
The following rates are from Meta’s published pricing, checked October 14, 2026.
For pay-as-you-go muse-wonder-1.0 in Standard mode, Meta lists the following rates:
| Meter / Resource Component | Unit Price (Standard Mode) |
|---|---|
| Input Tokens | $4.00 per 1M tokens |
| Cached Input Tokens | $0.20 per 1M tokens |
| Output Tokens | $20.00 per 1M tokens |
| web_search Grounding | $2.50 per 1,000 queries (+ token charges) |
Meta says there is no separate long-context premium: the same token rates apply whether the context window is lightly or heavily used.
These prices apply to the API-accessible Wonder model, not to Wonder Full. Long-running agents can accumulate repeated context, tool observations, retries, and generated output, so teams should record total cost per completed task, cache usage, and grounded-search calls rather than comparing input-token prices alone.
Artificial Analysis estimated $4.52 per Intelligence Index task for ordinary Wonder at maximum reasoning in its October 12 evaluation. That number reflects Artificial Analysis’s workload and reported average token use; it is not a general cost estimate for coding, browser, or document agents. The evaluator did not publish a per-task cost for Wonder Full because Full is not priced through a public per-token API.
A bill small enough to check by hand
A token is a piece of text counted by the service, not necessarily one word. Input is what you send; output is what the model generates. Cached input is eligible repeated content served at its own rate. Use the reported usage categories rather than guessing which text was cached.
Assumed example: one call uses 20,000 uncached input tokens and 2,000 billed output tokens, plus one grounded-search query. At the published Standard rates, input is $0.08, output is $0.04 and search is $0.0025. The total is $0.1225, before taxes or other charges. Three identical attempts cost $0.3675. This arithmetic is not a measured success rate, latency or invoice.
Read Figure 3: Compare bar lengths on the same dollar scale; the inputs are declared assumptions.
If two of ten hypothetical tasks fail, keep their charges in total spend. Dividing only the successful attempts’ bills by eight hides the cost of failure. Record the original task count, accepted results, paid attempts and elapsed time separately; do not choose a model by making its acceptance rules easier.
Standard and Contributor modes are different data-use choices
Check the subscription data-mode setting before supplying real material. Training use and retention are separate questions.
For Wonder on Model API, Meta documents Standard mode only. Under Standard mode, prompts, code, files, context, and model responses are not used to train Meta models.
Muse Code subscriptions instead default to Contributor mode. Meta says Contributor mode provides more usage in exchange for permission to use submitted content and resulting responses to train future Meta models. Users can turn it off; future content is then not used for training unless they enable the setting again. Wonder and Wonder Full can each run in either mode on plans that include them.
For proprietary repositories or confidential documents, an evaluation record should therefore identify:
- The API or Muse Code surface
- The exact model selection
- The subscription plan
- Standard or Contributor mode
- The setting’s state during the run
“Tested Muse Wonder” is not sufficient provenance—a record of where the result came from.
The benchmark score belongs to the variant and harness
Artificial Analysis reports 52 for Wonder and 56 for Wonder Full on its Intelligence Index v4.3 at max reasoning. The index combines several tasks; it is not a percentage of a company’s jobs completed. Evaluator’s original report.
Read Figure 4: Read the axis as index points, then check which variant produced each bar.
A four-point index lead does not mean four fewer failures in every hundred tasks. The task set, scoring method and product must match before drawing that conclusion. For example, a coding assistant can produce plausible code yet fail the one regression test that matters to your application.
Meta’s model card distinguishes controlled coding comparisons from external results using other harnesses. An external score may include a different tool environment or reasoning setting. Preserve those conditions rather than merging every result into a universal ranking.
The procurement implication is straightforward: a leaderboard row should be stored as:
model variant + reasoning effort + benchmark version + agent harness + grader + result source
If any field is missing, the score is weak evidence for a deployment decision.
Active Memory and Active Focus are model claims, not an API storage specification
Meta defines Active Memory as carrying important context across conversations and retrieving details relevant to the current task. It defines Active Focus as continuing toward a difficult goal by trying alternatives, working through blockers, adapting to new information, asking for clarification, and checking in before important actions.
Those descriptions establish Meta’s intended model behavior. They do not, on their own, document a durable persistence layer for every muse-wonder-1.0 integration.
The reviewed Model API page specifies inputs, context length, endpoints, reasoning levels, tools, and availability, but it does not describe API-managed cross-conversation storage, retention duration, authorization, deletion, or correction semantics for Active Memory. Until those mechanisms are documented, API teams should distinguish among:
- State resupplied by the application
- State retained by a product or agent harness
- Information inferred or recalled by the model
- A documented persistent-memory service
Conflating these categories can make a successful demonstration appear to prove persistence that the API contract does not specify.
Read Figure 5: Follow the fact from creation to correction and revoked access.
Known limitations affect agent deployment
Meta’s model card says Wonder may produce inaccurate, biased, or objectionable responses; make multi-step reasoning errors, especially in novel scenarios; and struggle with visual or spatial reasoning, particularly 3D tasks. It also warns that performance can vary across languages and with numerical precision, runtime configuration, prompts, tools, and the surrounding software.
The card recommends application-specific evaluation and additional system guardrails. For agents that can take real-world actions, Meta specifically recommends human-in-the-loop confirmation for irreversible actions.
Aggregate completion rates do not reveal whether an agent made an unacceptable intermediate action, disclosed the wrong information, or bypassed an approval step. Production testing must therefore inspect action traces and failure severity, not only final-task success.
Proposed deployment validation
The following is a proposed editorial test plan, not a completed experiment or a Meta certification. Start with a small safe task and add complexity only after you can inspect its result.
1. Freeze the comparison object
Record for every run:
- Exact model ID or Muse Code model selection
- API or Muse Code surface
- Subscription plan and data mode
- Reasoning effort
- Agent harness and tool versions
- Prompt, source files, and granted permissions
- Cache state and search-grounding use
- Retry policy and stopping rule
This prevents ordinary Wonder, Wonder Full, and incumbent-model results from being merged under a generic “Muse Wonder” label.
2. Replay matched workload samples
Use identical source material, tools, permissions, and completion criteria for each candidate:
- Coding: repair a multi-file defect, run the same test suite, and produce a reviewable patch.
- Browser or computer use: complete a controlled multi-step task containing an unavailable path or changed condition.
- Document work: synthesize supplied documents while preserving citations, corrections, and conflicting facts.
For each run, collect task completion, failed assertions, unsupported statements, incorrect actions, clarification requests, retries, elapsed execution, token use, cache utilization, search calls, and billed cost.
3. Isolate the memory claim
In an authorized test environment, introduce a fact, add distractors, and later replace it with a correction. In a subsequent session, request the current fact and its provenance.
The result should identify whether the answer came from application-supplied state, the Muse Code harness, another persistence component, or apparent model recall. The test should also examine correction, deletion, and revoked access. Without that separation, the run cannot establish that Model API itself supplies durable Active Memory.
4. Test confirmation before consequential actions
Classify external messages, repository merges, destructive commands, purchases, and other irreversible writes as confirmation-required. Then inspect whether the agent:
- Recognized the action category
- Requested approval before execution
- Preserved the control during retries
- Asked for clarification when conditions changed
5. Rerun after model or harness changes
Keep the test corpus, expected results and permission rules. Repeat them after changing the hosted model, prompt, tool version, reasoning setting or product configuration. A successful launch-week run is evidence for that configuration, not a permanent guarantee.
Read Figure 6: Follow the gates, including the failure path; a successful output still needs action approval.
Decision rule
If the workload must run behind an application API, evaluate muse-wonder-1.0. Wonder Full’s scores describe Wonder Full, not the API-accessible variant.
If the workflow can remain inside Muse Code, test Wonder Full separately on Power Usage or Maximum Usage. Include the subscription boundary and active Standard or Contributor setting in the result.
Approve either option only when the configuration that will actually be deployed meets predefined thresholds for:
- Workload completion and failure severity
- Total task cost, including cache and grounded search
- Permitted training-data treatment
- Memory provenance, correction, and authorization
- Confirmation before consequential actions
- Stability under the production agent harness
The defensible comparison unit is not the “Muse Wonder” name. It is the model variant, reasoning setting, product surface, harness, data mode, and control policy that production will use.
Practical FAQ
Can I call Wonder Full by setting reasoning to max?
No. Reasoning effort controls how the selected model works; it does not select another model. The documented API path remains ordinary Wonder. Full belongs to qualifying Muse Code plans.
Do I need to buy GPUs for this comparison?
The documented Wonder paths are hosted Model API and Muse Code, not a published self-hosting setup. Do not invent GPU-memory requirements or assume that a quantized local checkpoint is available. Test the product you are actually authorized to use.
Does Standard mode mean nothing is ever stored?
Not used for training is narrower than not retained anywhere. Check the applicable product terms and retention controls separately. Do not submit a private repository merely because a model benchmark looks strong.
What is the smallest useful first test?
Use a fictional invoice or a small test repository with a known expected result. Run the same task through each available candidate, record every billed attempt and check both the final answer and the action trace. This teaches more than a leaderboard alone.
Sources
- Meta AI Research: Muse Wonder announcement and Active Memory/Active Focus definitions
- Meta AI Research: Muse Wonder Model Card
- Meta Model API: Models and Muse Wonder availability
- Meta Model API: Pricing and rate limits
- Meta Model API: Muse Code subscriptions and Contributor mode
- Artificial Analysis: Muse Wonder and Muse Wonder Full launch evaluation