Meta's Muse Wonder Has 6 Reasoning Levels. Test Them.

By Lazar Milicevic · Published October 15, 2026 · 8 min read

Meta shipped Muse Wonder with a single parameter that changes both your bill and your answer quality, and most small teams will leave it on the default. If you pay per token and run everything at one setting, you're either overpaying on easy tasks or quietly losing accuracy on hard ones. Here's exactly how I'd measure it on your own workflow, with your own numbers.

What actually shipped (and what the dial is)

Meta launched Muse Wonder and Muse Wonder Full on October 12, 2026, according to Crypto Briefing's coverage. The part that matters for a small business is the reasoning_effort parameter. Per Meta's reasoning docs, the documented values are minimal, low, medium, high, xhigh and max. That's six levels on one model. Higher effort means more reasoning tokens, more latency and more cost. none is not supported and returns HTTP 400.

A few details that will save you debugging time:

• If you omit the parameter, the model still reasons, at a level it determines itself. "Default" is not "off."
• On Chat Completions it's a top-level reasoning_effort. On the Responses API it's nested as reasoning.effort.
• Setting max on muse-wonder-1.0 does not select Muse Wonder Full. On the Model API, Full isn't what you get. Per the docs, it's available only in Muse Code.
• The model works with OpenAI-compatible clients. Meta's launch post says you point your existing client at the Model API and set the model to muse-wonder-1.0.

Simon Willison, who maintains the open-source llm command line tool, updated his Meta plugin to support the model (version 0.2). He ran the same prompt, a pelican on a bicycle, at all six levels. The max result was decent but imperfect: the overall shape was right and the bicycle was missing a bar. That's the detail worth holding onto. Even the top setting isn't flawless, and the lower settings exist for a reason.

The pricing math you can actually check

Per Meta's pricing page, muse-wonder-1.0 in Standard mode costs:

Rate limits are 3,000 requests per minute and 4,000,000 tokens per minute. The context window is 1,048,576 tokens, and per VentureBeat, the per-token rate doesn't change based on how much of that window a request uses.

There's an important point in Meta's docs: max uses more reasoning tokens than xhigh at the same per-token price. So the effort level changes your bill through token volume, not through a different rate card. Two caveats:

• I haven't confirmed how reasoning tokens are billed relative to regular output tokens. Check the pricing page, your first invoice, or the usage field in the API response before you budget around it.
• Meta doesn't appear to publish how many reasoning tokens each level uses. So "minimal costs X% less than max" can't be stated as fact. That's exactly why you need to measure.

For context on how much the dial can matter, Artificial Analysis measured Muse Wonder at max effort at roughly 54k output tokens per Intelligence Index task and $4.52 per task, about 2.8x Muse Spark 1.3 at max ($1.60). Those numbers are from a benchmark suite, not your invoices, but they show how fast high effort adds up.

Why the leaderboard won't answer your question

Artificial Analysis scores Muse Wonder at 52 and Muse Wonder Full at 56 on its Intelligence Index v4.3, both at max effort, versus 48 for Muse Spark 1.3. Those are useful data points about the frontier. They're a poor guide for your inbox.

Two reasons:

1. The headline numbers are at max effort. I haven't found independent results for the lower effort levels on standard benchmarks. Any claim that "medium gets you 90% of the quality" is unsupported until you test it on your own data.
2. Benchmarks measure benchmark tasks. Whether a model ties another on a public test tells you almost nothing about how it handles your invoices, your customers, and your weird edge cases.

The dial is the thing you control. A leaderboard position isn't. So stop asking "which model is best?" and start asking "which setting is cheapest at the accuracy I need?"

The twenty-example test

Here's the repeatable harness. It takes an afternoon.

Step 1: pick one repetitive task. Email triage, line-item extraction from invoices, lead-reply classification. One task, not five.

Step 2: collect twenty real examples with known answers. Include a few ugly ones: the forwarded thread with three languages, the scanned invoice with a smudged total. If you don't already know the right answer, it's not a test case.

Step 3: run all twenty at three levels. Start with minimal, medium, and max. Add low or high only if the results are close.

Step 4: log three real numbers per run. Correct count, wall-clock time, and cost. No estimates.

Here's a minimal script using the OpenAI-compatible client. I'm assuming the base URL and key come from your Meta developer account; check the launch post for the current endpoint rather than trusting a placeholder from me.

import csv, time, json
from openai import OpenAI

client = OpenAI(
    base_url="YOUR_META_MODEL_API_BASE_URL",  # from Meta's docs
    api_key="YOUR_META_API_KEY",
)

LEVELS = ["minimal", "medium", "max"]
PRICE_IN, PRICE_OUT = 4.00 / 1e6, 20.00 / 1e6  # Standard mode, per token

cases = json.load(open("cases.json"))  # [{"input": "...", "expected": "urgent"}, ...]

def classify(text, effort):
    t0 = time.time()
    r = client.chat.completions.create(
        model="muse-wonder-1.0",
        reasoning_effort=effort,
        messages=[
            {"role": "system", "content": "Classify the email as 'urgent' or 'not_urgent'. Reply with one word."},
            {"role": "user", "content": text},
        ],
    )
    dt = time.time() - t0
    u = r.usage
    cost = u.prompt_tokens * PRICE_IN + u.completion_tokens * PRICE_OUT
    return r.choices[0].message.content.strip().lower(), dt, cost, u

rows = []
for effort in LEVELS:
    correct, total_t, total_c = 0, 0.0, 0.0
    for c in cases:
        out, dt, cost, usage = classify(c["input"], effort)
        correct += (out == c["expected"])
        total_t += dt
        total_c += cost
    rows.append([effort, correct, len(cases), round(total_t, 1), round(total_c, 4)])

with open("results.csv", "w", newline="") as f:
    csv.writer(f).writerows([["effort", "correct", "n", "seconds", "usd"], *rows])

One honest warning: the cost line above assumes completion tokens include reasoning tokens at the output rate. That's the unverified part. Print the full usage object on your first call and see what the API actually reports before you trust the cost column. If reasoning tokens are reported separately, adjust the formula.

Reading the results

Open the CSV and look for the cheapest level where accuracy stops meaningfully improving. A made-up illustration with round numbers, not real Wonder data:

In that hypothetical, medium wins: max buys nothing extra on this task. For a different task, say reconciling a messy invoice against a purchase order, the same table might show max earning its cost. Either way, you've replaced a guess with a decision.

Some practical rules for interpreting your own table:

• Twenty examples is a smoke test, not statistics. A one-case difference is noise. A five-case gap is a signal. If it's close, grow the set to fifty.
• Run the hard cases separately. An aggregate score can hide that minimal fails every ambiguous email. Tag your ugly cases and report them on their own line.
• Re-run before you commit. Reasoning models aren't perfectly deterministic. Run each level twice and check the answers match.
• Meta's own guidance is a starting hypothesis. The docs recommend low for direct-answer tasks like lookups, formatting and translation. Test that against your data rather than assuming it.

Once you have a winner, route by task: cheap level for triage, higher level for the judgment-heavy step. Don't set one global default.

Keep the model layer swappable

The same twenty-example harness answers the vendor question. Run the identical cases through the model you use today, and you have an honest side-by-side on your data: accuracy, latency, cost.

That only works if your automation talks to models through a thin layer. Because Muse Wonder is OpenAI-compatible, swapping it in can be as small as changing a base URL, a model string and one parameter. Keep those three in a config file, not scattered through your code:

# models.yaml
triage:
  base_url: YOUR_PROVIDER_BASE_URL
  model: muse-wonder-1.0
  reasoning_effort: medium
invoice_extract:
  base_url: YOUR_PROVIDER_BASE_URL
  model: muse-wonder-1.0
  reasoning_effort: high

Watch one trap: the parameter location differs by API (reasoning_effort on Chat Completions, reasoning.effort on Responses), and other providers name their reasoning controls differently. Isolate that mapping in one function. Simon shipping a plugin update quickly is a sign that switching tooling is getting cheap. Your architecture should be cheap to switch too.

Pricing and limits can change, so re-check the pricing page before you commit to a monthly budget.

Where this fits in my work

I'm a senior engineer who builds AI automations that ship, and this is the approach I take: a small evaluation harness plus a config-driven model layer, so each step in a workflow (email triage, lead follow-up drafts, invoice data extraction) runs at the cheapest setting that clears an accuracy bar measured on your own data. When a new model like Muse Wonder lands, the work is rerunning the saved test set against it and comparing the numbers, not rebuilding the workflow. More on how I work at bizflowai.io.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.