Meta released Muse Ember on November 9, 2026, targeting the repeated execution work inside AI agents. Its launch matters most to teams whose costs accumulate across thousands of small tasks, not just those chasing the strongest answer to a single difficult prompt.
This November 12 guide separates verified access and billing details from our recommendations for evaluating the model. We have not run an independent Ember benchmark and do not claim measured savings for Nerova or its customers.
What is Muse Ember, and how do you access it?
Meta's release announcement positions Ember as its smallest, most efficient Muse model for agent execution. The developer documentation identifies muse-ember-1.0, available through the Meta Model API and Muse Code. It accepts text, images, audio, video and PDFs and produces text, with a 1,048,576-token context window. API access is not a downloadable-weights release.
Meta describes an execution role alongside larger Muse models. Our practical interpretation is to test Ember on a bounded piece of a workflow before replacing the system that plans, validates and approves the whole job. “Small” describes its product position, not a guarantee that it is appropriate for every low-risk or high-volume task.
Muse Ember pricing: watch the 200K input boundary
The official price table lists these US-dollar rates per million tokens in Standard mode:
| Request input | Input | Cached input | Output |
|---|---|---|---|
| Up to 200K tokens | $0.10 | $0.004 | $0.50 |
| Over 200K tokens | $0.30 | $0.012 | $1.50 |
The higher tier applies to the entire request, not only the excess. Cached input and stored conversation history count toward the boundary. Ember has no Contributor-mode API variant; Standard-mode content is not used for training. Muse Code subscriptions have separate settings and default to Contributor mode, so do not assume an API privacy choice automatically applies there.
Worked cost examples: cheap tokens are not the entire bill
Consider 10,000 hypothetical tasks, each consuming 5,000 uncached input tokens and 1,000 total billed output tokens. At the lower tier, the input would cost $5 and output $5, for $10 in model token charges. That arithmetic assumes exactly one successful call per task and excludes tools, infrastructure and human review.
Now imagine the same workflow needs an average of three attempts before passing validation. The model component becomes $30 under otherwise identical assumptions. If a more expensive model succeeds in one attempt, compare final cost and quality rather than declaring the lowest rate the winner.
The long-context boundary deserves its own test. One hypothetical request with 200,000 uncached input tokens and 1,000 billed output tokens costs $0.0205. At 200,001 input tokens, the stated higher tier gives approximately $0.0615003. This is a pricing illustration, not a measured workload. A single extra token can move the request into a different tier; a one-million-token context window does not make all context equally economical.
Do not remove necessary evidence merely to stay below a billing threshold. Instead, test whether retrieval, focused task context or an approved summary preserves the information required to complete the job. Measure the change in correctness alongside its savings.
Reasoning is billed even when the final answer is short
Meta's reasoning documentation says Ember defaults to max effort. Internal reasoning tokens count toward billed output and the output budget; they are not visible answer text. Supported effort begins at minimal, while none is unsupported.
That means a short classification result is not sufficient evidence of a small output bill. Log returned usage and compare settings on the same tasks. Our recommendation is not to force minimum effort everywhere: select the least expensive setting that still meets the quality target, and route genuinely difficult cases elsewhere when necessary.
For coding subtasks, success should include tests and review, not just whether the assistant produced a patch. For document extraction, validate required fields against the source, including examples where the answer is absent. For a tool-using workflow, record whether it completed the requested action once, with the correct arguments and without unauthorized side effects.
A useful first trial: one repeated task, one acceptance test
- Choose a narrow unit of work. For example, extracting invoice dates from authorized documents rather than “handle finance.”
- Define correctness before sampling. Agree how missing dates, multiple dates and unclear scans should be handled. An explicit “needs review” result can be better than a guess.
- Run a holdout evaluation. Keep representative cases separate from prompt development. Include failures from the current system, not only easy demonstrations.
- Track end-to-end economics. Count retries, escalations, tool calls, processing time and reviewer effort in addition to input and output tokens.
- Roll out reversibly. Keep the previous path available and define when an error spike should pause the trial.
A spreadsheet with task ID, expected result, accepted result, total cost, latency and review outcome is more useful than a collection of impressive screenshots. Avoid copying sensitive source material into analytics when a reference and a redacted error label will do.
What benchmark claims can tell you
The launch announcement argues that Ember offers strong intelligence per dollar. Treat that as a reason to investigate, not a universal replacement rule. A benchmark's tasks, tooling and scoring can differ from your workload, and a vendor's favorable comparison does not demonstrate your own operational savings.
Compare against the model you actually use with the same permitted tools and acceptance criteria. If Ember reduces spending while preserving accepted outcomes, expand that task gradually. If it generates more repair work, retain the existing route even when Ember's per-token price looks attractive.
For businesses, the release is a new option for dividing agent work intelligently. The useful question is not whether Ember is cheaper in isolation, but whether it lowers the cost of a reliable completed job. See our coverage of Meta's specialized Muse models for the wider product context.