Choosing a Meta Muse model is only the first design decision. The more important question is what the model is allowed to decide, which application owns the resulting action, and how the workflow prevents an incorrect or repeated response from becoming a business record.
Use Muse Wonder for complex, long-running reasoning and software work; Muse Spark 1.3 for general reasoning and bounded interpretation; Muse Ember for efficient, repeatable subtasks; and Muse Glimmer when local or edge deployment is the requirement. For example, a support workflow can use deterministic rules to detect duplicate events, Spark to classify ambiguous customer wording, and application code to validate a proposed ticket update before committing it.
This guide compares the current model routes and documented API capabilities, then turns them into practical workflow patterns. The examples are proposed application designs, not Meta templates or guarantees of operational success.
Which Meta Muse model should you choose?
Meta positions Wonder for complex work, Spark for general-purpose reasoning, and Ember for efficient repeated tasks. Those are vendor-described workload distinctions, not independently verified rankings. Glimmer is a separate local-deployment choice rather than another hosted Model API option.
| Model | Best fit | Access | Operational tradeoff |
|---|---|---|---|
Muse Wondermuse-wonder-1.0 |
Complex reasoning, long-running agents, software engineering, and multi-file work | Meta Model API and Muse Code | Higher token cost. Reserve it for work that justifies the additional reasoning capacity. |
Muse Spark 1.3muse-spark-1.3 |
General reasoning, summaries, and bounded workflow decisions | Meta Model API and other documented Meta product routes | A practical starting point for interpreting ambiguous text inside a controlled process. |
Muse Embermuse-ember-1.0 |
Repeated routing, extraction, tool calls, and other bounded subtasks | Meta Model API and Muse Code | Cost-efficient for high-volume work. Requests over 200,000 input tokens use a higher tier. |
| Muse Glimmer | Local or edge deployment where the operator must run the weights on its own infrastructure | Self-hosted, not a Meta Model API endpoint | Your team owns the runtime, hardware, permissions, logging, retries, and tool execution. |
Meta’s model reference lists current model IDs and availability. Its model-selection guide explains the intended workload distinctions. Wonder Full is a Muse Code offering for eligible Power Usage and Maximum Usage plans, not a separate API model. Increasing Wonder’s reasoning effort does not select Wonder Full.
Meta describes Glimmer as an open-weight 30-billion-parameter model intended for local or edge use. Its research page reports selected benchmark comparisons, which should be read as Meta’s reported results rather than universal performance guarantees. Hardware, quantization, runtime, and benchmark settings affect the result.
Let deterministic rules own known facts, permissions, thresholds, and duplicate checks. Use a model for the judgment it has been assigned, such as interpreting ambiguous language.
In practice, use rules for exact thresholds, access checks, required fields, known routing, and duplicate detection. Spark can interpret unclear text or produce a bounded summary. Wonder is a better candidate when the reasoning or software task is substantially more involved. Ember fits repeated subtasks after the process has already determined what needs doing. Glimmer is appropriate only when local operation matters enough to justify owning the surrounding infrastructure.
What do Muse models cost, and where can you use them?
At the November 12, 2026 research date, Meta’s pricing documentation listed these standard API rates per million tokens. Model IDs, prices, plan eligibility, and rollout status can change, so confirm the current pricing and rate limits before budgeting or deployment.
| Model and mode | Input | Cached input | Output |
|---|---|---|---|
| Wonder, Standard | $4.00 | $0.20 | $20.00 |
| Spark 1.3, Standard | $1.25 | $0.15 | $4.25 |
| Spark 1.3, Contributor | $0.10 | Not listed | $0.20 |
| Ember, up to 200,000 input tokens | $0.10 | Check live pricing | $0.50 |
For Ember requests above 200,000 input tokens, Meta lists $0.30 per million input tokens and $1.50 per million output tokens. The higher tier applies to the whole request, not only the tokens above the threshold. Contributor pricing is a separate choice. Meta’s documentation says prompts, code, files, context, and responses may be used to train future Meta models in this mode. Choose it only after your organization has reviewed and accepted that condition.
Estimate cost from the expected mix of input, cached input, output, and long-context requests. Output tokens alone are not a useful budget. Wonder Full is not available through the Model API, and Glimmer is self-hosted rather than an API endpoint.
Muse Code is Meta’s terminal and CI coding-agent route, with documented interactive and headless operation, approvals, workspace trust, and sandboxing. Its documentation identifies Spark 1.2 as the default in one installation flow, so record the model ID used rather than assuming that an installation selects the newest version. Muse, Meta’s personal agent powered by Spark, is a separate product route whose availability can depend on rollout, account, platform, and location.
How to turn a Muse response into a usable workflow result
For a hosted API workflow, send text or supported file input to a chosen model, provide a JSON Schema through structured output, parse the response, and validate its meaning in application code. Meta documents structured output as a way to constrain response shape. A schema-valid value can still be unsupported by the source, attached to the wrong record, unauthorized, or an invalid business-state transition.
Consider this hypothetical support-ticket classification flow. The support platform remains the system of record. A workflow service receives the ticket event and sends its text to Spark. The model proposes a category, concise summary, and evidence spans. It does not authorize a refund, change a ticket status, or write directly to the support system.
{
"source_event_id": "ticket-84721",
"source_system": "support",
"tenant_id": "tenant-42",
"run_id": "run-20261112-00481",
"response_id": "response-abc123",
"model_id": "muse-spark-1.3",
"prompt_version": "triage-v1",
"schema_version": "ticket-triage-v1",
"category": "damaged_item",
"summary": "Customer reports a damaged replacement and asks about a refund.",
"evidence_spans": [
{
"text": "replacement arrived damaged",
"source_location": "ticket body"
}
],
"validation_status": "pending",
"approval_status": "not_required_for_classification"
}The object above is an illustrative application contract, not a Meta schema or vendor workflow template. The application should check that the category is allowed, the evidence appears in the source, the event maps to the intended ticket, and any destination state is permitted. Store the source reference, model and prompt versions, schema version, run identifier, response identifier, model output, and validation result as separate audit facts.
Meta’s structured-output guide documents the JSON Schema mechanism, and its file-handling guide describes supported file-input approaches and limits. The documentation lists inline files up to 50 MB and uploaded files up to 1 GiB under the cited conditions. Confirm supported MIME types and limits for the actual input. A confidence value can be requested as an application-defined field, but it is not a vendor-guaranteed measure of correctness.
How to let a Muse model request an external action
Meta’s function tool calling lets a developer define a tool and parameter schema. The model may return one or more tool calls. The application validates each call, runs the function, returns a result associated with each tool-call ID, and continues the loop or stops it. The API does not execute your business function. Your application owns authorization, validation, side effects, retries, and audit records.
For a hypothetical CRM update, define a narrow function such as prepare_crm_update with fields for a tenant, destination record ID, proposed status, summary, and idempotency key. Before any write, application code checks tenant and record identity, caller authorization, required fields, allowed status transitions, and whether approval is required. Stage customer-visible or irreversible changes for approval. After approval, execute the CRM write with the same idempotency key across retries.
A search-before-create check can still produce duplicate CRM records when two workers process the same event at once. Enforce a unique key such as tenant, source system, source event ID, and workflow version in the database. Use an atomic insert, upsert, or insert-on-conflict operation, and retain the same idempotency key when a timeout causes a retry.
Keep separate records for the source event, each model run, and each tool call. A source event can be keyed by tenant, source system, and stable event ID. A model run gets its own run ID and links back to that event. A tool-call record retains the API tool-call ID, validated arguments, execution status, and downstream response. If a run produces multiple citations, store each citation as a separate record with the run ID and citation ordinal or another unique citation ID.
The tool-calling guide and cookbook example document the API loop and argument-validation pattern. The cookbook is a runnable building block, not a complete CRM integration. Set a maximum turn count and handle timeouts, partial success, rate limits, repeated calls, and downstream failures explicitly.
Teams designing bounded agent actions may find AI agent design and implementation relevant. For CRM-specific ownership, transitions, and write-back design, see CRM systems and workflow design.
Should you use the Meta API, Muse, Muse Code, or Zapier?
These are different access routes, not interchangeable names for one integration. Choose based on control requirements, app coverage, and who will operate the workflow.
| Route | Best fit | Control or limitation to verify | Typical next step |
|---|---|---|---|
| Meta Model API | An application needs exact model IDs, custom schemas, developer-defined tools, run records, and application-owned write-back. | Your team must implement authentication, authorization, validation, retries, idempotency, and destination writes. | Build a service around a documented model ID and store each source event, run, and tool call separately. |
| Spark in a Zap | A team wants a low-code reasoning or transformation step between an existing Zap trigger and later app actions. | Available fields, model controls, task limits, authentication, and downstream actions depend on the configured Zap. | Confirm the exact trigger, AI step fields, destination action, and review route before promising a workflow. |
| Muse with Zapier MCP | A user wants Muse to request permitted Zapier actions in a conversation. | App actions, permissions, authentication, limits, reversibility, and confirmation behavior are app-specific. | Connect only the required apps and test the exact search, create, update, or delete action. |
| Muse Code or Glimmer | Muse Code suits terminal and CI coding work. Glimmer suits teams requiring local model operation. | Confirm the Muse Code model ID and sandbox settings. For Glimmer, operate the runtime, tools, storage, and monitoring yourself. | Record the actual model, platform, permissions, and execution environment used. |
Zapier’s Muse automation guide describes both the AI-step and MCP patterns. Its connector announcement explains the named connector. These sources do not establish that every app supports identical actions, fields, authentication, limits, or reversibility. For teams using this route, Zapier automation support is relevant to assessing app coverage and workflow design.
Meta describes Muse as a personal agent powered by Spark that operates through Muse Secure VM, with permissions, confirmations for sensitive actions, and an audit trail. These are Meta’s product descriptions, not an independent security certification. Similarly, local Glimmer weights do not automatically provide permission boundaries, safe tool execution, logging, or recovery controls.
What should you measure before expanding a Muse workflow?
Compare the workflow with its existing manual or deterministic baseline using the same task definition. Useful measures include valid-output rate, human correction rate, exception rate, duplicate side effects, latency, token cost per completed item, and completion time. Define what counts as a completed item before comparing results. Do not treat an illustrative target as product performance.
Keep the data grain explicit:
- Source event: one received business event, identified by a stable source-system and tenant-aware event key.
- Model run: one model attempt for one source event, with its own run ID, model ID, prompt version, schema version, and response ID.
- Tool call: one requested action, linked to the run and API tool-call ID, with validated arguments and execution status.
- Citation: one source reference from a run. Multiple citations require separate citation IDs or a run ID plus citation ordinal.
- Aggregate metric: a defined period, workflow version, model variant, geography, or query set. It should not overwrite the underlying event and run records.
For retries, preserve the original event identity and use an idempotency key for side effects. A replay should not send a second email, create a duplicate ticket, or add another CRM activity. Enforce uniqueness in the destination database instead of relying on a lookup followed by a create.
- Can every processed event be distinguished from a replay using a stable source and tenant-aware identity?
- Does the destination enforce uniqueness or an equivalent atomic idempotency control?
- Are model runs and tool calls stored separately from aggregate performance measures?
- Is there a named owner for invalid outputs, timeouts, duplicate attempts, and approval requests?
- Are correction, exception, duplicate, latency, and cost measures defined against a baseline?
Assign an operational owner and a review date for model IDs, pricing, permissions, and workflow behavior. Expand only when the source identity, outcome definition, exception route, duplicate-prevention behavior, and decision to commit a result are clear.