Muse Wonder: Memory, Recovery and the Work Left to You
MODELS & COSTS
Muse Wonder: Memory, Recovery and the Work Left to You
Repeating an instruction and rescuing a stalled tool call both cost time. Muse Wonder's Active Memory and Active Focus aim at those recurring problems. The question for a working agent is how much correction the features remove from a completed task.
In this article
Meta released Muse Wonder and Muse Wonder Full on October 12, 2026. The headline features are Active Memory and Active Focus. Developer access has started; the consumer Muse rollout is still described as coming soon, with subscribers first. Meta’s launch announcement separates those stages.
Active Memory across conversations
Meta describes Active Memory as carrying relevant context across conversations and retrieving it when needed. Active Focus describes persistence: trying another approach, adapting to new information, asking questions, and checking before important actions.
Here is the distinction I care about. Suppose I ask an agent to plan a trip around a fixed budget. Later, I change the dates and add an accessibility requirement. Useful memory means applying the updated constraints together, without quietly restoring the old dates. Merely repeating my original budget would be a much easier trick.
The model card lists a 1M-token inference context window, multimodal inputs, and text output. A large context window concerns material available during a run. Persistent memory concerns relevant information surviving across conversations. Those claims need different tests. Also, image input does not make Wonder itself an image generator.
Meta's internal MemoryBench uses conversations of 64K–100K tokens, with distractions and conflicting or updated facts. That is relevant to the trip example. It still leaves practical questions about what a deployed product stores, exposes, corrects, or deletes.
Active Focus after a failed attempt
A long task can fail without the model misunderstanding the original request. A website changes its layout. A dependency install breaks. A document arrives late. An agent has to revise its plan while preserving the goal.
That is the appeal of Active Focus. Meta's research page shows examples involving a kitchen game, running plans, and wedding seating. These are vendor demonstrations. I have not run Wonder against the same tasks, and a polished demo does not tell me the intervention rate.
For coding, Muse Code is the terminal-based product around these models. The distinction matters: the model supplies reasoning, while the surrounding product supplies tools, execution, and a workflow. I would evaluate the combination I actually intend to use.
For shopping, a good plan can still run into access restrictions. Our earlier look at Meta’s AI shopper and website access covers that separate problem. A stronger model cannot be assumed to remove platform restrictions.
Where Full gains and where it does not
No. In Meta’s published scorecard, Wonder scores 85.6 on MemoryBench and Full scores 85.5. ProgramBench is a different story: 50.0 for Wonder and 59.0 for Full. Both rows use maximum reasoning effort.
The 0.1-point memory difference gives me no reason to pay more for Full purely for recall. Without uncertainty estimates, I would not interpret it as a meaningful win for either variant. The nine-point ProgramBench gap is more interesting if reconstructing software resembles my workload.
The model card also mixes internal evaluations with results attributed to external evaluators. Calling the entire table independently verified would overstate the evidence. Calling every row internal would erase a useful distinction. I have retained the source labels, rather than treating the chart as one uniform experiment.
Available products and their cost
| Route | Status checked October 13, 2026 | Published price |
|---|---|---|
| Muse Wonder API | Available through Meta Model API; also listed on OpenRouter | Per 1M tokens: $4 input, $0.20 cached input, $20 output |
| Muse Wonder Full | Muse Code subscription; Power Usage or Maximum Usage | Power: $50/month; Maximum: $200/month |
| Consumer Muse | Wonder integration announced as coming soon; subscribers first | Launch announcement does not give a separate Wonder consumer price |
The API rates match OpenRouter’s Meta provider listing and Meta's model page. Full's subscription access is not an unlimited API allowance. I would check the current plan limits before assuming a monthly price covers a particular volume. These are published US-dollar amounts, not a Korean checkout total.
A concrete API example makes the rates easier to read. One million fresh input tokens plus 200,000 output tokens costs $8.00. If half the same input qualifies for the listed cache-read rate, it costs $6.10. That is my arithmetic using the posted rates, not a measured bill.
The calculation shows why a retrying agent needs a budget. Each fresh request or additional output can increase the total. The example fixes token volume; it does not predict how many tokens an actual task will consume. A larger context window is capacity, not a promise that filling it is cheap.
I have not verified access with a Korean account or tested Korean-language quality. A global announcement and multilingual training are insufficient evidence for either. Readers should check the service available to their account.
I would start with a small, reversible job and keep a record of what the agent actually does. The test below is my proposed acceptance checklist. It is not a report of tests already performed.
| Test I would run | What I would record |
|---|---|
| Change a constraint in a later conversation | Whether the updated detail replaces the earlier one |
| Introduce a recoverable tool failure | Whether the agent makes a useful recovery or repeats the error |
| Give an existing project a clear acceptance test | Final test result, manual interventions, and token cost |
| Require confirmation before a consequential action | Whether it pauses at the agreed boundary |
Wonder's promise is appealing because remembering the right constraint and recovering from a failed step can save more supervision than another fluent answer. The launch gives us a reason to test that promise. It does not yet tell me how much supervision I could remove from my own work.
For readers following Meta's model line, our earlier Muse Spark 1.3 article provides historical context. I would avoid comparing its older benchmark headline directly with the new scorecard unless the benchmark versions and settings match.
A useful evaluation would record what carried between conversations, which failures required intervention and the cost of the completed task. Without that record, the subscription comparison rests largely on Meta’s feature descriptions and reported scores.
Comments
Post a Comment