Muse Wonder vs Muse Spark: what the upgrade buys you

Spark was the rebuild. Wonder broadens the ambition.

Meta introduced Wonder and Wonder Full on October 12, after a sequence of Spark updates. Its launch puts personal and professional agents at the center: software projects, documents, and work that requires more than a convincing first answer. Meta’s Wonder announcement (source)

The naming is worth untangling. Muse is also a product ecosystem, Muse Code is the coding application, and the model API offers developers a separate integration path. A result achieved inside a coding application is evidence about that model working with that application's tools and instructions.

Meta's September developer recap already described a wider commercial platform, with Muse Code out of beta and the model API generally available. It also kept Glimmer, its open-weight model, as a separate deployment option. Meta's proprietary frontier models and its open releases should therefore be evaluated individually. Meta Connect developer recap (source)

The earlier WhatLLM Muse history covers the rebuild. The decision now is narrower: whether Wonder's additional capability removes enough failures from your workload to justify its cost and product constraints.

Use the same benchmark version and the same effort setting

A changing evaluation can make an improving model look worse, or an ordinary update look dramatic. The table below keeps the benchmark generation and reasoning effort fixed. It also keeps Wonder Full separate from the API model a developer can integrate.

The defensible reading is that the new family improves on Spark in this evaluation, while the version with the highest score has a different access model. A larger score is a useful reason to run an evaluation. It cannot tell a team how many support tickets, patches, or research tasks will improve.

Begin with the failures your current model produces. Separate cases where it lacks knowledge from cases where it loses track of instructions, chooses a bad tool call, or stops too early. A model upgrade is only one way to address those problems. Better retrieval, a clearer acceptance test, or a different agent harness may be cheaper.

For coding, the terminal agent matters. Before switching an entire team, give both products the same repository state and acceptance criteria. Inspect the resulting patch and the test coverage. The first plausible implementation is usually the easiest part of the demonstration to produce.

Fewer output tokens can still produce a larger bill

Wonder's launch API pricing is $4 per million input tokens, $0.20 per million cached input tokens, and $20 per million output tokens. Spark 1.3 is listed at $1.25 input and $4.25 output, with separate cached-input pricing. The unit prices alone make an upgrade materially more expensive for many request patterns. Artificial Analysis Wonder evaluation (source) · Muse Spark 1.3 independent model page (source)

A simple calculation shows the difference before an agent loop complicates it. Assume 100,000 uncached input tokens and 10,000 output tokens, including any billable reasoning. At those rates, Spark costs about $0.1675 and Wonder about $0.60. These are illustrative arithmetic, with no cache writes, retries, tool fees, or subscription terms included.

Agents complicate that calculation because they repeatedly send their working context back to the model. Reading a large repository once and replaying substantial context over twenty calls are different workloads. Caching changes the bill, but so do cache creation rules, misses, and edits that invalidate reusable prefixes.

Artificial Analysis measured Wonder using roughly ten percent fewer output tokens per Index task than Spark 1.3, yet its task cost was about 2.8 times higher. That is an instructive example of why output efficiency and total cost should appear in the same analysis. Artificial Analysis Wonder evaluation (source)

The calculation your team needs is spend per accepted result. A more expensive run can be cheaper overall if it avoids a second attempt and an hour of review. It can also be a poor upgrade when the cheaper model already succeeds and the extra capability changes nothing the user can see.

Log the complete attempt: input, cache events, output, elapsed time, retries, and acceptance. Compare that ledger rather than extrapolating from a single price per million tokens. Our agent cost guide develops this approach.

Memory has to survive the work

Meta calls two of Wonder's capabilities Active Memory and Active Focus. The first concerns carrying relevant information across conversations and retrieving it when useful. The second concerns continuing toward a goal through obstacles, new information, and alternative approaches. Meta’s technical explanation (source)

These are useful categories for a buyer's evaluation. Consider an agent asked to update a billing integration. It may need to remember that a legacy customer cannot migrate yet, preserve that constraint after summarizing a long session, and recognize when a later code change would break it.

Merely fitting the original instruction into a large context window does not test that behavior. A good evaluation introduces relevant facts early, adds distracting work, changes one requirement, and checks whether the final artifact respects the current constraints.

Persistence needs similar care. More tool calls can indicate useful recovery or a model repeating an unproductive approach. A patient agent should still recognize when it lacks a credential, needs a decision, or has reached a genuine stopping condition. Count productive progress, rather than rewarding duration.

Those distinctions also help evaluate the application around the model. Which memories are stored? What can the user inspect or delete? What context reaches a third-party tool? Answers need to come from the deployed product and its settings, not from a general description of the model.

Choose the upgrade path that matches the failure

The larger strategic move is easier to see through these choices. Meta can sell API access, package its strongest model inside a paid application, and use its models across consumer products. That gives the company several ways to turn model improvements into a product advantage.

For developers, it makes access part of capability. An exceptional benchmark result is less useful to an API team when it belongs to a model available only in another product. That does not diminish the result; it changes the decision it can support.

Reflection Beam makes a different proposition around controllable deployment, while Nemotron Bolt addresses local hardware limits. The three approaches deserve different evaluations. A team needs a model it can buy, operate, and trust on its own work.