Meta released Muse Ember on November 9, 2026, making its smallest Muse model available through the Meta Model API and every Muse Code subscription plan. Its intended jobs are the repetitive steps inside agent workflows: calling tools, classifying requests, extracting records, parsing documents and handling bounded coding tasks. Meta describes it as its smallest and most efficient model, a vendor claim that needs to be read alongside its pricing conditions and published evaluations. (Announcement)
The API model name is muse-ember-1.0. Standard pricing starts at $0.10 per million input tokens and $0.50 per million output tokens, but only for requests containing up to 200K input tokens. Larger prompts move both rates to a higher tier. (Developer announcement)
The practical opportunity is a division of labor: let a larger model plan the work, then assign many smaller, well-defined jobs to Ember. The important question for developers is whether those jobs stay bounded enough to preserve the savings.
Where Ember Fits Beside Muse Spark and Wonder
Meta positions Ember as the Muse family’s execution model. Its documentation recommends Muse Spark or Muse Wonder for the main planning and reasoning loop, with Ember handling repeated subtasks. For hard single-shot coding problems, knowledge-heavy questions and visual coding, the documentation directs developers toward the larger models. (Model documentation)
Meta’s suggested coding workflow separates responsibilities:
- Muse Spark or Muse Wonder: plan a repository change, identify dependencies and define acceptance criteria.
- Muse Ember: complete a bounded task using the relevant files, constraints and tests.
- Muse Spark or Muse Wonder, alongside developer review: examine the combined changes and resolve remaining issues.
That arrangement requires an explicit handoff. Meta recommends specifying the task, relevant context, files the worker may change, acceptance checks and expected result. The application or agent harness selects the model for each call and carries context between steps. Ember workers should return unclear requirements or broader dependencies to the planner. (Workflow guidance)
I’d treat that handoff as the most consequential part of the design. A cheap worker receiving an ambiguous assignment can still generate expensive retries or conflicting changes. Clear boundaries give the planner something concrete to check and make it easier to decide when a task needs a larger model.
The opened documentation provides role guidance, but no direct Ember-versus-Spark-or-Wonder benchmark table or larger-model pricing comparison. It supports this architectural distinction, not a quantified claim about savings against those models.
API Details, Context and Multimodal Scope
Meta’s documentation lists the following specifications:
| Item | Muse Ember |
|---|---|
| Model ID | muse-ember-1.0 |
| Inputs | Text, image, audio, video and PDF |
| Output | Text |
| Context window | 1,048,576 tokens |
| Maximum output | 524,288 tokens |
| Reasoning effort | minimal through max; default is max |
| API endpoints | Responses, Chat Completions and Messages |
| API availability | Standard mode only; no Contributor-mode variant |
These are the exact limits behind Meta’s rounded “1M context” and “512K output” descriptions. Multimodal support means Ember can interpret those input formats; the documented output modality is text, not generated images, audio or video. (Specifications)
Meta suggests tasks such as interpreting a screenshot alongside a bug report, extracting fields from scanned documents, summarizing meeting recordings and describing actions in video. For invoice extraction, its developer guide recommends returning each field’s value, source-page label and availability status, using null when a value is unavailable. (Multimodal guidance)
That structured approach is useful because a missing value and an unreadable value require different follow-up actions. I’d preserve those distinctions in the application schema instead of accepting a polished summary that hides uncertainty.
The 200K Pricing Threshold Matters More Than the 1M Headline
Meta publishes two input-length pricing tiers:
| Input length per request | Input price per million tokens | Output price per million tokens |
|---|---|---|
| Up to 200K tokens | $0.10 | $0.50 |
| Above 200K tokens | $0.30 | $1.50 |
The higher tier triples both rates. Meta also says requests above 200K input tokens consume Muse Code subscription usage faster. (Pricing, subscription conditions)
A calculation shows why this threshold deserves attention. Using the published standard input and output rates:
- 200,000 input tokens plus 10,000 output tokens: $0.020 input + $0.005 output = $0.025.
- 201,000 input tokens plus 10,000 output tokens: $0.0603 input + $0.015 output = $0.0753.
Those are illustrative model-token calculations, not measured application costs. They show that a slightly longer prompt can roughly triple the bill because the request crosses the pricing boundary.
The one-million-token context window therefore provides capacity, not an assurance of the lowest rate. Sending only the files or document sections a worker needs can keep a request in the cheaper tier while reducing irrelevant context. Splitting work also has overhead, so developers should compare complete workflow costs, including repeated instructions, retries and planner calls.
Making a Call Does Not Run the Tools
For developers with a Meta Model API key, the documented Responses endpoint accepts the Ember model ID:
curl -X POST "https://api.meta.ai/v1/responses" \
-H "Authorization: Bearer $MODEL_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "muse-ember-1.0",
"input": "Classify as billing, bug, or feature request: charged twice."
}'
This example follows Meta’s documented request format and asks for a simple classification. It assumes MODEL_API_KEY is set in the shell environment; it has not been executed here. Meta says Ember accepts the same request body as Muse Spark, making the model field the main change for many existing examples. ()
Frequently Asked Questions
3 questions
1Can Muse Ember generate images or audio?
Its documented output is text. It accepts text, images, audio, video and PDFs as inputs.
