Muse Wonder vs Wonder Full: Pricing, Benchmarks and What Matters

Meta’s Muse Wonder launch gives developers a serious new option for agents that work across code, documents and applications. It also creates a buying decision that the benchmark screenshot alone cannot answer: should you use the US$4-input/US$20-output API model, or pay for access to the stronger Muse Wonder Full inside Muse Code?

The evidence supports a fairly specific answer. Wonder Full looks strongest on several measures of sustained agent work and long-running software engineering. Claude Opus 5.5 still leads other coding and general-intelligence comparisons. Regular Wonder gives developers a public API and a million-token context window, but its token prices match Opus 5.5 rather than undercutting it. The right choice depends on your task, access requirements and total bill.

Published October 12, 2026. This article is scheduled for source checks every four hours for three days. We will add substantive findings and corrections to this page as they emerge. The launch-benchmark analysis is source-based. The dated Kingy API studies below test regular Wonder, GPT-6.1 Sol and Claude Sonnet 5.5, including a six-project comparison that scores recall and working code separately. Kingy.ai has not reproduced Meta’s benchmarks or tested Wonder Full.

What Muse Wonder and Wonder Full are

Meta announced both models on October 12, 2026. They are reasoning models aimed at personal and professional agents: software changes, research, document work and tasks that require repeated interactions with tools. Wonder Full is a separate, higher-capability variant. Selecting maximum reasoning on the regular Wonder API does not turn it into Full.

Sources: Meta’s model documentation, model page and model card. A million-token context is a capacity limit. It does not establish perfect recall, a million-token output allowance or identical performance at every prompt length.

Wonder can reason about an image or video and return instructions, analysis or code. Image generation is a separate Muse Image product. Keep that distinction in mind when a demo shows a complete creative workflow: the model, surrounding agent and connected tools may each contribute to the result.

Pricing and availability: the API and subscription are different purchases

Meta’s direct API pricing charges Wonder at US$4 per million uncached input tokens, US$0.20 per million cached input tokens and US$20 per million output tokens. Meta lists no long-context premium. Built-in web search adds US$2.50 per 1,000 queries, plus the model’s token charges. Listed rate limits are 3,000 requests and 4 million tokens per minute; account eligibility and operational limits still need checking for a particular deployment.

Wonder is also listed in OpenRouter’s catalog as meta/muse-wonder. Its public catalog matched Meta’s US$4/US$20 rates at our check. Provider routing, platform fees and account access should be verified at checkout. We have not called the endpoint.

These are the prices and usage descriptions on Meta’s Muse Code product page. They do not promise a fixed number of maximum-effort Full tasks. Meta’s subscription documentation says the subscription credential works through Muse Code; additional API keys incur pay-as-you-go charges. A US$50 Full subscription therefore cannot be treated as US$50 of unrestricted API access.

There is a separate rollout to watch in the Muse personal-agent app. The launch announcement says Wonder will power experiences there soon, with subscribers first. That statement establishes rollout intent, not confirmed Wonder access for every current app user. Model availability and subscription benefits can vary by region. Meta’s geographic policy does not guarantee worldwide access; check the onboarding screen for your account and country.

For the organizational context, see our September 28 Meta Enterprise Platform explainer, covering the Muse agent, Business Agent, model API and Muse Code. That broader enterprise offering is separate from the Wonder-specific model access and pricing above.

What an agent can actually cost

Price per million tokens is a useful starting point. An agent’s bill also depends on how often it rereads context, how long it reasons, which tools it calls and how many attempts it needs. Meta’s reasoning documentation confirms that internal reasoning tokens count as billed output. A short visible answer can follow a much larger quantity of paid reasoning.

The following example holds token usage constant: 100,000 uncached input tokens and 20,000 billable output tokens, including reasoning. These are calculated prices, not measured completion costs. Standard direct-API rates are used; search, tax, retries, cache writes, storage and premium service tiers are excluded.

Rate sources: Meta, Anthropic, OpenAI, Google and DeepSeek. OpenAI’s long-context tier begins above 272K input tokens; Gemini 3.1 Pro’s higher tier begins above 200K. DeepSeek specifies weekday peak windows of 01:00–04:00 and 06:00–10:00 UTC, excluding Chinese public holidays. Local clock time alone is insufficient to identify the applicable rate.

For Wonder, that US$0.80 example becomes US$0.825 with ten charged search queries. If 90,000 of the 100,000 input tokens are cache hits, input costs US$0.018 for the cached portion and US$0.04 for the new portion. With the same output, the total falls to US$0.458 before search. Meta documents automatic prefix caching; a repeated prompt is not a guaranteed cache hit, so check the returned usage.

Large context still has a cost even without a premium rate. One million uncached input tokens plus 20,000 output tokens would cost US$4.40 on Wonder. Multiply context processing across repeated turns or subagents and the bill can grow quickly. The practical metric is the cost of a correctly completed job, including failed attempts and human repair.

Independent benchmark accounting reinforces that point. Artificial Analysis reports an estimated weighted cost per Intelligence Index task of about US$4.52 for Wonder at max effort. Its contemporaneous data gives approximately US$3.26 for GPT-6 Astra and US$5.98 for Opus 5.5 at their listed settings. Wonder’s lower unit price than Astra does not guarantee a lower task bill. Those figures describe that benchmark’s mixture of tasks, caching and token consumption, not a quote for your workload.

Our harder follow-up: remembering the rules and applying them are separate tests

We followed the small coding pilot with a longer requirements-memory test on October 12, 2026. The 5 scorable full-history answers reproduced 240/240 final configuration facts; 1 full-history answer was unscorable. All 6 scorable handoff answers reproduced 288/288 facts after a fresh conversation received only a model-written note. These are repeated checks within two variants of one fictional workflow, not independent experiments for every fact.

Each scenario began with five campaign-routing profiles and 48 checked configuration facts. Thirteen accepted changes introduced partial reversions, a profile rename, retirement of the old alias, pause and fallback rules, replacement exclusions and a later correction. Three long blocks of archived records supplied conflicting old values. The records were explicitly marked as historical, so the task was to retain the current requirements rather than follow the most repeated number.

What the second branch tested

Before the final answer was generated, we saved the source conversation. One branch reconstructed the configuration from that full history. A separate branch asked the same model to write a memory note, then gave only that note and the original output/decision contract to a fresh API conversation. The note writer never saw the full-history final answer. The two branches answered identical final questions.

The note instruction allowed up to 700 words and permitted compact JSON. That is not a strict information-capacity limit: a minified JSON object can count as one whitespace-delimited word. We retain the note text, character count and token usage. This tests whether a model can write and use a faithful handoff for this task, not whether a tiny prose summary can preserve an arbitrarily large project.

Correct configuration does not guarantee a usable answer

Among scorable answers, the final full-history branches answered 49/50 proposal decisions correctly; the handoff branches answered 59/60. Across all 24 audits, 19 were valid strict JSON responses. An unscorable answer remains a failed response in the table; it is not counted as either correct remembered facts or proof that those facts were forgotten. The table keeps these measures separate so correct-looking remembered data cannot hide an invalid API response or a wrong operational decision.

Claude scenario one’s full-history answer rejected the valid willow-forward proposal. Under the specified rule, paused Willow routes once to active Birch, which satisfies every eligibility check. Its handoff answer made a different error: it rejected spruce-route, even though its saved configuration correctly showed Spruce unpaused and the proposal met every condition. Both answers reproduced all 48 configuration facts correctly. These are observable rule-application mismatches, not missing configuration fields.

A scoring amendment we are disclosing

After a Claude baseline answer returned malformed overall JSON and trailing prose, we separated response-format compliance from recoverable requirement content. This was a post-observation scoring change. The original strict grades remain in the evidence. The additional pass first tries the whole response as JSON; if that fails, it may extract exactly one valid JSON value for each of the four unique named output fields. It does not rewrite values, guess missing fields or send a repair prompt. A recovered fact score therefore does not make that response valid for direct programmatic use. We requested JSON in the prompt; we did not enable provider-specific structured-output enforcement.

Claude scenario two’s full-history response contained two sets of JSON values. Under the recovery rule, duplicate fields are ambiguous, so we did not pick a preferred answer or assign it a memory score. Its raw response and the failed original grade are retained.

Cost and limits

The follow-up used an estimated US$1.1680 in tokens. Including the first pilot, the total was US$2.0762. The combined conservative allowance, including a 35% reserve for fees and exchange-rate uncertainty and higher possible input costs, was US$2.9452. That stayed below the original shared US$5 ceiling. These are estimates from returned usage, not attributable invoices. No additional subscription, paid judge or generation retry was used.

We used the same three native model IDs at medium effort. Two numeric variants do not establish a broad ranking; repeated facts and decisions are correlated. Tokenization, caching and internal reasoning differ, and Claude replayed native signed-thinking content while GPT and Wonder replayed visible responses. The handoff branch used a normal fresh API conversation: it did not call Meta Active Memory, native compaction, Muse Code or Wonder Full. It also does not establish performance over hours of real software work.

Download the complete follow-up evidence ZIP, including the frozen scenarios, original and revised grades, requests and responses, model-written notes, exact wrong answers and the combined cost ledger. API credentials are excluded.

Our six-run API pilot: all three passed, GPT cost less

Kingy measured this pilot on October 12, 2026. Muse Wonder 1.0, GPT-6.1 Sol and Claude Sonnet 5.5 each completed two fresh conversations on the same Python project. All six runs passed all 33 final checks on their first attempt. Every applicable checkpoint case passed, and we observed no previously passing behavior regress and no repairs. This small task separated cost more than coding quality.

The project was a fictional campaign-budget planner. We added first-occurrence deduplication, archive and channel filters, stable priority ordering, decimal-dollar migration and an audit list of unaffordable proposals. Priority explicitly replaced the original input-order rule. Two unrelated writing tasks inserted competing preferences such as alphabetical order and newest information first, while saying that those preferences belonged to another project.

Across all six runs and three tiny access canaries, the token-cost estimate was US$0.9081. The conservative allowance, including a 35% reserve for fees and foreign-exchange uncertainty and higher input pricing where metering might be incomplete, was US$1.2857. Both stayed below the approved combined US$5. These figures cover every generation request in this pilot; there were no generation retries or paid judges. They are not reconciled provider invoices.

What we mean by a remembered requirement

A requirement counted as an observed regression only if an unchanged behavior check passed earlier and failed later. A rule that never worked would be an implementation miss, not evidence of forgetting. We also retired the original input-order check when the prompt replaced that rule with priority ordering. Adding the new audit field could fail the new output contract without proving that earlier budgeting behavior was forgotten.

After locking the final code, we asked each model to recall the requirements and explain three edge cases. In all six answers, the model correctly said that an archived first duplicate blocks later copies, a proposal exactly equal to the remaining budget is selected, and price overrides cost_cents. All identified the priority rule as replacing input-order traversal. These were manually reviewed diagnostic answers, not an exhaustive recall score or a reason to change the code results.

Settings and a limit we had to amend

We used the native model IDs muse-wonder-1.0, gpt-6.1-sol and claude-sonnet-5-5, each with medium reasoning effort, a 4,096-output-token request ceiling and sampling settings left unset. Tools were disabled. There was one standard repair available per failing checkpoint, but none was used. Serial order rotated: Wonder, Claude, GPT in repetition one; GPT, Wonder, Claude in repetition two.

The original 40,000 cumulative input-token allowance stopped Claude’s first run before the unsent recall question, after all its coding checkpoints had passed. We raised that allowance equally to 60,000 for every model and resumed only that recall. The prompts, code checks, output limits and combined US$5 budget were unchanged; no generation was repeated. The original stopped record remains in the evidence. Active time excludes the operator pause for this amendment; the evidence separately reports full wall-clock time.

Every model received the complete visible conversation. Claude also replayed its native signed thinking content, while GPT and Wonder did not replay hidden reasoning state. Native tokenizers, reasoning budgets and caching behavior differ, so medium does not mean equal compute. Claude requests originated from a different host to keep its credential there. The time column therefore describes these runs; it is not a controlled provider-latency ranking.

What this does and does not tell us

Wonder retained the tested requirements in this short task. GPT did too, at a lower estimated token cost in this setup. Claude also passed throughout. We cannot name a coding-quality winner from six perfect runs on one small project. Repeated edge-case checks are useful, but they do not become independent projects just because there are many of them.

This test did not exercise cross-session Active Memory, context compaction, hours-long Active Focus, agent tool use or Muse Code. Wonder Full was not tested: this was regular Wonder through the Model API. Nothing here independently validates Meta’s long-duration benchmark claims. A harder follow-up would need longer projects, controlled memory conditions and several independent tasks.

Rates were checked against Meta pricing, OpenAI pricing and Claude Sonnet 5.5 documentation. The evidence package includes prompts, candidate code, raw response bodies, token records, stage scores, the amended protocol and the pinned isolated-worker checks. API credentials are excluded.

Download the complete Kingy pilot evidence ZIP.

Our six-project study separates remembering rules from writing working code

Measured October 12, 2026. We tested Muse Wonder 1.0, GPT-6.1 Sol and Claude Sonnet 5.5 on six small, synthetic four-file projects: an invoice/refund ledger, appointment scheduler, import pipeline, job queue, tenant permissions service and webhook reconciler. Each had two policy variants and two fresh repetitions per model. Python and TypeScript candidates ran in isolated containers against frozen executable checks.

The test separated working code and response usability more clearly than requirement recall. Wonder and GPT each reproduced all 1,152 checked values in their scorable recall responses. Claude reproduced 1,031 of 1,032 values across 86 scorable responses; ten recall responses could not be scored under the frozen parser. We found no clear task-meaning recall advantage for Wonder on these explicitly scoped histories. The deliberately unanswered questions also stayed unknown: all 1,112 such checks in scorable responses returned null. These are repeated probes within the same small set of projects.

Claude’s one exact-match miss needs context. In a saved-note branch it returned latest_by="seq" instead of the required "sequence". Its note had preserved the current value but added advice treating the two labels as aliases. Both describe sorting by the sequence field, and the independent code branch passed all 48 checks. We retained the original 11/12 recall score. This is a label and serialization mismatch; it does not clearly show that the sorting requirement was forgotten. All 72 notes retained their 12 explicit current policy values, but that coverage audit does not certify every sentence in a note.

Under the original prompts, Wonder produced 83 fully passing submissions out of 96 attempts, GPT 73 and Claude 55. These are observed results for this test setup, with the input-contract limitation discussed below. Claude also had 29 code responses that could not be graded because of their output format. Across code and recall, Wonder and GPT returned strict raw JSON in 192/192 responses each; Claude did so in 152/192. One additional Claude response was accepted after the parser removed its surrounding code fence.

A concrete example shows why recall and implementation need separate checks. Wonder’s first complete-specification attempt on scheduler variant 1 recalled all 12 rules in the independent recall request, but its Python used false instead of False. Import failed, and the code passed 0/48 checks. Claude’s first complete-specification attempt on importer variant 1 also recalled all 12 rules, but passed 17/48 code checks; all 31 failed outputs differed in record order. Those are not 31 independent memory failures.

Our practical choice: GPT-6.1 Sol is the lower-cost starting point for a similar API workflow, provided its output is validated and tested in the actual target runtime. In the separate explicit-schema check, it passed 18/24 original submissions against Wonder’s 19/24 and Claude’s 17/24. That one-submission gap does not establish a general winner. Wonder remains a candidate when its task-specific strengths justify the larger bill. Claude’s format failures deserve attention in a JSON-driven pipeline. Choose using your own acceptance tests; these runs do not demonstrate a memory advantage that alone justifies paying more for Wonder.

Every scenario had four conditions: the current specification; a clean history of six updates; that history mixed with archived records from other synthetic projects; and a fresh request receiving the model’s own saved note plus the last update. Recall and code were generated in independent requests, so the recall answer never helped the coding attempt. The saved note was written before the last update was revealed. Fixed-input prompts used the same text across providers; the model-written notes naturally differed. All API calls used medium reasoning effort, with no agent tools, repair prompts or paid model judges. Equal effort labels do not guarantee equal computation.

The original four-condition results

Specification limitation: review during execution found implicit input field names in the invoice, importer and permissions contracts. We preserved these original prompts and scores. Their coding totals include response formatting, implementation and input-contract interpretation; they are unsuitable as an unqualified coding leaderboard. The separate check below supplies explicit schemas.

Each recall response checks 12 current policy values plus four questions whose answers were never supplied. Each code attempt faces 48 checks, including policy-sensitive and algorithmic cases. Those checks are correlated: one bug can fail many of them. A whole-project pass requires all 48 to pass. “Code graded” counts parsed submissions sent to the grader, including runtime failures. Unparseable responses are excluded from that count and cannot count as passing projects.

The frozen parser accepts a single surrounding Markdown code fence, but does not extract JSON from explanatory prose or repair code. “Scorable” therefore does not mean strict raw JSON. The evidence package records a separate strict-format audit. Unscorable recall responses do not establish that a model forgot a fact.

A separate coding check with explicit input schemas

After finding the specification gaps, we declared a supplementary check before making its first call: 72 fresh complete-specification coding requests, covering every project, variant, repetition and model. Each received an explicit input schema with the same starter, policy values, graders and output allowance. No earlier answer or test feedback was supplied. This is a post-observation diagnostic, not part of the original four-condition design. A change in score can reflect clearer inputs and response variation; it cannot isolate the causal effect of clarification.

Runtime qualification: the prompts named TypeScript but did not specify the pinned Node 24 runtime’s native type stripping. Ten GPT webhook submissions—six in the original study and all four in the schema check—imported Decimal as a value even though the helper exported it only as a type. Node failed to load those modules. A separate local check changed only that binding to import type; all ten copies then passed 48/48 checks. We made no model calls and changed no original scores. These repaired copies are not first-attempt successes or a balanced repair comparison. The 0/4 webhook cell should not be read as four demonstrated failures of the business logic.

What the tests cost

Output length helps explain the bill. The separate schema check used 97,771 billed output tokens for Wonder and 29,050 for GPT, in addition to Wonder’s higher per-token rate. The shared “medium” effort setting did not equalize paid reasoning or response length. Cache reads and writes also affect the measured totals.

Total estimated token cost was US$30.96 across 723 generation requests: US$28.10 for the primary study and US$2.87 for the supplementary check. The conservative accounting allowance, including uncertain input/cache classifications and a 35% fees/FX reserve, was US$43.94, within the approved US$150 ceiling. The two earlier studies have separate ledgers and are excluded from these totals.

The largest static prompt counted 42,551 tokens for one provider; identical text tokenized differently across providers. This did not test the advertised million-token context windows. The code-output limit was 12,288 billed tokens; recall 1,536; note generation 2,048, with a separate 6,000-byte visible-note ceiling. Reasoning can consume the output allowance. A temporary loss of the Claude transport helper interrupted token counting before some generations were sent. We retained those failure records and later completed only the unsent work; no paid generation was repeated. Timing therefore does not establish a model-speed ranking.

This experiment measures supplied-history retrieval, explicit handoff notes and small-program implementation. The distractions were explicitly marked as archived records from other projects; success here does not establish robustness to more ambiguous source conflicts. The API requests do not invoke proprietary persistent memory, native application compaction, Muse Code or Wonder Full. The fixed algorithm contract was provided again after the note handoff; that condition tests retention of policy choices rather than preservation of an entire repository. Independent recall and code branches cannot reveal the internal cause of a particular code failure. Six project families remain a small, synthetic sample, and two repetitions cannot establish a general ranking of model families.

Download the six-project evidence package for the frozen protocol, prompts, visible outputs, candidates, reference fixtures, per-case scores, note audit and usage ledger. Private reasoning blocks and credentials are excluded from the public export. The original responses are retained privately.

The benchmark screenshot is real; its rows measure different things

The image accompanying this request matches the scorecard in Meta’s launch report and developer model page. That confirms its provenance. The table combines Meta-run evaluations, independent results and competitor-provider results. It should be read row by row, with its original test names and settings preserved.

Source: Meta’s model card, with the same values published on its model page. The listed setting is max reasoning except Wonder Full’s xhigh SWE-Marathon run. Decimal differences are arithmetic gaps, not demonstrated statistical significance.

The most interesting pattern is the difference between types of coding. Wonder Full leads this comparison on DeepSWE and SWE-Marathon, while Opus 5.5 leads Terminal-Bench and ProgramBench. Full’s DeepSWE advantage over regular Wonder is only 0.2 points. Full’s ProgramBench advantage over Wonder is nine points, but it remains 11.5 points behind Opus. “Best coding model” is too broad a conclusion for those results.

DeepSWE evaluates longer software-engineering tasks. Meta identifies Datacurve as the source for the Wonder variants and Opus, alongside provider-reported Astra and Fable scores. SWE-Marathon evaluates substantial projects and uses different agent products in this comparison, including Codex for Astra and Claude Code for Fable. That row compares complete systems, with model and harness effects intertwined. Our initial direct DeepSWE page retrieval did not expose the Wonder rows, so the 79.0/78.8 figures above remain attributed to Meta’s sourced scorecard rather than a separately confirmed Datacurve readback.

ProgramBench asks agents to reconstruct software and pass hidden behavioral tests. Meta specifies a common mini-swe-agent harness for that row. These task differences matter if your work consists of maintaining repositories, building new programs or operating tools in a terminal.

The professional-agent rows also require care. Full’s 13.1 on Harvey LAB-AA is the best listed score, but the metric is strict success across all deliverable criteria and hallucination checks. It is not a 13.1-point rating of general legal competence. Full leads AutomationBench-AA at 45.4, yet that leaves substantial room for failures under strict end-state checks. Finance’s 59.1 versus Fable’s 58.9 is a very small reported gap.

OSWorld is particularly easy to misread. Full’s 78.4 partial score awards progress through tasks; its 39.4 binary score measures complete success. Comparing 78.4 partial with another model’s binary score would produce a false impression. The Opus binary cell is missing, so no five-way binary ranking is possible. HealthBench Pro likewise measures responses to a specific evaluation, not evidence that an autonomous agent can safely deliver healthcare.

Independent comparisons with frontier and open-weight models

Artificial Analysis’s live public data provides a useful independent check. Its Intelligence Index v4.3.2 snapshot places Full at 55.8 and Wonder at 52.4 before rounding. That agrees with Meta’s displayed 56 and 52. The selection below extends the comparison beyond the five-model launch graphic; it is not a complete global leaderboard.

Source: Artificial Analysis’s model data and its Wonder Full and Wonder pages. Preserve the effort and fallback labels when quoting these scores. Gemini 4 Argon’s score establishes a tested configuration; it does not establish unrestricted public API availability or a purchasable price. One composite score cannot capture every task, latency target or deployment constraint.

The open-model tradeoff is substantial. Full’s aggregate result is stronger than the open-weight examples listed here, but those models allow deployment choices that Full does not: local processing, controlled infrastructure, model modification and different serving economics. Some use permissive licenses; others impose conditions. “Open weights” is a more precise label than assuming every release is unrestricted open source.

DeepSeek V4.1 Flash combines public weights with an inexpensive hosted API. Qwen3.8-27B is a smaller dense multimodal model under Apache 2.0. GLM-5.3 and Kimi K3 are relevant open-weight agent competitors with custom licenses. Their primary model cards, rather than a generic “open” badge, should guide deployment and licensing decisions.

Qwen needs an additional distinction. The public Qwen3.8-2.4T-A95B checkpoint has 2.4 trillion total parameters and 95 billion activated parameters. Its card describes the hosted Qwen3.8-Max service as having additional features. The checkpoint’s custom license adds conditions for certain businesses. The hosted Max score above cannot be silently reassigned to an arbitrary local quantization of those weights.

Active Memory, Active Focus and the missing specifications

Meta calls context retrieval across conversations Active Memory and sustained progress through obstacles Active Focus. These are useful product goals: remembering a changed requirement, recovering from a failed tool call and continuing a long job all matter more than producing a polished first answer.

Meta’s internal MemoryBench gives regular Wonder 85.6 and Full 85.5, testing long conversations of roughly 64K–100K tokens. That result does not establish reliable recall throughout the entire 1M window, across unlimited separate conversations or after an application deletes its memory. Full’s larger model also does not automatically win every memory test. The benchmark is an internal evaluation, so independent replications and application-level testing remain valuable.

The launch’s generalization experiment compares targeted post-training tasks with unfamiliar tasks as reasoning effort increases. Meta attributes Full’s stronger unfamiliar-task performance to a stronger underlying base model. That is a vendor explanation of its experiment. A buyer still needs to see how the advantage holds up on their documents, code and tool environment.

Several specifications are unresolved in the reviewed sources: exact parameter counts for either Wonder model, dense-versus-expert architecture, active parameter counts, training-token totals, a knowledge-cutoff date, training cost, serving hardware and energy per request. Meta identifies its Prometheus data center as the training site, but a data-center capacity statement cannot establish this model’s training bill or inference efficiency.

Independent latency is also incomplete. The Artificial Analysis model pages showed no output-speed measurement for either variant at our check. Avoid converting Meta’s “frontier” positioning into an unsupported claim that Wonder is faster than Astra or Claude. Measure time to the first useful response, complete-task latency, failure recovery and throughput separately when access permits.

Privacy, safety and the real cost of self-hosting alternatives

Muse Code subscriptions default to Contributor mode. Under Meta’s published explanation, more included usage comes with permission to use prompts, code, files, context and responses to train future Meta models. Turning Contributor mode off changes future content handling. Direct Wonder pay-as-you-go is Standard mode only; Meta says that content is not used for model training. Training exclusion does not by itself establish zero retention or a particular data-residency arrangement.

This changes how a team should compare a cheap subscription with a hosted API or local model. A subscription’s usage allowance, privacy setting and deployment restrictions belong in the same decision as benchmark quality. Sensitive source code and customer documents warrant checking the actual terms and account settings.

Meta’s model card also records limits in visual/spatial reasoning, uneven language evaluation and errors on multi-step tasks. Its safety assessment for Full reaches “moderate or lower” residual risk with mitigations; it does not rule out the unmitigated chemical/biological high-risk threshold. One evaluation correction is especially revealing: ExploitGym lists 92 captured flags, but only 21 used the intended vulnerability and are comparable to its published ranking. The raw 92 should not be used as a directly comparable leaderboard score.

None of that makes a hosted agent a safe place to grant unlimited permissions. Assess whether it can complete representative jobs without leaking private context, corrupting files or taking an unintended action. Keep confirmations for consequential actions and preserve a way to inspect and stop work. Benchmark success and operational control answer different questions.

Local alternatives have their own bill. Using parameter count × bits per parameter, a 27B model requires a theoretical 54GB for BF16 weights or 13.5GB at four bits. Those decimal-GB figures exclude quantization metadata, the vision component where applicable, KV cache, activations and runtime overhead. They are lower-bound estimates, not minimum-RAM installation instructions.

The same arithmetic puts a 2.4T checkpoint at roughly 4.8TB for BF16 weights or 1.2TB at four bits. A mixture-of-experts model’s activated parameter count does not mean only those weights must be stored. Compression, offloading and distributed serving can change feasibility, but require measurement. Include hardware or GPU rental, electricity, engineering time, updates and utilization when comparing self-hosting with an API.

Meta’s Muse Glimmer is another option for local agents. Its smaller-model role and Apache 2.0 release make it relevant to always-on local workflows, despite a much lower aggregate score than Wonder. A local assistant with modest capability can still fit a task that requires offline access or tightly controlled data.

Which option is worth evaluating first?

For an application that requires direct model calls, Wonder is the accessible variant. Compare it with Opus 5.5 at the same token prices and GPT-6.1 Sol at lower unit prices. Use your own task set and score correct completion, tool failures, latency and total cost. Similar aggregate scores can conceal meaningful differences on the work you do.

For difficult repository work inside a terminal agent, the US$50 Power Usage plan is the lowest advertised subscription that includes Full. Its long-running coding results justify an evaluation. Check how many representative Full jobs fit the allowance, how Contributor mode affects usage and whether the agent produces maintainable changes with passing tests.

For high-volume extraction, classification or smaller tool tasks, Spark, Gemini Flash and DeepSeek’s hosted models have much lower listed prices. The launch scorecard offers no reason to run every step of a workflow on the most expensive model. For local processing, examine Qwen, DeepSeek, Kimi, GLM and Glimmer alongside their licenses and hardware needs.

For legal, financial and health work, the domain scores help select candidates for supervised testing. They do not remove the need to verify citations, calculations and consequential advice. Full’s best-in-table legal score still reflects a strict benchmark with a low absolute completion rate.

Our next checks will prioritize Full’s access and usage details, independently readable DeepSWE and SWE-Marathon results, latency measurements, revised pricing, public model or safety documentation, and comparable results for open-weight competitors. New findings will be dated and sourced. If a check produces no material change, the article’s public update date will stay unchanged.

Sources and update record

The October 12 launch analysis uses Meta’s announcement, 13-page model card, developer specifications, pricing and subscription pages; Artificial Analysis’s independent model and index data; benchmark publishers; competing providers’ official prices; and first-party open-model cards. Charts are original Kingy.ai visualizations of those sources. Cost examples and weight-memory estimates are calculations. The separate Kingy pilot above contains six measured API runs dated October 12, 2026, with raw evidence linked for inspection. It does not reproduce Meta’s benchmark suite or test Wonder Full. No model weights were downloaded.

October 12, 2026: Initial publication. Verified the supplied scorecard against Meta’s report; documented US$4/US$20 Wonder API pricing, subscription-only Full access, independent index scores, open-model alternatives and the remaining evidence gaps.

October 12, 2026, measured-pilot update: Added the six-run changing-requirements API study, a per-run cost chart and the unchanged evidence archive. All six runs passed the tested checks; GPT-6.1 Sol had the lowest estimated token cost in this setup. Disclosed the input-cap amendment, correlated cases and transport differences, revised the firsthand-testing disclosure, and linked our existing Meta enterprise coverage.

October 12, 2026, six-project study update: Added the original memory-and-coding results, a separately declared explicit-schema diagnostic, three charts, exact pass/completeness tables and a public evidence package. Preserved the earlier studies and their dates, and separated observed recall from executable-code correctness.

Right now

Trending on Kingy

Keep reading with the stories getting the most attention now.

1. 01 Blog · Oct 3

   AI Video Game Decompilation: What Works, What’s Possible, and What’s Legal

   Read story →
2. 02 Blog · Oct 10

   AI Reverse Engineering Is Getting Easier. Can It Really Replace Adobe?

   Read story →
3. 03 Blog · Oct 6

   OpenAI’s 722 Math Manuscripts: The Results, Proofs, Compute and Costs

   Read story →

The Kingy Brief

Get The Kingy Brief.

AI changes, original tests and one practical thing to try. Fridays at 09:00 Vancouver time.

Free · Double opt-in · Unsubscribe anytime

Privacy policy

Signup help and newsletter schedule

Signup form provided by Beehiiv. After submitting, check your inbox for "Confirm your subscription to The Kingy Brief" and open its confirmation link. Check Spam or Promotions if you cannot find it.

Fridays at 09:00 Vancouver time: source-checked AI changes, original tests and one practical thing to try. The weekly restart begins October 9, 2026. We skip a week when there is not enough verified material. Free. Unsubscribe anytime.

Open signup on Beehiiv →