Meta announced Muse Ember on November 9, 2026, positioning its smallest Muse model as an executor for the work agents repeat: tool calls, coding subtasks, routing, extraction and document processing. The model is available through Meta Model API and Muse Code under the model ID muse-ember-1.0. (Announcement, documentation)
The headline API price is $0.10 per million input tokens and $0.50 per million output tokens. Requests exceeding 200,000 input tokens move to a higher tier, where both rates triple. That distinction matters for a model Meta is also promoting for large document sets and codebases.
Muse Ember’s useful proposition is the division of labor it enables. A larger model can plan a job, while Ember handles many bounded steps. The documentation gives developers enough information to examine that arrangement through request costs, supported inputs and workflow limits, without relying entirely on launch benchmarks.
Where Muse Ember Fits in an Agent System
Meta’s documentation recommends pairing Ember with Muse Spark or Muse Wonder: the larger model handles planning and reasoning, while Ember takes on repeated execution. The company specifically recommends Spark or Wonder for hard single-shot coding problems, knowledge-heavy questions and visual coding. (Meta’s workload guidance)
That gives Ember a fairly clear role:
- Coding subtasks: focused changes, terminal commands and lookups delegated by a main agent.
- Tool calls: selecting and invoking tools within a larger workflow.
- Routing: classifying a request and passing it to an appropriate handler or model.
- Collection processing: applying the same operation to many images, files or records, such as extracting fields, sorting photos or classifying support tickets.
A practical architecture could use a larger model to decide which parts of a repository need investigation, then give Ember narrowly scoped searches or edits. A document workflow could use Ember to extract consistent fields from individual files, with a larger model resolving ambiguous cases. These are workflow implications of Meta’s documented positioning, not systems tested for this article.
I’d start with tasks that have explicit completion criteria: a classification from a fixed list, fields matching a schema, or a code change checked by tests. Small errors can multiply across thousands of requests, so cheap execution is most useful when the surrounding system can detect failures.
Meta lists support for tool calling, structured output, computer use, image understanding and search grounding. Those capabilities provide integration options; developers still need to define tool permissions, validation and escalation rules. (Feature documentation)
API Pricing: The 200,000-Token Threshold Matters
Meta publishes two pricing tiers for muse-ember-1.0. All figures below are US dollars per million tokens. The documentation says requests with more than 200,000 input tokens receive long-context pricing. (Pricing table, threshold explanation)
| Token category | Standard request pricing | Over 200,000 input tokens |
|---|---|---|
| Input | $0.10 | $0.30 |
| Cached input | $0.004 | $0.012 |
| Output | $0.50 | $1.50 |
The threshold changes output pricing too. Treating a long request as ordinary input with a small surcharge for excess tokens would understate the published cost.
For an illustration, assume uncached input and 10,000 output tokens:
- A request with 190,000 input tokens costs $0.019 for input plus $0.005 for output, totaling $0.024.
- A request with 210,000 input tokens costs $0.063 for input plus $0.015 for output, totaling $0.078.
Those are calculations from Meta’s listed request-tier rates. In this example, adding roughly 10.5% more input raises the token bill by 3.25 times, because the request crosses into a more expensive tier. The calculation excludes separate tool or service charges.
Repeated small requests have a different profile. One million tasks, each consuming 2,000 uncached input tokens and generating 200 output tokens, would total two billion input tokens and 200 million output tokens. At standard rates, that comes to $300 in model token charges.
That is a useful budgeting baseline, but retries, longer responses and routing calls change the total. Cached-input rates offer further savings only for tokens actually billed as cached.
My view is that developers should model the distribution of request sizes, not simply multiply total monthly tokens by the headline rate. A workload with occasional huge histories can have materially different economics from one that keeps each subtask’s context small.
What the Million-Token Window Actually Offers
Muse Ember’s documentation lists a 1,048,576-token context window and a 524,288-token maximum output. It accepts text, images, video, audio and PDFs, but produces text output. Multimodal input support therefore allows media analysis; it does not imply audio or video generation. (Model specifications)
The large context window gives developers room to supply extensive source material without first breaking everything into small passages. Meta says Ember can take a full codebase or document set in one call, although what fits will depend on the size and token representation of the material. (Launch post)
The architectural choice is whether a task needs all that context together.
Independent invoice extraction, for example, may fit naturally into separate requests. Comparing clauses across a contract collection may benefit from shared context. Splitting the latter into isolated chunks could remove relationships the model needs to see.
I’d treat the long window as capacity to use when the task warrants it, not a default payload size. Smaller task-specific inputs can avoid the higher pricing tier and keep unrelated material out of a subagent’s instructions. The tradeoff is that some jobs genuinely require cross-document context.
The output ceiling is similarly a capacity limit, not a recommended response length. Routing and extraction steps generally benefit from compact outputs that downstream software can validate.
Availability, Reasoning Settings and a First Request
Muse Ember is available on Meta Model API in Standard mode only, with no Contributor-mode variant. It is also available through Muse Code on pay-as-you-go and every subscription plan. On a Muse Code subscription, requests exceeding 200,000 input tokens consume the plan’s usage faster. (Availability documentation)
The API supports Responses, Chat Completions and Messages endpoints. Reasoning effort ranges from minimal to max, with max as the default. Standard mode and reasoning effort are separate settings: Standard describes the available API mode, while reasoning effort controls the model’s reasoning setting.
That default deserves attention in a high-volume deployment. I’d compare supported reasoning settings on representative routing or extraction tasks before assuming the maximum setting is appropriate for every call.
Frequently Asked Questions
3 questions
1How Much Does Muse Ember Cost?
Standard API pricing is $0.10 per million input tokens and $0.50 per million output tokens. Requests above 200,000 input tokens cost $0.30 and $1.50 respectively. Cached input has separate, lower rates.
