On October 12, Meta announced Muse Wonder and Muse Wonder Full, and the launch leans on two features with telling names. Active Memory, in Meta's own words, carries what matters to you across conversations and brings back the details relevant to the task at hand. Active Focus keeps the model working when a task gets hard: trying other approaches, recovering from errors, asking for clarification when needed. Six weeks ago, Muse Spark 1.3 scored 48 on the Artificial Analysis Intelligence Index. Wonder Full scores 56.
Memory just moved inside the model.
Our own memory governance is file-based, the same system we have written about here for months. Our reaction to the launch was not worry. It was recognition. Meta built memory into the model, and the layer we spend our days on is exactly the layer that cannot fit inside one.
What Meta actually shipped
The facts first, because they are strong. Muse Wonder is available today through the Meta Model API and Muse Code at $4 per million input tokens, $0.20 cached, $20 output. Wonder Full, the stronger variant, is reserved for Muse Code subscribers on the $50 and $200 monthly plans. On the Artificial Analysis Intelligence Index, Full scores 56 against Claude Opus 5.5's 58, and the API model scores 52. On Terminal-Bench 4.0, Meta's line jumped from 33% with Spark to 57% with Full. Whatever you think of the marketing, the slope is real: 31, 34, 40, 48, and now 56 on that index across the Muse line in about a year.
Two caveats belong in the same paragraph. Meta's own chart leaves out Claude Sonnet 5.5, which scores 56.00 on the same index, a hair above Full's unrounded 55.80. And the two flashiest headline numbers, MemoryBench 85.6 and FocusBench, are Meta-defined internal benchmarks, with no independent third-party replication published yet. Credit where due, though: cross-conversation recall with zero setup is genuinely convenient at the personal layer. We said the same thing about Grok Build's native memory when we tested it last month, and we meant it.
No, this is not recursive self-improvement
The Chinese AI outlet Xinzhiyuan went furthest, telling its readers the labs have now cracked recursive self-improvement. They have not. Remembering across conversations and recovering from errors are ways of using what a model knows. Self-improvement is changing what a model is. Active Memory and Active Focus are real capabilities, and they will matter to anyone building agents this year. They are also, both of them, things a determined team could already approximate with files, loops, and discipline. That is worth remembering the next time a launch gets called a singularity.
Four things built-in memory cannot do
None of what follows is a flaw unique to Muse. These are fundamental constraints of vendor-hosted memory. No matter how capable the underlying model becomes, any memory managed entirely inside a model vendor's system inherits all four.
1. It cannot be audited
Meta's memory is a black box. You cannot diff it, ask why a fact survived, or roll it back to last Tuesday. When we ran our five-task memory test on Grok Build, native memory held every convention across sessions, but zero percent of the work from four working sessions ever reached git. With a repo-file layer and an arbitration chain on top, 100% of the work was committed by end-of-day closeout, memory record in the same commits. Auditability turned out to be a property of where the memory lives, not of how smart the model is.
2. It cannot leave the vendor
Active Memory is a reason to stay, and every remembered preference is one more unit of switching cost. Our own memory system has now run on three engines in one year: OpenHands, Hermes, and Grok Build. The memory traveled each time, because it lives in the repository rather than in the engine. Muse's memory will not follow you to another model, and there is no published export or audit interface for it. That is not a bug in Active Memory. It is the business model.
3. It cannot defend itself from its own contents
Memory systems record the world as discussed, not as committed, and they get polluted by their own notes. In our Grok test we hard-reset the repository mid-experiment, and the agent kept working from a commit that no longer existed: six near-duplicate observations, half of them pointing at code that was gone, with nothing in the system to flag the mismatch. A governed layer can run a drift check against git and catch the divergence in seconds, because it has a second source of truth to check against. A closed memory store does not.
4. It cannot outlive the account
Built-in memory is tied to the account. If the subscription lapses or Meta deprecates the feature, the memory goes with them. In the same test, a fresh session in a cloned repository picked up every standing convention and every prior decision in about four minutes. A teammate or your own setup six months from now gets the full history from a plain git clone. Memory that belongs to the organization survives the people and the tools. Memory that belongs to the account does not.
These four constraints draw a clean line. Zero-setup memory inside the product serves the individual user well; team and organizational agent work needs memory that is governed and portable.
The other route
There is a second way to read this launch. Meta, the company that built much of its modern AI reputation on open weights, now keeps its strongest memory capability inside closed models sold by subscription, while its open-weight line, the 30B Muse Glimmer under Apache 2.0, sits at a much smaller scale. The message between the lines is that memory is valuable enough to keep closed. We agree with the valuation and disagree with the custody. On open-weight models, memory can live outside the model entirely: auditable, portable, self-defending, and owned by the organization rather than the account. The engine becomes replaceable. The governance does not.
One disclosure belongs here: we sell inference for open-weight models, so we have a stake in this answer. Judge the receipts rather than the stake. Every experiment linked above is published with its full record.
What we have not done
We have not hands-on tested Muse Wonder or Wonder Full. Full requires a paid Muse Code subscription, and everything in this piece draws only on Meta's announcement and third-party reporting as of October 13, 2026. This piece does not evaluate raw model performance; it examines the architectural trade-offs of vendor-managed memory. If Meta ships an export or audit interface for Active Memory, two of the four limits get weaker, and we will say so here. Nor is this an argument against built-in memory at the personal layer, where zero-setup recall is a genuine good. The claim is narrower: the better built-in memory gets, the more valuable the governed layer above it becomes, because that is the layer that decides what deserves to be remembered at all.
What to watch
Two things, over the next quarter. First, whether OpenAI and Anthropic answer with productized memory of their own, because three vendors shipping memory features makes the neutral layer more necessary, not less. Second, whether any vendor ships a memory export or audit API, which would be the first real crack in all four limits. The race Meta just escalated is over who remembers you. The more interesting race is over who gets to check.
Sources and further reading
- Meta: Introducing Muse Wonder and Muse Wonder Full (announcement, October 12, 2026)
- Artificial Analysis: Muse Wonder Full and Muse Wonder (Intelligence Index v4.3, accessed October 13, 2026)
- Layered Memory for Grok Build (our five-task test, with the full run record)
- Your rule file says "later." That's why it never happens. (on discipline text as control flow)
Your data, your business
Three commitments, verbatim from our privacy policy: No content logs. No training on your data. No usage reports built from your traffic. Usage lines record token counts, costs, and timing — never prompts, never completions.