Muse Wonder vs Wonder Full: Pricing, Access and Which to Choose

Muse Wonder and Muse Wonder Full are different models with different buying routes. Choose ordinary Wonder when you need metered API access or want to start on a lower Muse Code tier. Choose Full when you specifically want that model inside an eligible Muse Code subscription. A higher API reasoning budget does not establish that you have purchased Full, and ordinary Wonder's token price cannot tell you what a Full subscription will cost per completed task.

The useful decision has three parts: which model you need, where you can access it, and how you will measure the work it finishes. Here is a practical way to keep those parts separate before committing a real project or recurring budget.

The entry price for documented Full access is $50 per month, not $200. The $200 tier provides four times Power's advertised usage for four times its fee. For the API, the most useful number is the cost of your actual fresh input, cache hits, output and searches; the worked response below shows how to derive it without counting cached input twice. Prices and access were checked on October 14, 2026.

Wonder and Full: choose the model before the plan

Meta introduced the family on October 12, 2026. Its model page positions both for demanding agent and coding work, with Full as the higher-capability option. That positioning is a provider claim, not a finding from a test conducted for this article.

Checked October 14, 2026. Confirm the current account offer before buying; availability and terms can change.

Start with the output you need. “Help me maintain this repository” describes different work from “give me a website I can review and publish.” For repository work, your files, tests, development environment and review habits may matter more than a model's name. For a new product, include interface design, asset placement, data requirements and deployment in the scope.

Then decide what you are evaluating. If the question is whether Full produces more useful changes, compare actual changes under clear acceptance criteria. If the question is whether an API can fit your operating budget, use its documented rates and your own usage records. Those are related questions, but a price calculation cannot answer the quality question.

Which Muse Code plan includes Wonder Full?

The Muse Code page and Full's official access block describe the following subscription choices:

Source: the current Muse Code plan blocks, checked October 14. Everyday advertises 10–50 prompts per five-hour period; the higher tiers publish usage multipliers. Those are not fixed Full prompt counts. Model choice, task size and the account's current settings still matter.

Normalize the published fee by its advertised usage multiplier: Everyday is $5 per baseline unit, High $3, Power $2.50 and Maximum $2.50. This is our arithmetic on the plan table, not a provider billing unit. It shows why moving from Power to Maximum buys more advertised capacity without improving this normalized fee ratio. The table also does not list a different Full model for Maximum. Start the Full comparison at Power, then justify the $150 monthly upgrade with an observed capacity constraint or another documented benefit.

These are Code plans, not the similarly named consumer Muse app plans. In particular, the $50 Power Usage plan is a Full route; Full is not reserved solely for Maximum Usage. The token-based API and the consumer assistant are also separate purchases.

Meta's launch announcement says Wonder will power consumer Muse experiences and roll out first to subscribers. That announcement does not establish that every consumer account already has it. If you need a model today, check the actual selector and the plan's current eligibility rather than inferring access from a subscription name.

Before upgrading, use this sequence:

1. Identify the product you are buying: consumer Muse, Muse Code or the developer API.
2. Read the exact plan name in the account you intend to use.
3. Check whether the model selector exposes the wanted model, rather than only a related family name.
4. Confirm included usage, reset conditions and any separately charged usage in the current checkout or account documentation.
5. Save the terms you relied on, then try a bounded piece of work before moving a larger project.

This sequence is especially useful when an article's pricing table and its FAQ disagree. The provider's current access documentation should resolve eligibility. A third-party summary can help explain the choices, but it cannot grant access or determine what your account will show.

API pricing: build a budget from actual usage

Ordinary Wonder's published standard rates are $4 per million fresh input tokens, $0.20 per million cached input tokens and $20 per million output tokens. Search grounding is billed separately at $2.50 per thousand actual queries.

For Muse Wonder pricing, keep the token categories separate. Cached input is a subset of the input processed at the discounted rate, not an additional copy of the entire input. A repeated instruction is not proof that the provider charged it as a cache hit; read the usage categories returned by the service.

For a small budgeting worksheet, use:

def wonder_cost(fresh_input, cached_input, output, search_queries=0):
    counts = (fresh_input, cached_input, output, search_queries)
    if not all(n >= 0 for n in counts):
        raise ValueError("Usage counts must be non-negative")
    return (
        fresh_input * 4 / 1_000_000
        + cached_input * 0.20 / 1_000_000
        + output * 20 / 1_000_000
        + search_queries * 2.50 / 1_000
    )

assert round(wonder_cost(100_000, 0, 10_000), 9) == 0.60
assert round(wonder_cost(0, 100_000, 10_000), 9) == 0.22
assert round(wonder_cost(100_000, 0, 10_000, 10), 9) == 0.625

This is a price calculator, not an inference client. The examples use invented usage counts, and the checks verify arithmetic only. No Wonder request was run to produce these token amounts.

The entirely cached row is an arithmetic illustration, not a prediction of a real request. New instructions, edits and account-specific caching behavior can change the distribution. A useful estimate should include several real attempts, not only the cheapest one.

Convert a response into a bill

Meta's prompt-caching documentation distinguishes two response shapes. Within usage, Responses puts cached_tokens inside input_tokens_details; Chat Completions puts it inside prompt_tokens_details. Both are subsets of total input. For Responses, fresh input is therefore input_tokens - cached_tokens.

This invented usage fixture follows the documented Responses field names. It is not a response obtained from a model call:

sample_usage = {
    "input_tokens": 100_000,
    "input_tokens_details": {"cached_tokens": 80_000},
    "output_tokens": 10_000,
}
total_input = sample_usage["input_tokens"]
cache_hits = sample_usage["input_tokens_details"]["cached_tokens"]
if not (cache_hits >= 0 and total_input >= cache_hits):
    raise ValueError("Cached input must be a subset of total input")
subtotal = wonder_cost(total_input - cache_hits, cache_hits,
                       sample_usage["output_tokens"])
assert round(subtotal, 9) == 0.296

The chain is explicit: $0.08 fresh input + $0.016 cached input + $0.20 output = $0.296. With ten separately billed searches, it becomes $0.321. Treating all 100,000 input tokens as fresh and then adding cache hits would produce the wrong $0.616 total before search. Preserve the raw response and its model ID beside the worksheet so another person can reproduce the classification.

For scale, 100 repetitions of the fresh, mixed and fully cached illustrations cost $60, $29.60 and $22 respectively before search. All assume 10,000 billed output tokens per attempt. An additional 10,000 output tokens adds $0.20 at the listed rate, so a larger answer can offset part of the cache saving. None of these rows predicts how many attempts your task will need.

Copy this header into your own log:

task_id,attempt_id,model_id,fresh_input,cached_input,output,search_queries,subtotal_usd,accepted,review_notes

Use a stable task ID for the original request and a new attempt ID whenever the model retries or you ask for a correction. Keep rejected attempts in the file. Otherwise, a task that needed several attempts will look like a cheap successful request because the failed work disappeared from the calculation.

When you have results, sum the subtotals for the whole task. Separately note hosting, external services, taxes where applicable and your review time. The token worksheet deliberately does not price those items. It also cannot determine whether a generated change is correct; acceptance belongs to the task's tests and human review.

Why $50 of API calls is not a Full subscription

In the fresh-context toy example, one hundred identical attempts would total $60. At the entirely cached illustrative rate, the same number would total $22. Dividing $50 by the fresh-context example's $0.60 yields about 83.33 attempts.

That division is useful for seeing the scale of the assumed API workload. It is not a subscription break-even result. The API example uses ordinary Wonder, while a Power subscription can provide Full. A monthly fee also does not specify a freely interchangeable amount of API tokens or a guaranteed number of completed app tasks.

To make a useful purchase comparison, write down:

• The model and route you actually want.
• The included usage and reset conditions that the current account documents.
• Your expected workload, using observed usage where possible.
• What happens when included usage is exhausted.
• What counts as an acceptable result and how much review it needs.

If you need an API inside your own application, the subscription's headline price is not the decisive comparison. The decisive question is whether the route supports your integration and its operating requirements. If you need Full in a terminal coding workflow, ordinary Wonder API arithmetic does not establish that the cheaper-looking option is an equivalent purchase.

Avoid starting with the largest plan as a precaution. Define a small useful task, try the documented route and use the resulting usage record to decide whether more capacity would solve a real limitation. More allowance helps only if allowance is the thing preventing useful work.

Check the shared API limit as well as the price

Meta's rate-limit table lists 3,000 requests and 4,000,000 tokens per minute for muse-wonder-1.0, shared across a team rather than granted separately to each key. In a simplified steady workload of 100,000 total input plus 10,000 output tokens per request, floor(4,000,000 / 110,000) is 36 requests per minute. The token budget would bind before the request-count limit. This is a planning ceiling from the published limits, not measured throughput or a service guarantee; variable request sizes and remaining quota require headroom.

Parallel agents share that team budget. Check the returned x-ratelimit-remaining-tokens and x-ratelimit-remaining-requests headers; on a rejection, honor Retry-After. A second API key does not create another team allowance. This explains an apparent contradiction a price-only comparison misses: a workload can fit its dollar budget and still exceed its throughput budget.

Check settings before sending a real codebase

Meta documents Standard and Contributor pricing modes. Its pricing page says Standard-mode content is not used to train Meta models. Wonder on the Model API has no Contributor variant. Muse Code subscriptions default to Contributor mode, which can be changed in settings; that mode permits use of submitted content and responses for training as described by Meta.

Treat these as documented product settings, not as a complete assessment of your organization's requirements. Inspect the actual configuration before sharing project files. A subscription price and a token rate can reflect different settings, so they should not be compared as though the service conditions were identical.

For a first trial, supply only the material needed to finish the chosen task. State which files may change, what should remain compatible and which checks decide acceptance. Keep the resulting diff and the usage record together. That lets you distinguish a model-quality problem, an environment problem and a usage-budget problem when the trial falls short.

If your goal is a first website, compare the whole workflow

Choosing a coding model is one way to approach a new product. Atoms offers a related route: describe the product in natural language, review the generated website or application and iterate through conversation. The relevant comparison is the workflow and the output you need, rather than assuming either Wonder model is available inside Atoms.

For example, use a scoped brief for a small product catalog: supplied items, category filters, a clear empty state and a layout that remains usable on a phone. Define the expected interactions before comparing tools. A polished homepage alone does not establish that filtering, saved data or checkout works.

The storefront examples below illustrate product contexts from the Atoms library. They are not Wonder or Full tests, and their videos do not establish that the proposed catalog acceptance checks have passed.

Mattress Brand E-commerce Web

Mattress Brand E-commerce Web — DEEPREST is a premium mattress storefront in the Atoms library. A comparable brief should supply the mattress catalog, approved product wording and image associations before evaluating the generated presentation.

Workwear Heritage Store

Workwear Heritage Store — KOSTA is a modern workwear storefront. For this kind of project, define the garment categories and the reset behavior in the input brief, then check the resulting page against those supplied records.

Sleepwear Brand Store

Sleepwear Brand Store — MOONHOUSE is a premium sleepwear storefront. Specify the product imagery and mobile browsing priorities up front, so visual polish and preserved catalog content can be assessed separately.

If you are evaluating several coding routes, the existing Codex pricing guide can help you separate subscriptions from usage meters. Carry the same project scope into each option so differences in the requested work do not decide the comparison for you.

Conclusion

Choose the model first, verify its actual purchase route, then estimate the usage you can observe. Full requires an eligible Muse Code subscription; ordinary Wonder's API rate is a separate budgeting question. Use the worksheet to understand the meter and a bounded task to judge the work.

If the goal is a first product rather than maintaining an existing repository, start in Atoms with that same scoped brief. Review the product against your acceptance criteria before deciding which workflow to keep.

FAQs

Q1: Can I use Muse Wonder Full through the Meta Model API?

At the October 14 check, Meta lists Full as a Muse Code subscription model. Ordinary Wonder is available through the Model API. Do not attach ordinary Wonder's published token rate to Full when comparing purchases.

Q2: Does the $15 Muse Code plan include Full?

Meta's documented Full routes are Power Usage and Maximum Usage. High Usage is a different tier. Verify the exact plan name and model selector in your account before upgrading.

Q3: Does a consumer Muse subscription give me Muse Code access?

They are separate access products in the documentation discussed here. The launch also describes a forthcoming consumer rollout, so a consumer subscription should not be treated as proof that a coding model is available in that account today.

Q4: Can I convert a monthly Code fee into API tokens?

Not from the headline fee alone. The model, route, settings and included usage differ. Use the account's actual terms for the subscription and observed usage categories for the API; the toy calculations above establish no subscription allowance.

Q5: Are Wonder and Full available in Atoms?

This comparison does not establish either integration. Check the current model selector if a specific model is essential. Atoms is relevant here as an alternative product-building workflow, not as an asserted Full endpoint.