Muse Wonder and Full: Which Access Route Do You Need?
Find the official Muse Wonder API ID, distinguish Wonder Full subscription access, and check account, region, billing and first-request requirements.
Muse Wonder is available through Meta’s Model API and Muse Code. Muse Wonder Full is currently a Muse Code benefit for Power Usage and Maximum Usage subscribers, not a pay-as-you-go Model API model. Increasing Wonder’s reasoning effort to max does not turn it into Full.
Meta’s October 12 announcement introduced several product surfaces at once. This guide separates their access and billing rules using the official model documentation, checked October 15, 2026. We did not register an account, buy a subscription, or execute the paid API example. A documented route is not proof that your particular account has access.
Pick the route that matches the task
| Route | What it offers now | What not to assume |
|---|---|---|
| Model API, pay as you go | Wonder, exact ID muse-wonder-1.0 | No current Full PAYG API model |
| Muse Code | Wonder; Full through Power Usage or Maximum Usage subscriptions | A subscription is not a general-purpose API token package |
| Muse consumer experience | Announced rollout, initially for subscribers | “Coming soon” does not prove every account can select the model today |
The model documentation lists Wonder with text, image, video, audio, and PDF inputs and text output. Multimodal input support does not mean image or video generation. It also lists a 1,048,576-token context and reasoning levels through max; those settings do not establish real workload quality or a Full entitlement.
If your goal is Full specifically, start with the eligible Muse Code subscription and the actual model selector. Do not invent an API identifier such as muse-wonder-full, or keep raising the reasoning parameter while expecting a different model.
Check geography and account requirements first
The signup guide requires a user at least 18 years old, a supported region, and an account/team. Sending API requests also requires the relevant payment setup and an API key. Creating an account alone is not a completed API setup.
The Geographic Use Policy, updated October 12, explicitly lists China, including Hong Kong and Macau, and Russia among restricted territories. It restricts access from those locations and providing model-powered integrations to end users there, and prohibits bypassing geographic controls. Read the complete current policy for all listed territories and conditions; this paragraph is not an exhaustive country list.
Language does not determine location. A Chinese- or Russian-speaking reader elsewhere still needs to check their own jurisdiction and account. Conversely, the absence of Japan or South Korea from the examined restricted list is not our verification of every local account, payment method, or subscription benefit. The actual supported-country and onboarding rules still apply.
When your location or use is restricted, stop at research and choose a service authorized for that use. A gateway, VPN, or foreign payment method is not evidence that the underlying policy no longer applies.
The official Wonder API details
The API overview and Create a response reference establish this route:
| Field | Documented value |
|---|---|
| Base URL | https://api.meta.ai/v1 |
| Responses endpoint | POST https://api.meta.ai/v1/responses |
| Model | muse-wonder-1.0 |
| Authentication | Authorization: Bearer $MODEL_API_KEY |
| Minimal body fields | model, input |
The documentation also lists Chat Completions and Messages interfaces. Choose one documented interface and its matching request schema. Do not paste a body from another API family and assume that changing the URL is sufficient. Some generic examples still use Muse Spark; the official overview explicitly allows replacing the model with muse-wonder-1.0 for Wonder.
For eligible accounts, this is a minimal documented Responses request. Running it can incur usage charges. It has not been executed for this article. Set the key securely in your own environment; never put a real key in an article, screenshot, or shared terminal log.
curl --fail-with-body -sS https://api.meta.ai/v1/responses \
-H "Authorization: Bearer $MODEL_API_KEY" \
-H 'Content-Type: application/json' \
-d '{"model":"muse-wonder-1.0","input":"Reply with the word ready."}'
Here ready is the requested acceptance target, not a captured result. If you use the OpenAI SDK as shown in Meta’s documentation, set both the Meta base URL and the Meta key. Leaving the SDK’s default OpenAI endpoint in place sends the request to a different provider.
Verify a first request without inventing success
Use the access worksheet to record checks before and after an authorized request. It contains no credentials and no prefilled success results.
Before calling, record the chosen product, region-policy check, account/team, model entitlement, billing source, endpoint, and exact model ID. Confirm that a PAYG request is intended; a Code subscription may not fund it.
After calling, verify:
- The HTTP status and any structured error. A network response is not automatically an inference success.
- The response status. If it is incomplete or failed, inspect its details instead of treating any returned object as a completed answer.
- The text content in
outputmessage items and theiroutput_textcontent. Do not assume the raw REST JSON has a single top-level answer string. - The requested output task, returned model information where provided, and usage fields.
- The corresponding account’s usage and billing record. An answer alone does not show which balance paid for it.
Retain a redacted result and timestamp if your own policy permits. Do not turn an official sample response into a claim that Ofox tested the model. We provide the verification sequence, not a fabricated response screenshot.
Muse Code subscriptions have different credentials
The subscription documentation says subscription access is tied to credentials automatically connected during CLI onboarding and is for Muse Code. Additional API keys created separately remain pay as you go. That distinction matters if you subscribe, then build an application using a new API key: the application does not automatically inherit the Code allowance.
The same documentation describes Contributor mode as the subscription default, allowing content to be used for training. It can be turned off; future content after disabling it is not used for training under that setting. Review the current account choice and policy before sending private work. Wonder’s PAYG availability is Standard mode; do not assume a subscription’s mode or benefits transfer to a separate API key.
Full access depends on the specified subscription tiers and actual onboarding availability. Regional benefits may differ. Record what the account displays rather than presenting a global entitlement promise.
When the model or request does not work
| Symptom | Check next | Evidence that would resolve it |
|---|---|---|
| Full absent from a PAYG model list | Product route | Official availability says Full is a Code subscription benefit |
| Wonder call reaches the wrong provider | Base URL and SDK initialization | Meta endpoint and intended key are configured together |
| Authentication or permission failure | Key validity, team, account access | Redacted error plus account settings; never the secret itself |
| Model not found | Exact model ID and supported interface | muse-wonder-1.0 on the documented route, with account entitlement |
| Paid API usage despite a Code subscription | Credential origin and billing | Separate API key versus onboarding-linked Code credentials |
| Model absent in the consumer app | Rollout and account availability | Actual account selector, not merely the launch announcement |
Do not try unrelated identifiers until something returns a result; that may test a different model while leaving the original question unanswered. Preserve the first error and change one configuration issue at a time.
What the launch does not establish
Active Memory and Focus are described as system capabilities in the announcement. They are not evidence that every raw API request automatically keeps memory across sessions. Design state handling around the documented endpoint and product you use, then verify behavior with your own authorized tests.
Similarly, launch benchmark claims are not a task-specific comparison. This article does not rank Wonder against other models, claim Ofox availability, or quote an unverified price. For a related example of separating artifacts from account access, see Step 5 Preview weights versus API routes.
The task is complete when you can name the correct product and model, confirm applicable region/account conditions, identify the actual billing path, and record the outcome of your own permitted access check. If any of those remain unknown, keep that field unresolved rather than converting a launch announcement into a successful deployment claim.


