AI / Muse Wonder Interview questions

Muse Wonder is a frontier AI model from Meta, released on October 12, 2026 and built for personal and professional agentic tasks. Meta calls it its most capable model to date, built on the groundwork of Muse Spark.

"Agentic" here means multi-step work instead of one-shot answers: navigating an insurance claim, making sense of a lease, or building a working app. Two traits define the model: Active Memory (carrying context across conversations) and Active Focus (staying on a hard task until it is done).

It accepts text, image, video and audio input, returns text, and has a 1M-token context length at inference.

Muse Wonder comes from Meta (its Superintelligence Labs effort) and was released on October 12, 2026, together with Muse Wonder Full.

Meta says both models were trained at its gigawatt-scale Prometheus data center and that the release comes fourteen months after it began a ground-up overhaul of its AI work. The Muse family so far runs: Muse Spark (April 2026), the Muse personal agent (September 8, 2026), then Muse Wonder (October 12, 2026).

Meta also describes the work as pushing from rebuilding foundations toward the frontier, with Muse Wonder positioned as the next step on its scaling ladder after Muse Spark. A full safety report was promised after launch, and the model card has since been updated.

Muse Wonder Full is the larger, more capable member of the Muse Wonder series. At launch it is available only to Muse Code subscribers, not through the pay-as-you-go API.

According to a third-party summary of Meta's documentation, Full is a separate model and not simply Muse Wonder run at maximum effort. Reported Muse Code plans put it on the $50 Power and $200 Maximum tiers. Meta's risk assessment in the model card was run on Full because it is the most capable variant.

On Artificial Analysis Intelligence Index v4.3 (max effort), Muse Wonder scored 52 and Muse Wonder Full 56, as reported by third parties.

Active Memory is Meta's name for the model's ability to carry important context about you across conversations and bring back the details that matter for the task at hand.

The key word is "relevant": the goal is not to replay everything, but to recognize when earlier information becomes useful, for example a constraint you mentioned weeks ago that affects today's booking.

Meta tests this with MemoryBench, an internal benchmark of long multi-turn conversations (64K to 100K tokens) that include distractors and turns that update or contradict earlier facts.

Active Focus is the model's ability to keep working toward a goal when a task gets hard. Instead of stopping at the first obstacle, it tries other approaches, works through blockers, recovers from errors and follows through.

Meta adds two safeguards to that persistence: it asks for clarification when something is unclear, and it checks in with the user before taking anything important.

Meta evaluates it with FocusBench (persistence through real-world blockers across multiple interactions) and SWE-Marathon (long-running software projects).

Muse Wonder is available through the Meta Model API and Muse Code. Muse Wonder Full is available to Muse Code subscribers, and Meta says Muse Wonder will soon power more of the Muse app, rolling out to subscribers first.

Meta also says availability varies by country, so check the onboarding screen for what you can use.

Muse Code is Meta's terminal-based coding agent. It runs Muse Wonder on every plan, and Muse Wonder Full on the upper plans.

It first appeared alongside Muse Spark 1.2 and is one of the two places, with the Meta Model API, where Muse Wonder is available on day one.

A third-party review notes that subscription keys only work inside the Muse Code CLI, so a plan is not a cheap general-purpose API key.

In practice you install it, sign in with a Muse Code plan or key, and delegate coding work from the terminal. Plan tier decides whether you can pick Muse Wonder Full as well as Muse Wonder.

The Meta Model API is Meta's developer endpoint for calling its Muse models with pay-as-you-go billing. Muse Wonder is served there; Muse Wonder Full is not.

A third-party guide lists the base URL as api.meta.ai/v1 with bearer-token authentication, and says the request format matches Muse Spark, so switching is mostly a model-ID change. Developer docs and support live at dev.meta.ai.

Typical uses are chat assistants, coding tools and agents that call Muse Wonder from your own backend. Billing is per token, so usage dashboards and spend limits are worth setting up on day one.

The model card lists a context length of 1M tokens at inference. A third-party spec sheet rounds it to about 1.05M.

As a rule of thumb, 1M tokens is roughly 750,000 English words, enough for several large codebases or many long documents in one request.

A big context window is not the same as memory. It covers what you send in a single request, while Active Memory is about carrying context across conversations.

Large inputs are billed per token, so sending 1M tokens on every turn is expensive. Pair long context with caching, and send only what the task actually needs.

Muse Wonder accepts text, image, video and audio as input and produces text as output.

That makes it suitable for reading screenshots, charts, scanned documents and clips alongside a prompt. A third-party spec notes PDFs are handled through file upload.

Because output is text only, image or media generation needs a separate model such as Meta's Muse Image.

In practice, this lets one request combine a screenshot, a spoken note and a document, which suits personal-agent tasks such as reviewing a lease with photos of a damaged wall.

Per Meta's price list as reported on October 13, 2026, Muse Wonder costs $4 per 1M input tokens, $0.20 per 1M cached input tokens and $20 per 1M output tokens.

Muse Wonder Full has no per-token price because it is only sold inside Muse Code plans.

Because output costs five times the uncached input rate, verbose responses and long reasoning drive spend. Prices come from third-party reporting of Meta's list on October 13, 2026 and may change during the preview.

Muse Code has four monthly plans, and Muse Wonder Full is included only on the top two. These figures come from third-party reporting of Meta's product page.

Billing is monthly and the plans are separate from pay-as-you-go API pricing. Pick a plan by whether you need Full, which the lower two tiers do not include.

Third-party guides list muse-wonder-1.0 for Muse Wonder and muse-wonder-full-1.0 for Muse Wonder Full.

Only the first is something you call through the API. Full lives inside Muse Code. Meta classifies Wonder as a preview, so pin the exact ID in configuration rather than hard-coding it in many places.

import os
MODEL_ID = os.getenv("MUSE_MODEL", "muse-wonder-1.0")

Version suffixes like 1.0 imply later revisions will get new IDs, so a pinned ID protects you from silent behavior changes and makes A/B tests reproducible. Store the ID alongside each logged request so you can trace which model produced which output when you compare quality or cost later.

Muse Spark is Meta's earlier Muse model family, introduced in April 2026 and aimed at fast, lower-cost responses. Muse Wonder is built on the groundwork laid with Spark and is larger and more capable.

Spark has since had point releases (1.1 through the Meta Model API, 1.2 with Muse Code, and 1.3). Meta's own generalization plot compares Spark 1.3 with Wonder Full.

A third-party review reports Spark 1.3 at about $1.25 input and $4.25 output per 1M tokens, so it remains the cheaper choice for high-volume short tasks.

Meta highlights law, finance and health, plus frontier coding. Each has a matching evaluation in the model card.

The model card frames these as drafting and interpretation help with output meant for review, not a replacement for a professional.

Meta frames these as agentic work products: interpreting source documents, following detailed instructions and producing something a human reviews, such as a legal draft or a financial summary.

It is the framework Meta says it uses to train, evaluate and release its most capable models. It sets risk domains and thresholds that decide whether a model can be deployed and what mitigations it needs.

For Muse Wonder the assessed domains were Cybersecurity, Chemical & Biological and Loss of Control. A model reaches the "high" threshold when its deployment could substantially contribute to a threat scenario Meta has identified as severe. Meta's internal governance process reviews the assessment before a deployment decision.

The model card lists several limits. The most specific is that visual and spatial reasoning, especially 3D tasks, remains a known weakness.

• It can still make errors in multi-step reasoning, particularly in novel scenarios.
• It was not evaluated on every language in its pre-training data, so quality may drop outside the strongly supported set.
• Results vary with quantization, serving setup, prompts, tools and the agent harness.
• It may produce inaccurate, biased or objectionable output.

Meta recommends human-in-the-loop confirmation for irreversible actions.

Meta states that Muse Wonder is not intended for individuals under 18. Third-party summaries describe use as limited to adults.

For companies building on the API, the model card puts responsibility on the deployer: any risks from use by under-18s must be assessed, mitigated and compliant with applicable law.

Meta's terms and the Muse Supplemental Terms of Service apply on top of this rule, so product teams should review the Acceptable Use Policy as part of launch checks. If your product serves a general audience, add age gating or an adult-only declaration before onboarding.

A third-party spec lists function calling, JSON-schema structured output and built-in web search as supported tools.

Function calling lets the model request actions from your code. JSON-schema output forces a predictable response shape, which matters when another service parses the result. Built-in web search is billed separately at a reported $2.50 per 1,000 searches.

Check dev.meta.ai for the exact request fields, since the model is in preview.

Combine them in an agent loop: the model calls a function, your code runs it, and the result goes back as context until the task is finished.

Meta's research blog shows several agent demos. Together they cover coding, planning and document-heavy personal tasks.

• Kitchen game: a playable 3D game built from customizable image inputs.
• Saturday run planning: a running plan built in the browser and across apps from personal preferences.
• Personalized gifts: custom swag designed and ordered from real photos on an Instagram profile.
• Wedding seating chart: a chart that satisfies a list of complex matching requirements.
• Insurance claim and wellness support scenarios.

The demos are curated by Meta, so read them as examples of intended behavior, not guaranteed results on your own data.

Muse Wonder Full is a larger, separate model; Muse Wonder is the one you can call by API. Full is reserved for Muse Code subscribers and tops most of Meta's own comparison charts.

If you need programmatic control inside your own product, you are choosing between Wonder and other API models. Full only matters if your workflow lives in Muse Code.

Because the two are different models. Meta's documentation, as relayed by third parties, stresses that Full is not Wonder with reasoning turned to maximum.

The model card backs this up indirectly: results for both Wonder and Wonder Full are generated at max reasoning effort, yet Full scores higher on most rows. If effort were the only difference, the two would converge.

In practice, raising the effort setting on Wonder will not give you Full's capability, only more thinking from the smaller model. SWE-Marathon is the one place the card notes Full at xhigh effort.

That is why choosing between them is a product decision about access and capability tier, not a tuning knob you can turn up yourself.

A context window is what the model can see within one request. Active Memory is about what carries over between conversations and what gets retrieved when it matters.

MemoryBench deliberately injects turns that update or contradict earlier details, because remembering the latest correct fact matters more than remembering everything.

For builders, this means you still need good retrieval design and user-visible memory controls, since stale facts cause trouble.

When a step fails, Active Focus keeps the goal alive: the model tries another route, recovers from the error, asks if something is unclear, and checks in before anything important.

flowchart TD
  A["Goal set"] --> B["Attempt step"]
  B --> C{Blocked?}
  C -- No --> D{Important action?}
  C -- Yes --> E["Try alternative approach"]
  E --> F{Still unclear?}
  F -- Yes --> G["Ask user to clarify"]
  F -- No --> B
  G --> B
  D -- Yes --> H["Check in with user"]
  D -- No --> I[Continue]
  H --> I
  I --> J{Goal done?}
  J -- No --> B
  J -- Yes --> K[Finish]

FocusBench measures this persistence across multiple interactions and changing environments.

For product design, expose these clarification and approval moments in the interface so users understand why the agent paused. Without that, a clarifying question can look like a failure instead of a deliberate step toward finishing the job correctly.

Send an authenticated request to the Meta Model API with the model ID muse-wonder-1.0. Third-party guides give the base URL as api.meta.ai/v1 with a bearer token, and say the request shape matches Muse Spark.

import os, requests

BASE = "https://api.meta.ai/v1"
headers = {"Authorization": "Bearer " + os.environ["META_API_KEY"]}
payload = {
    "model": "muse-wonder-1.0",
    "messages": [{"role": "user", "content": "Summarize this lease."}],
}
# Endpoint path is illustrative: confirm it and the fields at dev.meta.ai
r = requests.post(BASE + "/<endpoint-from-docs>", json=payload, headers=headers, timeout=120)
print(r.json())

Keep the key in an environment variable, set a generous timeout for long agent turns, and read Meta's docs for the exact path since the model is in preview.

Add retries with backoff for transient errors, log request IDs for support, and never ship the key in client-side code.

Because Wonder uses the same request format as Muse Spark on the Meta Model API, migration is mostly a model-ID swap followed by testing, not a rewrite.

1. Change the model string from the Spark ID to muse-wonder-1.0.
2. Replay a sample of real tasks against both models and compare success, not just output quality.
3. Compare cost per completed task, since Wonder is roughly 3x Spark's input price and 4-5x its output price in third-party figures.
4. Check data mode: Wonder runs only in Standard mode, while Spark also offered a cheaper Contributor mode.
5. Re-check rate limits and timeouts, because longer agent runs take more time.

Roll out behind a flag so you can fall back to Spark for simple, high-volume traffic.

Choose Wonder when one failed run costs more than the extra tokens: long, multi-step jobs where persistence and memory matter. Keep Spark for large volumes of short, cheap tasks.

Since both share a request format, you can test the claim on your own tasks by changing one string.

Rule of thumb: estimate the cost of a failed run plus human cleanup time, and compare it against the extra token spend of Wonder.

Muse Wonder exposes six reasoning-effort levels, from minimal to maximum (per a third-party spec). Higher effort lets the model think longer, which usually helps on hard tasks but raises token use and latency.

Meta's published results use max effort for Wonder and the competitor models, so your results at lower settings may differ from the charts. Meta's generalization analysis also shows both Spark 1.3 and Wonder Full improving on unfamiliar tasks as test-time compute grows.

A sensible approach is to start mid-range, measure success per task, then move up only where failures cluster.

Treat effort as a per-task setting: use low levels for routing and extraction, and reserve the top levels for planning, debugging and multi-file work.

Cached input tokens cost $0.20 per 1M instead of $4, which makes them 20 times cheaper. Agents that resend a long, stable prefix on every turn benefit most.

To make the prefix cacheable, keep stable material first (system prompt, tool definitions, reference documents) and put the changing user message last. Reordering a prompt so a timestamp or user ID sits at the top can break reuse.

Exact cache rules are defined in Meta's API docs, so verify how hits are detected before budgeting around them.

Measure the cache hit rate in your own traffic, because a 20x discount only applies to the share of tokens that actually hit.

Multiply token volumes by the three rates, then add search calls. Use measured tokens per task from a pilot instead of guesses.

Output dominates here even though it is only 1M of 11M tokens. Third-party testing at max effort measured roughly $4.52 per task on the Artificial Analysis index, so list price alone can understate or overstate real cost depending on how many tokens a task reads and writes.

Add a safety margin of 20 to 30 percent for retries and longer-than-expected runs when presenting budgets to stakeholders.

The honest answer is mixed. Meta compared Wonder and Wonder Full against GPT-6 Astra, Claude Fable 5.1 and Claude Opus 5.5 at max effort and reports leading results on several agent and memory rows.

Independent data is thinner. Third-party reports put Artificial Analysis Index v4.3 at 52 for Wonder, 56 for Wonder Full and 58 for Opus 5.5. One outside tally of Meta's 14-row table counted Wonder Full and Opus 5.5 at six top scores each, and Wonder at one.

On price, third-party summaries say Wonder's per-token rates match Opus 5.5 and sit well below GPT-6 Astra. Treat all comparisons as provisional: the model was under a day old when most were written, and the right test is your own workload.

Read them as vendor-run evidence with some independent anchors. The model card itself explains the conditions, and several matter.

1. All headline runs use max reasoning effort.
2. Competitor runs are "best-effort"; prompts and tools may not be tuned for proprietary models.
3. Where no third-party result exists, Meta uses the highest of its internal run, a self-reported score or an official leaderboard score.
4. Some rows use internal benchmarks (MemoryBench, FocusBench, PSI, VBT) that outsiders cannot rerun.
5. SWE-Marathon compares models in different harnesses (Codex vs Claude Code), so it is not a controlled test.

Artificial Analysis, Vals AI and Datacurve results are the closer-to-independent signals. Meta's own card warns results vary with prompts, tools and harness.

MemoryBench is an internal Meta benchmark that checks how accurately a model recalls critical information across long, complex, multi-turn conversations of 64K to 100K tokens.

The conversations contain several individual facts, distractor conversations, and injected turns that conflict with or later update the target details. An LLM judge scores each answer against weighted, question-specific rubric criteria.

Meta reports Wonder at 85.6 there; a Chinese-language summary lists Opus 5.5 at 81.5. Because Meta built and graded the test, treat the lead as a signal about intended behavior rather than a neutral ranking.

Because the questions are rubric-graded by an LLM judge, small wording differences in rubrics can shift scores, another reason to treat the number cautiously.

The model card says Meta uses a comparable third-party or provider-reported result where one exists. Where none exists, it uses the highest of three candidates: its internally validated run, a self-reported score, or the official leaderboard score.

That rule is transparent but generous. Picking the best of several runs favors whoever has more options, which includes Meta for models it can run itself. Material departures from official setups are noted per benchmark.

When reviewing the tables, look at the source label for each row. Third-party-sourced rows (Artificial Analysis, Vals AI, Datacurve, Abundant AI) carry more weight than internal composites.

A practical habit is to rerun two or three key benchmarks on your own tasks instead of trusting any single table.

The model card says model refusals receive zero credit and stay in the denominator instead of being dropped. A model that declines a legitimate task should not look better by being excluded.

Safety tables treat refusals differently. For some biology tasks (ABC Bench Fragment Design and Screening Evasion), the card marks results with "**" because of a high rate of refusals from safety training, with refusals dropped before scoring. There the aim is to measure underlying capability, not refusal behavior.

So the same behavior is counted against the model in capability tables and set aside in dangerous-capability proxies.

This detail matters when comparing vendors: a model that refuses more can look safer yet score lower on usefulness, and both effects should be visible.

Both support the Active Focus claim, but at different scales.

Meta reports Wonder at 53.1 on SWE-Marathon. FocusBench is part of Meta's internal PSI composite, so only SWE-Marathon is independently sourced.

Neither benchmark guarantees performance on your tasks, so use them to shortlist and then test on real work. Also note FocusBench is internal, so outsiders cannot reproduce it, while SWE-Marathon has public leaderboard results.

Meta says it trained both models on diverse, long-running tasks so they can sustain progress through the cycle of tracking requirements, changing code across a repository, testing and revising.

The evidence offered: DeepSWE v1.1 (113 tasks across 91 repositories and five languages, pass@1) at 78.8 for Wonder using Datacurve's results; SWE-Marathon at 53.1; and Terminal-Bench 4.0 at 52.0 from Artificial Analysis. A third-party report notes Wonder moved from 33% to 52% on Terminal-Bench versus Muse Spark.

In day-to-day use that means pairing it with Muse Code or your own harness, running tests after each change, and letting Active Focus retry instead of stopping at the first red build.

It means doing well on unfamiliar tasks, not just the ones targeted during training. Meta ties it to the debate over "benchmaxxing" versus "big model smell".

In its analysis, Meta plots in-distribution score against out-of-distribution score at different reasoning efforts for Spark 1.3 and Wonder Full. Wonder Full sits above the line Spark's trend would predict.

Meta's explanation is the base model: Wonder and Wonder Full build on larger, stronger bases, so post-training gains carry over better to novel tasks. This matters for personal agents, which face unpredictable mixes of goals, tools and constraints.

A skeptical reader should still ask for third-party out-of-distribution results, since this analysis is Meta's own.

Meta says it trained the Muse Wonder family to avoid sharing private information without permission, to refuse clearly harmful requests and to resist adversarial instructions.

This matters because a personal agent often touches messages, calendars and documents. Active Focus also adds a check-in step before important actions.

Training is only one layer. The model card recommends deploying Wonder inside a broader system with guardrails suited to the use case, and reports that API traffic in Standard mode is not used for training (per a third-party summary).

Product teams should add data-minimization rules: give the agent only the mailboxes, calendars and folders needed for the current task.

With mitigations, Meta assessed residual risk at "moderate or lower" across all domains. Without mitigations, it did not rule out reaching the "high" threshold for Chemical & Biological.

Meta's governance process reviewed this before the deployment decision, and the evaluations were run on Muse Wonder Full as the most capable variant.

The "moderate or lower" label is Meta's own assessment under its own framework, reviewed by its internal governance process.

Because Meta could not rule out the model reaching the framework's high threshold in that domain without them. That made safeguards a condition of deployment.

The mitigations named in the card are safety post-training and system-level classifiers. Reported results for Wonder Full include BioTIER refusal rates of 98.7% (English), 98.7% (multilingual) and 98.2% (adversarial), and internal chemistry refusals of 100%, 100% and 99.8%.

The same card shows dual-use capability proxies such as SecureBio's tests and LAB-Bench, which is why classifiers and refusals were added on top of the base model.

The card also states Meta worked with outside experts and government entities on threat modeling, and applies a weight-security program across the model lifecycle.

Meta corrected its harness to include the intended vulnerability in the model's prompts, as the benchmark recommends, and reran the test. The result for Muse Wonder Full is now 20 intended flags.

The original report had 92 total flags and 21 intended flags. The update keeps only the intended count, which is how the public leaderboard reports it.

Meta states the correction does not change the "moderate or lower" cyber risk rating. For readers, it is a reminder to check the card's footnotes and dates, since the figures were revised after launch.

This is also a good interview talking point: it shows why benchmark harness details change scores.

Meta says developers and security teams can use models like Muse Wonder to find flaws in their own code, and that it kept frontier cyber capability available for defensive use while adding safeguards against misuse.

The card reports CyberGym at 88.4% and ExploitBench at 58.9% for Wonder Full. On adversarial refusal, attack success rates were low, for example 0.8% on CyberBench in both single and multi turn.

The balance is deliberate: block help with attacks on others, but do not cripple code review, vulnerability triage and hardening.

Security teams should still run the model inside sandboxes and review its findings, since false positives and missed bugs both occur.

Because agents can take actions that cannot be undone, and the model can still err on multi-step or novel tasks. The model card recommends human confirmation for irreversible actions.

Examples are sending a message, paying a bill, deleting files, or submitting a form. Active Focus already includes a check-in step, but the application should enforce its own approval gates instead of relying on model behavior alone.

A good pattern is to let the agent draft or stage the action and require a person to approve the final step.

Interviewers often ask for an example, so be ready to describe a staging pattern: agent proposes, human approves, system executes.

Treat the model as one component of a broader system, as Meta's card advises, and give it the least power it needs.

1. Grant tool access per task (read-only by default).
2. Tier actions by risk and require human approval for irreversible ones.
3. Treat text from emails, web pages and files as untrusted input, since it can carry hidden instructions.
4. Set spend, step and time limits so a stuck loop cannot run up cost.
5. Log every tool call for audit and review.
6. Evaluate on your own tasks before launch, since results vary by prompts, tools and harness.

Per a third-party summary of Meta's terms, Standard mode means your content is not used for training, while Contributor mode is a cheaper option where prompts and outputs may be used to improve models.

Confirm the current terms in Meta's documentation before sending sensitive code or personal data, since these details can change.

Teams handling client code or personal data should default to Standard mode and document that choice in their vendor review.

Third-party summaries citing Meta report limits of about 3,000 requests per minute and 4 million tokens per minute. Confirm the numbers for your account in Meta's docs, since preview limits can change.

For agents that fan out many calls, design for the cap: queue work, use exponential backoff with jitter on rate-limit errors, and track token use per minute, not just request count. Long contexts burn the token budget much faster than short ones.

Spreading large batches over time is cheaper than retrying bursts.

Also watch for per-model concurrency limits and implement request queues so a single burst does not starve other workloads.

Muse Wonder offers a 1M context, agent-oriented behavior and competitive pricing, but it comes with preview-stage risks and some unknowns.

Pilot on a narrow workflow with human approval gates, measure cost per completed task, and keep a fallback model.

Muse Wonder is the capability tier above Muse Spark and the engine Meta plans to use for harder work across the Muse app.

Meta says Wonder will soon power more of the Muse app, rolling out first to subscribers; will power artifact generation and processes needing more intelligence; and will be used to develop specialized models for everyone using Muse.

The sequence so far: Muse Spark in April 2026, the Muse personal agent on September 8, then Muse Wonder on October 12. Meta frames it as a step toward personal superintelligence.

Because roadmap items have no dates, plan around what ships today (API and Muse Code) and treat Muse app features as upcoming.

An illustrative flow shows how Active Memory and Active Focus combine. It is based on Meta's described behavior, not a published trace.

sequenceDiagram
  participant U as User
  participant W as Muse Wonder
  participant D as Documents
  participant P as Insurer portal
  U->>W: Help me file my claim
  W->>W: Recall policy details (Active Memory)
  W->>D: Read bills and policy
  W->>U: Ask which date to use
  U-->>W: Provides date
  W->>P: Fill claim form
  P-->>W: Error: missing code
  W->>W: Try alternative approach (Active Focus)
  W->>U: Check in before submitting
  U-->>W: Approve
  W->>P: Submit claim

Memory supplies prior context, Focus handles the portal error, and the check-in step keeps the user in control of the irreversible submission.

The point of the flow is not the specific insurer steps but the pattern: remember, act, recover, confirm. If any step fails twice, a well-built agent should stop and report what it tried rather than looping, which is where spend limits and step caps come in.