Meta releases Muse Ember for low-cost AI agent execution

Introduction to Muse Ember: what the Muse Ember release offers

The Muse Ember release on November 9, 2026, positions Meta’s smallest Muse model as an execution engine for AI agents: software that calls tools, processes documents and carries out sequences of tasks. The central proposition is a division of labor. A larger model can handle difficult planning, while Ember performs the repeated steps at a lower token price.

According to Meta’s announcement, Ember is available through Muse Code and the Meta Model API under the identifier muse-ember-1.0. Pricing is $0.10 per million input tokens, $0.004 per million cached input tokens and $0.50 per million output tokens. Meta lists a 1M-token context window, up to 512K output tokens and support for the Responses API.

The release targets tool calls, coding subtasks, routing, extraction and long-document parsing. Meta also describes native support for text, images, audio and video. Those capabilities give the cost argument a practical focus: Ember is intended to perform work across different inputs, rather than serve only as a cheaper text generator.

TechCrunch’s release coverage places Ember alongside Meta’s larger Muse Wonder model in an agentic harness—the surrounding software that coordinates model calls and execution. But the evidence supports a qualified assessment of the launch. Meta publishes promising prices and evaluation results; its broader claim of superior intelligence per dollar needs to be read alongside the actual chart values and testing conditions.

Cost-effectiveness compared to competitors

Meta’s headline comparison is with Claude Haiku 5.5 and GPT-6 Luna. It says Ember offers more intelligence per dollar at any reasoning setting and matches Haiku’s best score at about a third of the cost. The announcement draws on Artificial Analysis results, plotting its Intelligence Index against cost per task.

The numerical series provides a more precise picture:

Each point represents a reasoning-effort setting. The supplied chart text does not clearly map every value to a named setting, so assigning those settings individually would go beyond the evidence. These are figures reproduced in Meta’s announcement, which attributes the underlying results to Artificial Analysis on November 9, 2026; they are not a separate evaluation conducted for this article.

The chart supports a strong efficiency argument within the displayed results. Ember’s higher-scoring point costs less than Haiku’s two higher-scoring points, and both Ember points exceed every listed Luna score. It does not show Ember as the cheapest option in absolute terms: Haiku and Luna each have lower-cost points with lower scores. The relevant question is how much capability a particular task requires at a given expense.

There is also a material discrepancy between Meta’s wording and its chart. Ember’s highest listed score is 35.8, while Haiku reaches 36.2. That shows a close result at roughly a third of Haiku’s displayed cost, rather than an exact match to its best score. A separate evaluation summary rounds the general Artificial Analysis Index to 36 for both Ember and Haiku, which conveys less precision than the cost chart. Neither presentation justifies silently treating 35.8 and 36.2 as identical.

The cost labels themselves need qualification. One caption describes Ember’s costs as estimates at proposed pricing; another describes them as costs at list pricing. The announcement does not explain that difference. The published token prices are explicit, but the per-task figures should be understood as the announcement’s benchmark-based estimates, rather than a guaranteed bill for a developer’s workflow.

Meta also compares Ember with Muse Spark 1.3. Its table lists Intelligence Index scores of 36 for Ember and 37 for Spark, alongside costs per Intelligence Index task of $0.14 and $2.39, respectively. Spark’s listed token rates are $1.25 per million input tokens and $4.25 per million output tokens. This comparison illustrates Meta’s portfolio strategy: a small difference on that composite index accompanies a substantial difference in the reported task cost.

For developers, the evidence makes Ember a candidate for evaluating repeatable work at scale. It does not establish a universal production saving. The published task costs concern a particular evaluation, while an application’s relevant outcome is successful completion of its own work. Meta’s efficiency claim is useful evidence for that decision, but it cannot substitute for the decision itself.

Integration with larger models

Ember’s intended relationship with Muse Wonder is central to the release. Meta recommends pairing the models for the hardest problems, assigning planning to Wonder and volume execution to Ember. TechCrunch illustrates the idea with customer support: a heavier model establishes rules for handling an issue, and a lighter model applies those rules across tens of thousands of cases.

That is an illustrative deployment pattern, not a reported customer implementation. It nevertheless explains why a smaller model can matter even when a more capable model is available. The proposal is to reserve the larger model for work that needs its judgment, then use Ember for repeated application of the resulting instructions.

Meta describes coding in similar terms. Ember is designed for the subtasks an agent repeatedly delegates, including reading files, running tests and making targeted fixes. A testimonial from Cline founder Saoud Rizwan, included in Meta’s announcement, specifically highlights its role as a subagent for coding and document analysis. That is a partner endorsement, rather than independent evidence that every such deployment will save money.

The distinction between planning and execution also sets a boundary on what has been announced. The available material does not document a complete routing policy, a working integration example or measured results for a combined Wonder-and-Ember system. It establishes the intended division of work and Ember’s API availability. It does not quantify the total cost or reliability of that combined architecture.

Meta says Ember is the first model trained using Muse Wonder Full. That identifies a development relationship within the Muse family, but the announcement does not explain the training procedure in enough detail to establish how that process produced the reported capabilities. The practical evidence remains the released model’s features, prices and evaluations.

Capabilities in managing workflows

Meta says Ember can carry a business workflow from beginning to end by retrieving records, calling tools in sequence and updating systems across applications. Its most direct published evidence for that claim is AutomationBench-AA, described as an evaluation of end-to-end business workflows.

The announcement reports the following results at maximum reasoning:

These results measure different things. AutomationBench-AA uses strict pass@1 scoring, according to the announcement. Agents’ Last Exam is a Meta internal evaluation covering a Linux subset. Terminal-Bench 4.0 uses each model’s best published harness, so the comparison includes differences in the software surrounding the models. FrontierCode 2.0-AA evaluates real engineering tasks judged on mergeability, while GDP.pdf-AA concerns professional work over long documents. Their scores should not be combined into a single success rate.

Ember’s AutomationBench-AA lead is substantial within this comparison, but its 37.8% result also makes the limitation visible: the result is well below complete success under that benchmark’s strict measure. Meta’s description of end-to-end workflow capability therefore should not be read as a promise that arbitrary business processes will run reliably without intervention.

The coding evidence is mixed in a useful way. Ember leads the displayed Terminal-Bench 4.0 results, and Meta’s Coding Agent Index-AA table gives it 46 against Haiku’s 37 and Luna’s 31. Yet Haiku leads FrontierCode 2.0-AA with 34.9%, compared with Ember’s 27.2%. That difference matters for the proposed division of labor. Strong performance on delegated coding work does not establish leadership on engineering tasks assessed for mergeability.

Ember’s long-context and multimodal features broaden the workflows Meta is targeting. The company says agents can use screenshots, charts and scanned documents, as well as voice memos, meeting recordings and video, without a separate model. Its 1M-token context window is presented as sufficient to take in a full codebase or document set in one call. That claim depends on the size of the material; the context limit is a capacity specification, not evidence that every codebase fits or that every detail will be used correctly.

The document benchmark offers a similarly bounded result. Ember’s GDP.pdf-AA score of 22.8% ties Luna and exceeds Haiku’s 20.8%. It supports competitiveness on that evaluation, rather than an across-the-board lead in document work.

Computer-use scores require particular care. Meta’s summary lists OSWorld 2.1 partial-credit results of 69.5% for Ember, 68.9% for Haiku and 50.5% for Luna. It separately lists binary results of 33.8%, 27.8% and 17.0%. The chart emphasizes the partial-credit figures and labels the evaluation as internal. Presenting 69.5% simply as a completed-task rate would erase the distinction between partial progress and the binary measure.

Partner reports add concrete task descriptions, although they remain testimonials selected for Meta’s announcement. Box describes contract assessment against a negotiation playbook and candidate screening against a detailed brief. Cloudflare reports up to 30% faster tail performance against an unnamed comparable model. You.com reports a p95 latency of 2.2 seconds on its coding quests, alongside fewer output tokens than the leading open-weight models it tested. The supplied material does not provide enough detail about those comparison sets and test conditions to generalize the reported gains to other workloads.

Finally, Meta says it evaluated Ember under its Meta Superintelligence Scaling Framework and found it below high-risk thresholds in the categories assessed. It also describes testing user intent, sensitive-information handling, resistance to instructions hidden in external content, and requests for human input before high-impact actions. Those are relevant areas for a model that updates systems across applications. The announcement does not supply numerical results for those behavioral tests, so it establishes the scope of Meta’s reported testing rather than a measured guarantee of safe operation.

Conclusion on the impact of Muse Ember

Muse Ember’s clearest contribution is a concrete option for cheaper agent execution: published token prices, a large context window, multimodal inputs and benchmark results that make repeated workflow and coding tasks its strongest stated use case. Its intended partnership with Muse Wonder gives those features an architectural purpose, with expensive planning separated from high-volume execution.

The evidence supports taking that proposition seriously while preserving its boundaries. Ember leads several published comparisons, trails Haiku on FrontierCode 2.0-AA and ties Luna on GDP.pdf-AA. Meta’s strongest cost-efficiency language also runs ahead of the exact chart values, and the announcement uses inconsistent labels for estimated task costs.

The consequential question for an agent deployment is whether Ember can complete its assigned steps at the required quality for less total expense. Meta has supplied prices and evaluation results that make that question worth testing. The release does not yet establish the answer for a combined-model system or for every business workflow.