Muse Wonder’s gains come with a cost-per-task question

An October 12 evaluation of Meta’s Muse Wonder and Muse Wonder Full reported Intelligence Index scores of 52 and 56 at maximum reasoning effort, compared with 48 for Muse Spark 1.3 at the same named effort level. The evaluator, Artificial Analysis, found improvements across several agent and knowledge-work tasks.

The same analysis complicates a simple efficiency story. Both new models used fewer output tokens in the evaluation, but Muse Wonder’s reported cost per task was higher than its predecessor. The analysis attributes this to pricing and substantial input-token consumption. Muse Wonder Full also had a different access model, available through Muse Code rather than a per-token API price in that comparison.

An agent pays for repeated context

A long task is rarely one prompt followed by one answer. An agent may repeatedly send instructions, previous messages, retrieved documents, and tool results. Even if its final response is short, the total input processed across the sequence can be large.

For a product team, this means a token-efficiency claim needs a clear denominator. Fewer generated tokens per answer, fewer total tokens per task, and lower spending per completed task are separate outcomes. The most useful trace records each call, including the context sent again after a tool operation. That makes it possible to see whether spending comes from reasoning, repeated context, or repeated attempts.

Keep effort settings comparable

Maximum effort is a meaningful evaluation condition, but it may not match an application’s operating point. A model used for an interactive assistant might need to finish sooner, while an overnight research workflow can tolerate longer execution. Test the level that the product will actually use and keep that level visible beside the result.

A sensible comparison also holds the task instructions and available tools stable. Otherwise, a model can appear better because it was given a more helpful environment. Record when a run failed for an external reason, such as a tool outage, so those failures are not silently mixed with reasoning errors.

A model can be attractive in an evaluation and unavailable through the interface an organization needs. A developer building an API service, a person using an integrated coding application, and a team with strict deployment requirements face different options. Availability belongs in the decision table alongside quality, latency, and spending.

Muse Wonder’s reported gains make it worth considering for demanding agent work. The more durable lesson from the evaluation is to compare whole tasks under explicit conditions. Output brevity is useful, but the bill follows the entire interaction, including the information the model repeatedly reads.