Cursor has made Meta’s model selectable, but a large context window and a place in the catalog do not show whether it earns its separate meter. Teams should judge it by reviewed coding outcomes per dollar, not by context capacity alone.
Summary
Cursor’s documentation lists Meta’s Muse Wonder as model muse-wonder-1.0, with a 300,000-token context window and up to 1 million tokens in Max Mode. It is not included in Cursor plan usage; listed rates are $4 per million input tokens and $20 per million output tokens. Some Teams and Enterprise administrators must enable Meta access.
What happened
The listing brings Muse Wonder into Cursor’s model catalog, letting developers consider it within a coding workflow they already use. The commercial and access conditions matter as much as the listing: usage is separately metered, and some organizations need an administrator to enable Meta access. Cursor’s documentation establishes availability and those operating terms, but does not show that Muse Wonder performs better on coding work or that teams are adopting it. The reason Cursor added the model is not established by the available evidence.
What the archive adds
The archive records earlier access to Muse Wonder through Meta Model API and Muse Code, and a Vercel AI Gateway listing. This shows distribution across developer-facing surfaces, not adoption or comparative performance. The dossier describes Meta’s October 2026 launch as positioning Wonder for agentic work, including coding. It also raises benchmark comparisons, but the supplied findings contain no benchmark values or Cursor task results. Any benchmark signal would need to be treated as bounded evidence, not a substitute for testing the standard Muse Wonder listing against the separately specified Wonder (max) conditions.
Trend signal
Model catalogs are becoming a way to bring providers into existing development workflows. That lowers the friction of trying another model, but shifts the hard question from access to operational value: what does a model cost to produce a change that survives review? Context-window ceilings describe capacity, not the amount of context a task needs or the quality of the resulting code. Without task-level evaluation, a catalog listing is an option—not evidence of a better default.
Why now
According to the dossier’s Meta launch finding (d2), Meta positioned Muse Wonder for agentic work including coding and made the standard model available through Meta Model API and Muse Code. The archive finding (d1) records that earlier access route. Cursor’s primary documentation now lists the model within its catalog and states its metering and access conditions. These facts suggest broader developer distribution is a plausible driver, but they do not establish the reason Cursor added it.
Connections to other events
The constraint this listing exposes is attribution: teams need to connect the separate token meter to useful, accepted work. A model that produces more output or accepts more context is not necessarily cheaper per completed task. Our read is that the best evaluation is a controlled comparison on representative coding jobs, with the same repository state and review standard. Cursor’s published rates make cost measurable; the documentation does not settle whether the quality justifies it.
Why it matters
Builders can trial Muse Wonder without treating it as a replacement for their current model. Engineering leads should account for the separate charge and any provider-enablement step before expanding access. For Meta, Cursor is another route into a developer workflow; for Cursor, the listing expands its catalog. Neither fact establishes a performance edge, and the evidence does not establish why Cursor chose to add it.
What happens next
- Cursor’s Muse Wonder listing will remain separately metered unless its published plan or provider terms change. (3 months, 65%). Watch for: Cursor’s model documentation still states that usage is excluded from plan allowances and lists token rates.
- A public, reproducible comparison will test Muse Wonder on coding tasks in Cursor or a comparable agent harness. (6 months, 55%). Watch for: A published side-by-side evaluation reports task outcomes and usage for Muse Wonder against named alternatives.
Limits and uncertainty
The primary evidence is Cursor documentation. It gives listed rates, context limits, and access conditions, but no task-level coding results, typical token use, latency, reliability, or adoption data. The supplied dossier provides no benchmark figures or direct Cursor comparison, so benchmark claims cannot resolve the practical question here. Rates and access terms may change, and results from a small task set may not generalize across repositories or teams.
Skill to build now
Practise cost-per-accepted-change evaluation this week: run three recurring coding tasks against Muse Wonder and your current model from the same repository state. Have a reviewer score correctness, completeness, and rework from 1–5; log input/output tokens and calculate spend at the listed rates. Set your team’s cost ceiling before reviewing results, and check provider access before the trial.
Reader takeaway
Run a small, matched test before making Muse Wonder a team default. Use three recurring coding tasks and the same repository state for Muse Wonder and your current model; have reviewers score correctness, completeness, and required rework on a 1–5 scale, and record input/output tokens. Calculate spend per accepted change using Cursor’s listed rates. Keep it opt-in unless it matches or improves your quality score and lowers rework without exceeding your team’s agreed cost-per-change ceiling; confirm provider access first.
Open question
Will Muse Wonder produce enough additional accepted coding work to justify its separate meter, or will its value be mainly the convenience of another provider inside Cursor?