Muse Wonder: Access, Pricing and an Agent Trial Plan

Muse Wonder is worth evaluating for work that stretches across documents, tools and multiple rounds of revision. Start by choosing the surface you can actually use: Meta announced Wonder for its Model API and Muse Code on October 12, 2026, while Wonder Full was announced for Muse Code subscribers. The wider Muse rollout was still forthcoming. Those are different access promises, and a successful trial on one does not establish the capabilities or terms of another.

The practical buying question is whether this model completes your difficult tasks with less intervention at an acceptable total cost. That requires a bounded comparison with your current setup. The guide below separates verified access from advertised capabilities, explains the observed API prices and gives you a trial plan. It does not report an independent benchmark or a completed deployment.

Meta's launch announcement makes an important distinction: Muse Wonder is available through Meta Model API and Muse Code, whereas Muse Wonder Full is available to Muse Code subscribers. Meta says Wonder will reach more Muse experiences later, starting with subscribers. A developer evaluating an API integration should therefore begin with Wonder, rather than assume the Full variant is an interchangeable API option.

Write the exact product, account type and model selection into your trial record. For example, comparing an existing API workflow with a Muse Code session changes both the model and the surrounding agent software. That can still answer a useful product question, but it cannot isolate the contribution of the model. Keep a separate comparison if your real decision is whether to replace the whole coding environment.

An account showing a model name is the beginning of an access check. Confirm that the intended team can use it, that the required tools are supported and that the chosen deployment terms suit the workload. Avoid moving customer information into a personal trial merely because it is the quickest way to obtain a result.

Our October 13, 2026 check of OpenRouter's Muse Wonder listing found $4 per million input tokens, $20 per million output tokens and $0.20 per million cached-input tokens. Web search is listed separately at $2.50 per thousand calls. These are observed OpenRouter prices; they are not a subscription price or a claim that every access route has identical billing.

A useful budget records what a completed task consumed, including retries and intermediate work. A model that produces a longer answer may cost more without creating a better result. Conversely, extra reasoning may be worthwhile if it prevents an operator from rebuilding an incorrect deliverable. Compare accepted outcomes, with the acceptance rule fixed before the run, rather than comparing only the cost of the first response.

For a purely hypothetical text request using 100,000 uncached input tokens and 10,000 output tokens, those rates imply $0.40 plus $0.20, or $0.60 before tools and other charges. This is arithmetic, not a measured task cost. Cache eligibility, reasoning accounting and repeated calls can change the actual bill, so retain usage receipts when testing a real workflow.

The captured OpenRouter route lists a 1,048,576-token context window and text, image, video, file and audio inputs with text output. Its unusually large maximum-completion field should be treated as serving metadata to verify, not a promise that a useful response can fill the remaining window. An advertised input type also needs a working request through your selected endpoint before it becomes an integration requirement.

Long context and persistent memory solve different problems. Context is the information available within a request or session budget. Memory is information retained and retrieved across work. Meta's research post describes Active Memory as carrying relevant information across conversations. That description does not, by itself, specify the storage, deletion or access-control behavior of your own application.

Test a harmless preference and a later correction before using business records. Ask the system to apply the corrected preference to a new task, then inspect which value it used and why. A system that repeats the original preference confidently has not demonstrated useful memory. The same principle appears in our guide to where stored agent-memory copies survive: the surrounding storage design matters as much as recall.

• Test whether updated information replaces an earlier assumption.
• Record which memory behavior belongs to the product and which your application supplies.

Meta describes Active Focus as sustained work toward a goal, including trying alternatives, recovering from problems and checking with the user before important actions. Treat this as a capability to evaluate. Persistence is useful when the agent fixes a failing test; it is expensive when it keeps polishing an output that already meets the brief or repeatedly tries an unavailable integration.

A trial needs an explicit completion condition and a bounded recovery policy. For a small application change, define the behavior to add, the files it may alter and the checks that demonstrate success. Include an instruction about what to do if a required service is unavailable. A screenshot of a plausible interface should not satisfy an acceptance rule that requires a working submission flow.

Also define when the agent should return control. If it encounters an ambiguous business decision, the useful behavior may be a concise clarification with the evidence already assembled. Our missing-information guide explains this boundary. The trial should reward useful progress and appropriate questions, rather than uninterrupted activity for its own sake.

A harness is the software around the model: tools, instructions, permissions, memory, retries and the rules for checking outputs. Changing several of these at once can improve results while leaving the reason unclear. For a model comparison, hold them as constant as the endpoints allow. For a product comparison, disclose that the products supply different harnesses and judge the whole experience.

Choose tasks your team already understands well enough to review. One could involve revising an existing report from supplied evidence; another could require repairing a small application bug with a known reproduction. Include difficult but ordinary cases, such as a contradictory requirement or an unavailable source. Do not construct a set entirely from the vendor's strongest public demonstrations.

Keep the original prompt, inputs, model route, effort setting, tool permissions and output for each attempt. If an endpoint cannot reproduce one of the comparison settings, note the difference rather than silently substituting another. The aim is a decision your team can explain later, especially if the model or its default behavior changes after the trial.

• Compare the same task and acceptance criteria.
• Keep product-level and model-level conclusions separate.

Record whether the task passed, what the reviewer changed and how much work was needed to finish it. A binary pass/fail result is useful, but it can hide the difference between correcting a heading and repairing the underlying logic. Classify intervention by its consequence: presentation cleanup, factual repair, implementation repair or a decision that still required the operator.

Suppose two hypothetical agents both produce an acceptable report after review. One requires a wording edit; the other needs its evidence rebuilt because it mixed sources from different dates. Calling both runs successful loses the information that matters for deployment. Keep the initial artifact alongside the accepted version so the review burden remains visible rather than disappearing into the final document.

For coding work, inspect the behavior as well as the tests. An agent can make a test pass by weakening the assertion, changing the fixture or narrowing the feature. A reviewer should compare the final change with the original requirement. Our guide to choosing a frontier model provides the broader selection context; this trial supplies evidence about your particular work.

A capable model still needs the correct account, data scope and permission boundary. Keep read-only investigation separate from actions that create records or affect other people. For an initial trial, use disposable destinations and synthetic inputs where they preserve the behavior you need to test. This lets you inspect the whole action without turning an evaluation into an unplanned business operation.

For example, a proposed calendar change should identify the calendar, attendees and exact event before the system writes it. A tool response saying success should be followed by a read-back of the resulting event. The same approach applies to file changes and application configuration. A well-written final response cannot substitute for evidence at the destination.

The model's ability to ask before important actions is helpful, but the application must decide which operations require confirmation and what that confirmation covers. Follow the method in previewing an agent's changes: show the actual proposed difference, then ensure execution still matches it. Reusing approval after the target has changed defeats the purpose of the preview.

• Evaluate the result at the destination, not just in the conversation.
• Keep approvals tied to a specific proposed action and current target.

Make a narrow adoption decision first. If Wonder performs well on a repeatable report task, you have evidence for that task and the tested settings. You do not yet have evidence for autonomous finance work, unrestricted browsing or a different coding repository. Expand the trial when the new work introduces different tools, inputs or consequences.

A useful decision record names the chosen surface, the workloads accepted, unresolved failures, estimated operating cost and the person responsible for reviewing exceptions. It should also name the fallback when the model is unavailable. That fallback might be the existing workflow or a human operator; it need not be another model that has never been evaluated on the same task.

For teams moving beyond experimentation, our AI transformation service starts with the work and its acceptance criteria. Muse Wonder adds a credible new option to that evaluation. The strongest reason to adopt it will be a repeatable improvement in your own workflow, supported by preserved evidence, rather than the size of its context field or the confidence of its launch language.

• Start with one workload and an owner for exceptions.
• Re-evaluate after material changes to the model, tools or input distribution.