Meta Muse Wonder API: Should Your Startup Switch?

Meta released Muse Wonder on October 12, 2026, and it is the first model from Meta that sits in the same price bracket as the frontier models from Anthropic, OpenAI and Google. It is a self-serve API preview, which means you can get a key without a sales call, but Meta is calling it a preview and not a general release.

Reported launch pricing is $4 per million input tokens and $20 per million output tokens, with cached input around $0.20 per million and no premium for long prompts. Those are the numbers that were published in trackers the week it launched. Pricing for a preview can move, so treat them as the starting point for a model, not a contract.

There is a second, bigger model called Muse Wonder Full. It has no API. You only get it inside Muse Code, Meta's coding product, which is sold in plans starting around $50 a month with a $200 tier above it. If you read a benchmark chart that puts Muse Wonder at the top, check which of the two models it measured. The one you can call from your backend is the smaller one.

Three days later Meta also published Muse Spark Open, an open-weights model with a 1M token context window under the Muse Model License. Hosts list it at roughly $1.25 input and $4.25 output per million tokens. That is a different decision with different economics, and I cover how to think about it in our piece on self-hosting open-weight frontier models versus paying an API. This post is about the paid preview.

My position, up front: do not move production traffic to Muse Wonder this month. Do run it against your own prompts for two weeks, because a fourth serious vendor changes your negotiating position and your failover plan even if you never switch. The rest of this post is how to run that test without wasting an engineer's quarter.

Here is the part founders miss. At $4 and $20, Muse Wonder costs the same per token as Claude Opus 5.5. Meta did not undercut anyone. It priced itself as a peer, and it wants to be judged as one.

That matters because the per-token rate is only half of your bill. What you pay per finished task depends on how many tokens the model burns to get there. One tracker that scored the models on the Artificial Analysis index put Muse Wonder at 52 for about $4.52 per task, and Opus 5.5 at 58 for about $5.98 per task. Read that carefully. On those numbers Wonder is cheaper per task and also lower on the index. You are paying less and getting a lower score, which is not a bargain or a rip-off. It is a different point on the same curve.

I would not build a decision on that one tracker. Indexes weight tasks you may not care about, and a preview model can get retuned between measurements. What the numbers do tell you is that the per-token price comparison is a red herring. A model that thinks for fewer tokens at the same rate wins on cost, and a model that needs two attempts loses even at half the rate.

If you want the full picture of what the incumbent costs you at this tier, read our breakdown of the Claude Opus 5.5 migration and what it saves. It is the baseline Muse Wonder has to beat for your workload.

The cached input price is the second place to look. At $0.20 per million, a feature that sends the same long system prompt or the same document on every call can cut its input bill by roughly 95 percent after the first request. Any app with a stable prefix, such as a support agent with a policy document, should model its cost with caching on, because that is how the bill will actually look.

Meta's launch material shows Muse Wonder ahead of Opus 5.5 on some long-horizon coding tests and behind it on others. Those results come from Meta, and nobody outside the company had reproduced them in the first week. That is normal for a launch. It is also why I ignore the first week of benchmark threads for every model, mine included when I am tempted.

There are three reasons a public benchmark will mislead you on your own product.

• Your prompts are not the benchmark's prompts. A model tuned on coding tasks can be mediocre at extracting fields from a messy insurance PDF.
• Your failure cost is not uniform. A benchmark counts a wrong answer as one point. In your app, a wrong refund amount costs you a customer and a wrong summary costs you nothing.
• Your latency budget is not the benchmark's. Most leaderboards ignore time to first token, and your users feel nothing else.

So the only benchmark worth running is yours. It does not need to be fancy. Pull 100 real requests from your logs, strip anything private, and save the inputs along with the answer your current model gave and a note on whether a human accepted it. That is a dataset. A founder with 100 labeled examples knows more about which model to use than someone who has read forty launch threads.

If you do not have logs yet because you are pre-launch, write 40 prompts by hand that cover the happy path, the weird path and the abuse path. Include a few where the right answer is "I do not know." Models differ more on refusing well than on answering well.

Here is the plan I would hand a seed-stage team. It assumes you already call one model in production and have a thin wrapper around the call. If you do not have the wrapper, build it first. You will want it for every vendor change from here on.

1. Days 1 and 2. Freeze the dataset. Collect the 100 requests, remove personal data, and write the grading rule. A grading rule is one sentence per task type, such as "the extracted total must match the invoice to the cent."
2. Days 3 and 4. Replay. Send every request to Muse Wonder and to your current model with identical prompts. Log tokens in, tokens out, time to first token, total time and the answer. Do not tune prompts for Wonder yet.
3. Day 5. Grade blind. Shuffle the outputs, hide the model names and have someone who knows the product mark each one. Two people is better than one.
4. Days 6 to 8. Tune once. Give each model one round of prompt changes. Models have different habits, and a fair test lets both adapt. One round, not ten.
5. Days 9 to 12. Shadow traffic. Send a small slice of live requests to Wonder in the background and compare against what you actually returned. No user sees the output.
6. Days 13 and 14. Decide. Write down cost per accepted answer, p50 and p95 latency, and the failure modes you saw.

Cost per accepted answer is the number that settles arguments. Divide the total spend by the count of answers a human would accept. A cheaper model with a 70 percent acceptance rate can cost more per good answer than an expensive one at 95 percent, because the rejected answers cost you the call plus the retry plus the support ticket.

Budget for this honestly. The API spend for 100 requests across two models, with some long-context cases, usually lands in the tens of dollars. The expensive part is the two or three hours of grading, and that is the part you must not skip.

A preview API comes with a preview agreement, and founders skip it because they are excited about the model. Read it first. There are five things I check on every new vendor, and I have seen each one change the decision.

• Training on your data. Does the API train on prompts by default, and is there an opt-out? Reporting on Muse Code mentions a training setting that is on by default, and the details were not clear to me at launch. If your users upload anything sensitive, get the answer in writing before you send a single real request.
• Retention. How long are prompts stored, and can you set it to zero?
• Rate limits for a preview. A preview often caps requests per minute well below what a launch day needs. If you cannot get a limit that covers your peak, the model cannot be your primary.
• Deprecation notice. How many days of warning do you get before a model version is retired? This year has shown how short that can be.
• Region and compliance. If you sell to healthcare or finance buyers, ask where inference runs and which attestations exist. A preview rarely has a SOC 2 report you can hand to a customer.

I would also ask about the license on outputs. Some model licenses restrict using outputs to train competing models. If you are planning to fine-tune a small model on your logs later, that clause can quietly rule out your whole plan.

None of this is a reason to avoid the preview. It is a reason to keep it away from regulated data until the terms are final, and to run your test on synthetic or scrubbed inputs.

I do not think any new frontier model replaces your incumbent outright in the first month. I do think there are three places one can earn a slot, and they are worth testing in this order.

As your fallback. If your product depends on one vendor, an outage becomes your outage. A second frontier-class provider with a different parent company is the cheapest insurance you can buy, and a model priced like Opus 5.5 is not much of a premium when it only takes the traffic during an incident. This is the lowest-risk use and the one I would start with. Design the failover once and it works for every vendor after this one.

As a specialist in a routing setup. Some tasks will suit it better than your default. You will only find out by grading, and the answer is rarely the same for summarizing, extraction and code. A router that sends each task type to the best model per accepted answer is how teams cut the bill by a third without hurting quality. Our guide to AI model routing and LLM cost optimization covers the mechanics.

As a bargaining chip in a price conversation. If you spend five figures a month with a vendor, a credible alternative that you have already tested gets you a call with a human who has authority to discount. You do not need to switch for this to work. You need a graded dataset and a working integration.

Where I would not use it yet is as the engine behind a feature with legal or financial consequences, such as contract review or pricing decisions. A preview model has not had the months of real-world failure reports that the incumbents have. Let other teams find the weird edge cases.

For a wider look at how the three big vendors compare for typical app work, see our Claude vs GPT vs Gemini comparison for apps. Muse Wonder is a fourth column in that table now, and the right way to fill it in is with your own numbers.

Do not let the API test and the coding product blur together. Muse Code is a tool for your developers. The API is a component in your product. They are bought by different people, billed differently and judged on different outcomes.

The coding plans start at roughly $50 a month, and the full model sits behind them. If you are a founder paying for AI coding tools for a team of three, the question is not the benchmark. The question is how many accepted pull requests per week each seat produces and how much review time the output costs you. A tool that writes more code and doubles your review load is a loss.

Usage-based billing has changed the math on these tools this year, and I wrote about it in how to budget for AI coding tools that bill by usage. The short version is that a flat $50 plan may have limits you hit by Wednesday, and the overage is where the real price lives. Ask what happens at the limit before you buy seats.

My advice for a small team is to let one developer try it for two weeks on real tickets. Track the tickets closed, the bugs found in review and the hours spent fixing the output. If you cannot measure those three, you are buying vibes. A tool earns its seat when it saves more review-adjusted hours than it costs in plan fees plus overage, and not before.

The data setting deserves a flag here too. If a coding tool trains on your code by default, your private repository is the training set. Turn it off or read exactly what it covers before the first commit goes through.

If you run an AI feature in production today, this is the sequence I would follow, and none of it requires betting the company on a preview.

1. Build or confirm the model wrapper, so a vendor change is a config change and not a rewrite.
2. Save 100 graded requests. Keep them forever. They are the most useful artifact in your AI stack.
3. Run the two-week test on Muse Wonder with scrubbed data, and write down cost per accepted answer.
4. Read the terms on data use, retention and deprecation, and keep a one-page summary in your vendor folder.
5. If it wins a task type, route that slice to it behind a flag. If it loses everywhere, shelve the result and rerun when the preview becomes a general release.

The pattern here outlasts this model. Every few weeks another lab ships something that looks like it changes everything, and the founders who benefit are the ones with a dataset and a wrapper, not the ones who read the most threads. Pricing will move, previews will become releases, and some of this post will be stale by the time Meta publishes final terms. Your graded dataset will not go stale.

If you are weighing a model switch and want a second opinion on the test design, the routing setup or the failover plan, bring your current monthly model bill to a call and we will go through it. Book a free strategy call.