Meta’s Muse Wonder launch puts memory and sustained work at the center of its agent ambitions. Evaluating that proposition means looking beyond the announcement to the access options, test conditions, and deployment guidance.
Two models, different routes to access
Meta announced Muse Wonder and Muse Wonder Full on October 12. Its launch announcement presents them as its strongest models for personal and professional agents. The company also plans to bring Wonder-powered experiences to Muse, starting with subscribers. That rollout is prospective, rather than evidence that every Muse user already has the new capabilities.
The official API pricing page makes an important distinction between the two variants. Muse Wonder is available through the Model API and Muse Code. Its listed API rates are $4 per million input tokens, $0.20 per million cached input tokens, and $20 per million output tokens. Wonder Full is listed as a Muse Code subscription offering, without API prices. Both entries show a one-million-token context window.
Consequently, access to Wonder does not automatically mean access to Full. A developer comparing the family must first establish which variant a proposed integration can actually use. The pricing table also separates uncached input, cached input, and output: there is no single per-token price that captures all three. That distinction matters when comparing the cost of different workloads.
Memory and persistence need different tests
In Meta’s account, Active Memory retrieves relevant information from earlier conversations, while Active Focus supports continued work toward a difficult objective. Focus includes trying other approaches, adapting to new information, asking questions, and checking before important actions. These are related ambitions, but not interchangeable: remembering a preference does not establish that an agent can finish a complicated project safely. Meta describes long-running software work as one area where the capabilities come together. These descriptions are vendor claims, not independent findings. Source: Meta’s launch explanation.
The model card explains that MemoryBench is an internal evaluation using conversations of 64,000 to 100,000 tokens, including distracting material and updates to previously supplied facts. An LLM judge grades the answers. That is a more specific test than an unrestricted claim that an assistant will reliably remember everything across a person’s life.
Its comparison methodology also matters. Meta says controlled internal coding comparisons use a shared benchmark-specific setup, while externally reported results keep their original harnesses or agent products. Competitor configurations are best-effort. Reading a score without its testing conditions would therefore erase information the document itself supplies. For anyone selecting an agent, the relevant comparison is the actual workflow and setup, not simply the largest number in a launch presentation.
Safety commitments are not blanket guarantees
The release arrives after Meta’s October 2 safety-framework update. That earlier announcement extended containment requirements to training and evaluation, not just deployment. For high-risk reinforcement-learning runs, Meta described internally approved sandboxes, secure real-time records of model activity, and automated monitoring capable of halting runs after serious misbehavior. It also said a new board committee would review future framework changes. These are the company’s stated controls and governance plans, not proof that every possible failure has been eliminated.
Wonder’s model card is more cautious than a slogan about persistent agents. It acknowledges possible errors in unfamiliar multi-step situations, inaccurate responses, and spatial-reasoning weaknesses. It recommends application-specific testing and additional safeguards, including human confirmation for irreversible actions. Source: model-card limitations and responsible-use guidance.
The surrounding product also matters. Meta’s Muse Code description promotes coordinated workers and background reviewers, alongside visibility into actions and generated code. Those are product claims about the working environment, rather than additional model-evaluation results. Keeping that distinction clear lets a team ask separate questions about the underlying model, the tools it can operate, and the review process around its work.
