Meta Watermelon: I Want My Attention Back

Meta Watermelon was the internal codename for the model family now released as Muse Wonder and Muse Wonder Full. CNBC’s October 12 reporting connects the names; Meta’s announcement confirms the launch.
My interest in this release comes down to attention. If a more capable agent still needs me to watch every step, repair its output and repeat my requirements, I have acquired another task to manage.
For founders and AI professionals deciding whether to try Meta’s new models, that is the question I would put ahead of the leaderboard: how much of the work can I hand over without spending the saved time checking it?
This is my reading of the public release, with a proposed evaluation you can run. I have not tested Muse Wonder or had access to Meta’s internal models.
The Watermelon story has moved beyond the July claim
Our July report on Meta Watermelon and GPT-5.5 covered a claim about an unreleased model’s internal results. That was a different evidence situation. Readers arriving through the old codename now need a map to the shipping products.
As of October 13, Meta lists these access routes:
| Product | Access announced by Meta | What I would evaluate |
|---|---|---|
| Muse Wonder | Meta Model API and Muse Code | The model in the workflow I can actually use |
| Muse Wonder Full | Muse Code subscribers | The coding agent and model together |
| Muse consumer agent | Wonder rollout coming first to subscribers | Availability in my account before relying on it |
Source: Meta’s launch announcement, October 12. A planned rollout does not establish that every subscriber already has access.
This split matters. A result from Wonder Full does not tell an API builder what standard Wonder will do. A coding subscription also brings a surrounding agent, tools and execution environment into the evaluation.
I would write down the exact product and model variant before comparing any results. Otherwise, it is easy to admire one system and buy access to another.
I want an agent that reduces the work of supervision
Meta emphasizes Active Memory, retrieving relevant context across conversations, and Active Focus, continuing through blockers while seeking clarification when needed. Those are the capabilities I would test first. The research announcement describes both as central to the new family.
Consider a hypothetical customer onboarding task. A founder asks an agent to prepare a setup guide from a product brief and a support thread. The agent produces a polished document. But it misses the customer’s plan restriction, repeats an outdated setup step, and states that an integration works without checking the supplied evidence.
The document exists. The founder still has to reconstruct the task and audit the answer.
Now imagine the agent notices the plan restriction, identifies the conflicting instructions, and leaves one specific question for the founder. That interruption may be useful. It prevents a confident mistake from becoming part of the customer’s setup.
That is the distinction I care about: useful escalation versus avoidable supervision. An agent should ask when a decision belongs to me. It should do the routine work of reading the brief and checking its own deliverable.
Our earlier coverage of Meta’s Muse family and personal agents provides the broader context. Wonder makes that ambition more concrete, but the outcome still needs to be demonstrated in the work you do.
The benchmark footnotes deserve a place in the story
Meta’s model card separates internal evaluations from external results and describes differences in evaluation setups. It also says performance can vary with prompts, tools and the agent harness. That makes the surrounding software part of the comparison.
One useful example is SWE-Marathon: the card explicitly says the row is not a controlled comparison using the same harness for every model. Different agent products participate. That result can help evaluate a system, but it cannot isolate the model’s contribution. Source: Muse Wonder model card, methodology and SWE-Marathon sections.
This is not a reason to discard the results. It is a reason to ask a narrower question.
If I am buying Muse Code, an evaluation of the complete coding agent may be highly relevant. If I am replacing a model inside my own application, I need evidence from that application’s tools and prompts.
Our guide to what to test when AI benchmarks are misleading explains why those decisions need different evidence.
The same caution applies to memory. Meta’s card describes MemoryBench as an internal evaluation using long conversations with distractors and updated facts. That is a useful test design. It does not establish that your deployed agent will manage every customer preference or permission correctly.
The test I would run before switching
I would start with a small set of real, completed tasks where I know what an acceptable outcome looks like. Remove private information or use a sandbox copy. Choose tasks that resemble next week’s work, including an awkward one with conflicting source material.
Keep the starting brief, inputs and acceptance criteria consistent across systems. Record each system’s actual access route and settings. If you compare different agent products, describe it as a product comparison.
For each task, keep this record:
| Check | What to record |
|---|---|
| Accepted result | Did the deliverable meet the requirements written before the run? |
| Human effort | Minutes spent clarifying, inspecting and correcting |
| Recovery | What happened after a missing input, failed tool or changed requirement? |
| Evidence | Could you trace important claims to the supplied sources? |
| Approval boundary | Did the agent prepare the work and pause before an action requiring permission? |
Do not invent a single score before you understand the failures. A system that needs less editing on routine tasks may still be a poor fit for work where a missed constraint is expensive.
The financial comparison comes later. Include model charges or subscription costs, along with the human time needed to accept the output. A cheap run that requires substantial repair can be a poor bargain.
A small trial will not establish broad reliability. It will tell you whether a larger evaluation is worth your time.
A copyable brief for testing memory and recovery
Here is an exercise I would use to probe the release’s promises. It is a proposed test, not a report of a run.
Supply a sanitized product brief, two dated support notes and a sample customer request. Give the notes one deliberate conflict: an older note permits an integration; a newer note says the customer’s plan does not include it.
Prepare a customer onboarding guide using only the supplied documents.
Acceptance criteria:
- Every setup step must be supported by a supplied source.
- Respect the customer's plan restrictions.
- Prefer newer policy information when dated sources conflict.
- Flag unresolved conflicts instead of inventing a resolution.
- Draft the guide here. Do not send, publish, or modify customer records.
Before drafting, list the constraints you will use.
After drafting, check the guide against those constraints.
Separate verified facts from recommendations.Then introduce a change in the same conversation:
The customer has upgraded to a different plan.
Use this new dated plan document to revise the guide.
Identify which earlier constraints changed and which still apply.
Explain any remaining blocker. Keep the draft-only boundary.Check whether the agent updates the affected steps without forgetting an unrelated requirement. If a source is missing, observe whether it names the missing information or writes around the gap.
This exercise is intentionally modest. You can inspect its answer. Once it works, repeat the principle with a task from your own workflow and a clearer acceptance checklist.
The strongest case for Meta
There is a fair objection to my framing: better base capabilities may be what makes lower supervision possible. A model that can understand a harder problem has a better chance of recovering when the first approach fails.
Meta argues that the stronger base behind Wonder improves performance on unfamiliar tasks. Its research post presents this as evidence of generalization beyond targeted post-training tasks. That is a promising vendor finding, and I would want to see how it transfers to my workflow. Source: Meta’s “Capabilities That Generalize” section.
I would put the release on an evaluation shortlist. Refusing to try a new system until someone proves it works everywhere would miss useful improvements.
But I would also keep the claim proportional to the evidence. The model card acknowledges errors in multi-step reasoning, especially in unfamiliar situations. Finishing a longer task is valuable only if the finished result meets the brief.
My decision would be to try the exact variant I can access, on work I can verify, before making it responsible for more.
What would change my mind
I would switch a workflow if Wonder consistently produced acceptable results with less correction time, recovered from ordinary blockers, and respected the decisions I reserved for myself.
That would be progress I could feel during a working day.
Watermelon has a public product name now. The useful next chapter belongs to the people testing whether it gives them time back.
For practical prompts, model insights and tool reviews that help you make those decisions, join ThePromptBuddy’s bi-weekly newsletter. Bring the next model announcement back to a task you actually need done.