Evidence at a glance
A Plugin Update Brings a New Model into an Existing Workflow
Simon Willison released llm-meta-ai 0.2 on October 12, 2026. It is an update to a plugin for calling Meta AI models from the LLM command-line tool. It adds support for Muse Wonder and a `max` reasoning-effort setting. It is not a release of Meta model weights or training code, and it does not claim to introduce a new inference algorithm.
That distinction shapes how technical leads should read the release. Muse Wonder supplies the model capability, while the plugin connects it to an interface developers may already use. Trying the new model therefore requires less disruption to an existing workflow. That is a real engineering convenience, but it does not in itself tell us how much the model has improved.
Six Reasoning Settings Put Quality and Budget in the Same Decision
Willison showed six reasoning-effort settings: `minimal`, `low`, `medium`, `high`, `xhigh`, and `max`. The 0.2 release notes specifically call out the addition of the highest setting. These are not six different models. They are choices a caller can make about the reasoning effort used for a request. The plugin requires a Meta AI API key to call the service rather than running the model locally.
Reasoning effort is not a cost-free quality dial. The available material says reasoning tokens count toward the output-token budget, so teams should consider the setting alongside answer quality, task completion, and usage. If an evaluation compares settings without recording which one was used and how many tokens it consumed, it becomes difficult to tell whether a gain came from the model or from spending more reasoning budget.
Pelican Drawings Make Iteration Visible, but Only in a Narrow Slice
The most immediately legible evidence in this release is not a leaderboard but a set of pelican drawings. Willison generated images with Muse Wonder at all six reasoning settings and compared them with results from Muse 1.3 and Muse 1.2. Muse 1.2 was released on August 5, Muse 1.3 on September 2, and Wonder on October 12. He saw material progress in drawing across the versions and described Meta as releasing roughly one new model a month.
The value of this small comparison is that it makes change visible and gives readers something more concrete than adjectives in a release announcement. But it tests a particular drawing task. It cannot establish that long-horizon coding, tool use, or multi-step execution has improved by the same amount. Treating an image result as a proxy for general capability would stretch narrow evidence into a conclusion it does not support.
The Model’s Claims Target Sustained Work, but the Evidence Needs Separating
Meta’s description of Muse Wonder puts agent tasks at the center. It says Active Memory can retain and retrieve relevant information across conversations. Active Focus, in Meta’s account, tries other paths when it hits an obstacle and can ask for clarification or request confirmation before an important action. These descriptions concern how the model is intended to handle sustained tasks. They are separate from the question of whether a plugin can call it from the command line.
The model card’s evaluations are closer to those intended uses than a drawing comparison. DeepSWE v1.1 covers 113 tasks across 91 codebases and five languages, while Agents’ Last Exam uses 105 Linux tasks. The card also warns that evaluation sources and configurations can differ, and that the test sets cannot cover every real-world environment. Those figures show what Meta is testing. They do not establish that the model will reliably complete work in any team’s repository.
Access Routes and Specifications Cannot Replace Team Testing
Muse Wonder and Muse Wonder Full also differ in how they were made available. Meta’s materials say Wonder can be used through the Meta Model API and Muse Code, while Full was then available to Muse Code subscribers. For a team, selection therefore involves more than model scores. It also requires checking whether the intended model can be called through the team’s actual entry point and whether the access conditions fit its workflow.
The model card lists a one-million-token context length, but that is a specification, not proof that the model can use information equally well at every input length. Artificial Analysis described Muse Wonder at the `max` setting as equivalent in score to GPT-6.1 Sol. That comparison is a useful lead, not proof of equal performance across all tasks. The available materials do not provide a reproducible, complete training recipe or establish that long-context use and agent behavior are reliable in every working environment.
Version 0.2 is best treated as a low-friction way to begin testing, not as a selection verdict. A technical team can use its existing command-line workflow to compare reasoning settings on the same code and multi-step tasks, record completion and token use, and limit its conclusions to the tools and scenarios it actually tested. Pelican drawings are useful for quickly seeing changes in output. The evidence that should determine deployment still needs to come from the team’s own work.