Meta's Muse Wonder: A Frontier Model You Can Only Partly Buy

Meta announced Muse Wonder and Muse Wonder Full on October 12, 2026, describing them as its most capable models to date and its first serious push at the frontier since restructuring its AI efforts. The capability claims are the part you cannot verify yet. The access structure is the part you can act on today: one model is reachable through the Meta Model API, and the more capable one is not reachable through the API at all.

Capability and access are two different purchasing questions

What Meta shipped

Muse Wonder and Muse Wonder Full, built on the groundwork of the lighter Muse Spark model. Meta describes state-of-the-art performance on personal and professional agentic tasks, with expert-domain capability in law, finance and health alongside frontier coding performance. Two product properties carry the announcement: Active Memory, the ability to carry what matters across conversations and bring back details relevant to the task at hand, and Active Focus, the ability to keep working toward a goal when a task gets hard, try other approaches, recover from errors, ask for clarification and check in before following through on anything important. Meta's model card, as reported, puts the pair at comparable benchmark scores to Fable 5.1 and GPT-6 Astra.

# Model choice is now a channel question as much as a capability question.
CHANNELS = {
    'muse-wonder':      {'api': True,  'muse_code_only': False, 'notes': 'developer access via Meta Model API'},
    'muse-wonder-full': {'api': False, 'muse_code_only': True,  'notes': 'no API path announced'},
}

def can_i_call(model, via='api'):
    row = CHANNELS.get(model)
    if row is None:
        return {'usable': False, 'reason': 'unknown model'}
    if via == 'api' and not row['api']:
        return {'usable': False, 'reason': 'not served through the API'}
    return {'usable': True, 'reason': row['notes']}

print(can_i_call('muse-wonder'))
print(can_i_call('muse-wonder-full'))

# Build against the channel you can actually call. Pin the other one to a note
# in your architecture decision record, not to a hopeful import.

The access split is the real story

Muse Wonder is available to developers and builders through the Meta Model API and Muse Code. Muse Wonder Full is available to Muse Code subscribers, and per reporting, it will not be served through the API at all. Muse Wonder will also soon power experiences in Muse, rolling out first to subscribers. That is a commercial structure, not an accident: the strongest tier is bundled into a subscription product, and the API tier is one step below the frontier. For anyone writing an architecture decision record this quarter, it means the model you can call is not necessarily the model in the announcement, and the difference is a procurement decision rather than a technical one you can route around at runtime.

# Active Memory, implemented as it behaves: carry what matters, recall on demand.
import json

MEMORY = []

def remember(kind, text, ttl_days=None, durable=False):
    MEMORY.append({'kind': kind, 'text': text, 'durable': durable})
    return len(MEMORY)

def compact(limit=4, must_keep=('preference', 'constraint')):
    keep = [m for m in MEMORY if m['kind'] in must_keep]
    recent = [m for m in MEMORY if m not in keep][-limit:]
    return keep + recent

remember('constraint', 'invoices must be reconciled weekly')
remember('noise', 'user asked about a font')
remember('preference', 'reports in PDF, not slides')
remember('noise', 'tab completion request')
remember('noise', 'unrelated search')

print(json.dumps(compact(), ensure_ascii=False, indent=1))

# The rule that matters is not storage. It is which entries survive compaction.

The point of memory is not what you store; it is what survives compaction

Active Memory and Active Focus, translated

Strip the branding and both are engineering patterns you already have names for. Active Memory is context management across sessions: durable facts and constraints that survive compaction, with relevance-based recall when a new task arrives. The hard part is not storage, it is the compaction policy, because whatever gets dropped is gone, and whatever gets kept incorrectly will mislead the agent for weeks. Active Focus is bounded retry with escalation: try another approach when the first fails, recover from error states, ask the user when the task is ambiguous, and check in before consequential actions. Both patterns are worth implementing regardless of vendor, because they are what separates an agent that finishes work from one that produces confident summaries of unfinished work.

# Published API rates make the routing decision concrete.
PRICE = {'input_per_m': 4.0, 'output_per_m': 20.0}

def task_cost(input_tokens, output_tokens, calls=1, price=PRICE):
    per_call = (input_tokens / 1e6 * price['input_per_m']
                + output_tokens / 1e6 * price['output_per_m'])
    return round(per_call * calls, 4)

print('short chat turn   ', task_cost(1_500, 400))
print('doc summarisation ', task_cost(24_000, 900))
print('agent loop, 12x   ', task_cost(6_000, 700, calls=12))
print('daily fleet 50k   ', task_cost(6_000, 700, calls=12 * 50_000))

# Output tokens cost five times input here. Verbosity is the budget line
# nobody puts in the plan.

The price tag and what it implies

As reported, Muse Wonder costs four dollars per million input tokens and twenty dollars per million output tokens when called through the Meta Model API, roughly in line with other current frontier models. That ratio carries a design instruction: output tokens cost five times input, so the cheapest optimisation available to most teams is making the model say less. In an agent loop that runs twelve model calls per task, verbosity compounds twelve times. This is why routing by task class matters more than picking a favourite model: planning deserves the expensive tier, while classification, extraction and summarisation tolerate something cheap and high-volume.

# Active Focus, bounded. Retry freely, but escalate before you loop forever.
def work_toward(goal, attempt, max_attempts=5, clarify_after=3):
    log = {'goal': goal, 'attempts': 0, 'outcome': None}
    for i in range(1, max_attempts + 1):
        log['attempts'] = i
        result = attempt(i)
        if result.get('done'):
            log['outcome'] = 'complete'
            return log
        if i >= clarify_after and result.get('ambiguous'):
            log['outcome'] = 'ask the user'
            return log
        if result.get('needs_approval'):
            log['outcome'] = 'check in before acting'
            return log
    log['outcome'] = 'stop with a partial result'
    return log

def flaky(i):
    return {'done': i >= 3, 'ambiguous': False, 'needs_approval': False}

print(work_toward('reconcile the ledger', flaky))

# Recovery from failure is a feature. An unbounded retry loop is a bill.

Output tokens cost five times input; verbosity has a line item

Safety claims and the report that has not landed

Meta says the family was trained to avoid sharing private information without permission, to turn down requests to assist in performing actually harmful acts, and to work on improving security and defending against cyber attacks, with the explicit note that developers and security teams can still use the models to find flaws in their own code. It says the models are trained, evaluated and released in line with the Meta Superintelligence Scaling Framework, and that a full report with additional safety evaluations will be available soon. That last sentence is the honest one to quote. Until that report exists, independent safety claims rest on the vendor's own summary, which is a reason to run your own evaluations rather than a reason to assume the worst.

# Continual-learning claims need a regression suite, not a demo.
SESSION_A = [('preference', 'reports in PDF'), ('constraint', 'no external sends')]
SESSION_B = [('preference', 'reports in PDF, 2 pages max'), ('fact', 'team renamed to Revenue Ops')]

CHECKS = [
    ('retains earlier preference', lambda m: any(x[0] == 'preference' for x in m)),
    ('honours security constraint', lambda m: any('external' in x[1] for x in m)),
    ('applies the later refinement', lambda m: any('2 pages' in x[1] for x in m)),
    ('does not resurrect stale facts', lambda m: not any('old team name' in x[1] for x in m)),
]

def run_suite(memory):
    return {name: ('pass' if fn(memory) else 'fail') for name, fn in CHECKS}

print(run_suite(SESSION_A + SESSION_B))

# Write the suite before the vendor claims arrive, or you will write it
# around whatever the model happens to do.

How to evaluate a gated model without buying in

Write the evaluation suite before any vendor conversation, and keep it portable enough to run against a model you cannot permanently buy. Four checks cover most of the ground: does it retain a preference stated in an earlier session, does it honour a security constraint after several turns of pressure, does it apply a later refinement instead of the original instruction, and does it refuse to resurrect stale facts. Add a cost harness, because a model that passes your quality bar at an inconvenient price is not a passing model for your workload. Then note the exit condition in the decision record: which channel you are building against, what happens if that channel's terms change, and how much of your stack assumes a model you cannot call directly.