Muse Wonder vs Muse Wonder Full: Meta Upgraded the Model. Your Warehouse Still Needs a Semantic Layer

Last verified: October 15, 2026. We will update this post when credible SQL evaluations of either model appear.

Meta calls Muse Wonder and Muse Wonder Full its most capable models to date.¹ Independent testing puts both above Meta's previous model and below Claude Opus 5.5.⁵⁶

Your data team has a narrower question. Can either model answer "what was net revenue last quarter" against your warehouse, and give the same answer tomorrow, given the same data? We found no public evidence yet. The table compares three common setups and shows why the answer depends on more than the model.

Three ways to put a frontier model on enterprise data

Aspect	Raw schema LLM (Wonder or Wonder Full)	Text-to-SQL agent with metadata and validation	Colrows semantic execution layer
Who defines "net revenue"	The model infers it from table and column names	Retrieved schema and curated metadata guide the model	Governed metric definitions that your team owns
How SQL is produced	Probabilistic generation on every request	Probabilistic generation, then checked and repaired	Deterministic compilation from resolved definitions
Access control	Instructions in the prompt	Database permissions plus application rules	RBAC, ABAC, row level and column level rules applied before the query reaches the warehouse
Audit and repeatability	A chat log	Prompt and query logs	Join path proofs, an audit trail, and point in time reproducibility

This table compares architectures in general terms. It is not a test result for either Muse model or for any named product.

Muse Wonder vs Muse Wonder Full: what Meta actually shipped

The names suggest one model in two sizes. Meta sells them as two different products.

Muse Wonder vs Muse Wonder Full (as of October 15, 2026)

Attribute	Muse Wonder	Muse Wonder Full
How you get it	Meta Model API (muse-wonder-1.0) and Muse Code1	Muse Code only (Power Usage and Maximum Usage plans). No API.46
Price	$4 input, $20 output, $0.20 cached input, per 1M tokens3	Flat monthly plans. VentureBeat reports $50 and $200.6
Intelligence Index v4.3	52	565
Hallucination rate (AA-Omniscience)	27%	23%5
AA-Omniscience score	25	305
Training on your content	API: not used in Standard mode. Muse Code: Contributor mode is on by default.34	Contributor mode is on by default.4
Weights	Closed. Neither model has publicly downloadable weights.6

The index, hallucination and recall rows measure general model capability. They are not accuracy on enterprise text-to-SQL tasks.

Both models accept text, image, video and audio input and produce text. Both have a context window of about one million tokens.²⁶ Neither Meta's announcement nor its model card states a parameter count.

The practical split is access. Wonder is a metered API product that your engineers can call from code. Wonder Full is a subscription feature inside Muse Code. If you plan to build a data agent, only Wonder can sit behind your own service today.

What independent testing says about Muse Wonder Full

Artificial Analysis scores Wonder Full at 56 on its Intelligence Index v4.3 and Wonder at 52. Muse Spark 1.3, Meta's previous model, scored 48.⁵ VentureBeat's summary of the same index puts Claude Opus 5.5 at 58, Claude Sonnet 5.5 at 56, and GPT-6 Astra, Gemini 4 Argon and Claude Fable 5.1 at 53.⁶

That is a real jump. It is not a lead.

Three details matter for enterprise buyers:

• Price. Opus 5.5 has the same API list price as Wonder, $4 and $20 per million tokens, and scores six points higher.⁶ Per task, the picture shifts. Artificial Analysis measured $4.52 per Intelligence Index task for Wonder, against $5.98 for Opus 5.5 and $3.26 for GPT-6 Astra.⁵
• Hallucination. Wonder Full hallucinated on 23% of AA-Omniscience questions, down from 33% for Spark 1.3. Gemini 4 Argon sits at 15%.⁵
• Recall. Wonder Full scores 30 on AA-Omniscience. Opus 5.5 scores 46.⁵ Artificial Analysis attributes Full's gain over Spark 1.3 to the lower hallucination rate.

Treat Meta's own scorecard with the same care you would give any vendor table. The model card says it uses a third-party or provider-reported result where one exists. It also says competitor runs are "best-effort" and that its SWE-Marathon row "is not a controlled common-harness comparison."² VentureBeat calls the Artificial Analysis scores "an important counterweight to Meta's broader performance claims" and notes that some coding comparisons use different coding tools.⁶

Muse Wonder text-to-SQL accuracy: no public result found yet

On October 15, 2026, neither Muse model appeared on the Spider 2.0 leaderboards (Snow, Lite or DBT) or on the BIRD leaderboard.¹¹ The model card sections we reviewed report cyber, chemical and biological, and loss of control evaluations. They report no SQL benchmark.² This covers those pages only. Other evaluations may exist that we did not find.

That is a data gap. It says nothing about model quality, and the models are three days old. Do not quote an accuracy figure for either one. Nobody has one.

Spider 2.0 and BIRD need care too

Researchers at the University of Illinois audited the gold queries behind both benchmarks. They found annotation errors in 52.8% of the 498 BIRD Mini-Dev examples. They found errors in 66.1% (80 of 121) of the Spider 2.0-Snow tasks that have public gold queries.⁷

Corrections changed results. CHESS rose from 62% to 81% execution accuracy and moved from fourth place to first. OpenSearch-SQL fell from 71% to 69% and dropped from first to third.⁷ Benchmark rankings need scrutiny. That does not make every result wrong. It means you should validate against business questions that your own experts have reviewed.

Why a stronger model alone does not close the enterprise SQL gap

Three studies point the same way.

1. Enterprise schemas break good models. The Spider 2.0 authors report that a code agent built on o1-preview solved 21.3% of their 632 enterprise tasks. The same framework reaches 91.2% on Spider 1.0 and 73.0% on BIRD.⁸
2. In one study, context moved accuracy more than model choice. A paired benchmark of Claude Opus 4.7, Claude Sonnet 4.6 and GPT-5.4 found the three models statistically indistinguishable without a semantic layer document, at 45.5% to 50.5%. Adding the document raised accuracy by 17 to 23 percentage points for all three.⁹ The intervention was a hand-written semantic layer document. That supports the value of explicit business context. It does not measure Colrows.
3. Representation of the data matters. GPT-4 answered 16% of enterprise SQL questions correctly on a raw SQL schema. Accuracy rose to 54% when the same questions ran over a knowledge graph representation of the database.¹⁰

Read these with their limits in mind. The third study used an older model. The second used 100 questions. Spider 2.0 numbers come from one agent framework. The direction still holds across all three. Model quality matters. It cannot replace business context and governance.

Now apply this to the Muse numbers. A 23% hallucination rate on AA-Omniscience measures how often the model invents answers to public world-knowledge questions. Your schema is not in any training set. The model has never seen your definition of "active customer", so it cannot know when to abstain about it. It will pick a plausible column and write valid SQL. That inference is ours, not a measured result for Muse. Test it on your own warehouse.

Leaderboards show the same pattern. The top Spider 2.0-Snow entry is an agent system, Genloop Sentinel Agent v2 Pro at 96.70, not a bare model.¹¹ Systems that wrap a model in schema exploration and refinement lead the board. That suggests the scaffold matters as much as the model.

Fix the context, not the model

Colrows is an autonomous semantic layer. It works as a semantic execution layer, a deterministic compiler that sits above your warehouse (Snowflake, Databricks, BigQuery or Redshift). It resolves a natural language question against governed definitions. It compiles governed SQL. It applies RBAC, ABAC, row level and column level policy before the query reaches the warehouse. It records an audit trail and supports point in time reproducibility.

Be precise about "deterministic". Here it means the SQL comes from a compiler working on resolved definitions, not from sampling a model. The same question, definitions and permissions produce the same SQL. Query results still change when the data in your warehouse changes.

One question, one ambiguity

This is an architecture walkthrough, not a measured result. Finance counts net revenue after returns and discounts. Sales operations counts it at booking. The warehouse holds three similar columns: net_revenue, revenue_net and rev_adj_total.

1. A raw schema model picks one column that looks right. It may pick a different one tomorrow.
2. A metadata-assisted agent may pick the documented column. Nothing forces the finance definition, and nothing records which version it used.
3. A semantic layer resolves the question to the metric version that finance approved, applies the asking user's permissions, compiles the SQL, and logs which definition produced the number.

Why not a text-to-SQL agent, a definitions document or another semantic layer?

These are fair questions. Each option helps.

• Text-to-SQL agent with validation. Schema retrieval and query repair raise accuracy, as the Spider 2.0 leaderboard shows. The model still writes the SQL. Validation catches broken queries. It cannot know which of two valid revenue definitions your CFO approved.
• Curated definitions document. The paired study shows it works. It is static, someone must maintain it, and it enforces no access rules. See our note on knowledge drift and semantic decay.
• Another semantic layer. Metric stores such as the dbt Semantic Layer define metrics well. Compare how they differ from a semantic execution layer in our Colrows vs dbt Semantic Layer page.

Colrows adds a governance layer under these tools. It does not ask you to discard them. Swap Muse Wonder for another model next quarter and your definitions stay in place. For the mechanics, read the Colrows architecture documentation and our note on semantic layer vs semantic execution layer.

One fair objection: Wonder Full might close the SQL gap by itself. It might. A higher accuracy score would still leave the other three rows of the first table unsolved.

Data handling checklist before you test Muse Wonder

Your security team will ask where data goes. Meta's published terms give these answers today.

• Model API. In Standard mode, "your content is not used to train Meta models." Meta states that Contributor mode is not available for Muse Wonder on the Model API.³
• Muse Code. Subscriptions "default to Contributor mode." Turning it off applies to future content only.⁴ Wonder Full is available only here. Keep confidential data out of Muse Code until the setting is off and verified for your organization.
• Zero data retention. Meta offers it to qualified Model API organizations after separate approval. It does not support server-side conversation state.⁶ The public pages we checked do not say whether muse-wonder-1.0 qualifies. Ask Meta in writing.
• Self-hosting. Not possible. There are no downloadable weights.⁶
• Beyond these settings. Training use is one input to vendor due diligence. Retention, access by service personnel, subprocessors, data residency and contract terms are separate questions. Settings are accurate as of October 15, 2026. Verify the current terms before you decide.
• Serving variance. The model card warns that "performance can vary with quantization, serving configuration, prompts, tools, and the agent harness."² Your results will differ from any published score.

How to test Muse Wonder on your own warehouse

VentureBeat's conclusion applies here: neither set of published results replaces an evaluation against an enterprise's own workflows.⁶ Use this plan.

1. Collect 50 to 100 real business questions from finance, sales and operations.
2. Have the metric owners write and sign off the correct SQL. Do not trust unchecked gold queries (see the audit above).
3. Run each question through the model against the raw schema, using the API in Standard mode.
4. Run the same questions through the same model behind a semantic layer, with the same settings.
5. Repeat each question several times. Count how often the answer changes.
6. Record wrong answers, refusals and cost per task separately.

Check consistency as well as accuracy. A model that gives different answers on repeat runs fails an audit, even when most answers are correct.

Which Muse model should an enterprise team test?

Start with Muse Wonder through the API. It is the only one you can put behind your own service, it keeps your content out of training in Standard mode, and it lets you control the semantic layer and access policy in front of it. Treat Wonder Full as a developer tool inside Muse Code, with Contributor mode off and no confidential data. Compare both against at least one other frontier model at the same price tier before you commit.

Frequently asked questions

What is the difference between Muse Wonder and Muse Wonder Full?

Meta released both on October 12, 2026. Muse Wonder is available through the Meta Model API and Muse Code. Muse Wonder Full is available only through Muse Code plans and has no API. Artificial Analysis scores Full at 56 and Wonder at 52 on its Intelligence Index v4.3.

Can I call Muse Wonder Full through an API?

Not as of October 15, 2026. Meta's API pricing page lists only muse-wonder-1.0, and VentureBeat reports that Wonder Full is not offered through the API.

Are Muse Wonder and Muse Wonder Full open source?

No. VentureBeat reports that neither model has publicly downloadable weights. Meta's smaller Muse Glimmer model uses the Apache 2.0 license.

How accurate are Muse Wonder and Muse Wonder Full at text-to-SQL?

We found no public result as of October 15, 2026. Neither model appeared on the Spider 2.0 or BIRD leaderboards, and the model card sections we reviewed report no SQL benchmark.

Is it safe to use confidential data with Muse Wonder?

It depends on the access path. Meta states that content sent to the Model API in Standard mode is not used to train Meta models. Muse Code subscriptions default to Contributor mode, which lets Meta use your content. Keep confidential data out of Muse Code until you have turned Contributor mode off.

Do I still need a semantic layer if frontier models keep improving?

Yes. In a paired benchmark of three frontier models, adding a semantic layer document raised accuracy by 17 to 23 percentage points, and the models were statistically indistinguishable without it. A better model changes the baseline. It does not supply your metric definitions, access rules or audit trail.

Sources

1. Meta, "Introducing Muse Wonder and Muse Wonder Full," October 12, 2026 (updated October 13). about.fb.com
2. Meta, Muse Wonder model card, October 12, 2026. research.meta.ai
3. Meta, Model API pricing and rate limits. Accessed October 15, 2026. dev.meta.ai
4. Meta, Muse Code subscriptions. Accessed October 15, 2026. dev.meta.ai
5. Artificial Analysis, Muse Wonder article (Intelligence Index v4.3), October 12, 2026. artificialanalysis.ai
6. VentureBeat, "Meta's new Muse Wonder and Muse Wonder Full models achieve frontier performance, but only the weaker one is available via API," October 12, 2026. venturebeat.com
7. Jin, Choi, Zhu and Kang (University of Illinois), text-to-SQL benchmark annotation audit, CIDR 2026. vldb.org
8. Lei et al., "Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows," arXiv:2411.07763. arxiv.org
9. Rumiantsau and Fokeev, "Semantic Layers for Reliable LLM-Powered Data Analytics: A Paired Benchmark of Accuracy and Hallucination Across Three Frontier Models," arXiv:2604.25149, April 28, 2026. arxiv.org
10. Sequeda, Allemang and Jacob, "A Benchmark to Understand the Role of Knowledge Graphs on Large Language Model's Accuracy for Question Answering on Enterprise SQL Databases," arXiv:2311.07509. arxiv.org
11. Spider 2.0 leaderboards and BIRD leaderboard, checked October 15, 2026. spider2-sql.github.io and bird-bench.github.io