Meta Muse Ember: When a Low-Cost Executor Model Belongs in Your Agent Stack

Meta Muse Ember is a small, cheap model built for the high-volume calls inside multi-step AI agents. This matters because agents make two very different kinds of call. Some make decisions, like how to split a goal into steps or whether the job is finished. Others are mechanical, like calling a tool with a fixed schema or pulling fields out of a document. Running all of it on a frontier model is the easy option, and that's where costs climb fastest.

This is a routing guide, not launch coverage. Every figure names its source. Prices, benchmark results and platform status for a new model can change quickly, so check current terms before you commit.

What Is Meta Muse Ember?

Ember is the fourth model under Meta's Muse brand. It follows the mid-weight Spark, Spark's open source twin Glimmer, and the Wonder frontier model. Meta positions Ember for repeatable coding and agentic tasks at scale, not as its strongest reasoner. The specs are still generous for a small model: Meta lists a 1M-token context window and up to 512K output tokens.

The most useful independent framing comes from Artificial Analysis, which places Ember 8 points behind Muse Wonder on its Intelligence Index for about 1/50th of the cost per task. For scale, Artificial Analysis reports Muse Wonder (max) scoring 44 at $6.95 per Intelligence Index task. That is the profile of an executor. Ember takes the well-defined, high-volume calls, and a larger model keeps the decisions that need deeper reasoning.

Muse Ember Pricing: Tokens, Caching and Cost per Task

List prices and the 200K long-context tier

Meta's standard list prices for Ember are $0.10 per million input tokens, $0.004 per million cached input tokens and $0.50 per million output tokens. Long prompts cost more. For Ember prompts exceeding 200,000 input tokens, rates rise to $0.30 per million input tokens and $1.50 per million output tokens. Claude Haiku 5.5 switches to its higher rates above 100,000 tokens, so Ember's standard tier stretches further.

The $0.10 figure you'll see quoted everywhere is the input rate only. Output costs more, so an executor that writes long responses will cost more than the headline suggests.

Why prompt caching changes the economics

Meta lists cached input at $0.004 per million tokens, against $0.10 per million for standard input. In many agent designs, calls repeat the same system prompt and tool definitions, so teams may find that a meaningful share of their input could qualify for the cached rate. We suggest keeping variable content, such as timestamps or request IDs, after the stable part of the prompt, and confirming in your platform's documentation exactly how caching is applied before you build a cost model around it.

Cost per task matters more than price per token

On Meta's chart, Ember at max scores 35.8 for $0.136 per task, while Haiku 5.5 at max scores 36.2 for $0.411. Artificial Analysis independently reports that Muse Ember (max) is the cheapest model scoring 36 or higher, at $0.14 per task, while Claude Haiku 5.5 (max) costs almost 3x more at $0.41 for a comparable score. The small gap between the two sources is most likely rounding. Both models land around 36, so read it as comparable capability, not an exact tie. Digital Trends also reports that Ember finishes an Artificial Analysis task for roughly $0.14.

According to MarkTechPost, Ember and Haiku 5.5 have identical list token prices, so the per-task gap comes from Ember using fewer tokens to finish the work. That parity holds on the standard tier only. Because Haiku's higher rate starts at 100K input tokens and Ember's at 200K, prompts between those sizes are priced differently.

This is the point buyers should hold onto. Price per token is just the rate. The number of tokens each completed task uses is what sets the bill. A model that reasons at length or writes verbose output can cost more per task than a rival charging the same rate. Benchmark tasks are not your tasks, so measure tokens per completed task on your own workload before relying on any of these ratios.

How to Read the Muse Ember Benchmarks

The published evidence comes from four kinds of source: Meta itself, launch partners quoted by Meta, Artificial Analysis as an independent benchmarker, and a few small third-party tests. They don't always agree, so check the protocol behind each number before you compare it with anything. Our guide on why benchmark scores need protocols and evaluation cards explains what to look for.

Independent results

Artificial Analysis finds that Ember beats Claude Haiku 5.5 (max) on Terminal-Bench 4.0, at 40.9% versus 32.8%, but trails it on FrontierCode 2.0, at 27.2% versus 34.9%. So 'good at coding' is too broad a label. Which kind of coding task you give it matters. Vendor charts and independent benchmarkers can report different scores for the same model on the same benchmark, so we suggest noting which source each number comes from before you compare them.

Knowledge is the clearest weakness. Ember's AA-Omniscience accuracy of 21.1% is the lowest of the similarly intelligent models Artificial Analysis compared, mostly because it declines to answer 64% of questions. In a lot of business workflows, a model that declines is safer than one that guesses. Still, don't treat Ember as a source of facts. Supply the facts through retrieval or tool results, and let Ember work with them.

Vendor-reported figures

On AutomationBench-AA, a set of 657 Zapier business workflows, Meta-reported figures show Ember completing 37.8% of tasks, compared with 20.2% for GPT-6 Luna and 13.9% for Claude Haiku 5.5. The 'AA' in the name may make you think of Artificial Analysis. However, the sources we reviewed present these as results from Meta's launch materials and don't show Artificial Analysis running them. The benchmark is close to what many operations teams actually run, which makes it relevant. Treat it as a vendor figure until your own tests confirm it.

Partner reports and small third-party tests

Meta's blog quotes You.com, an early-testing partner, reporting a p95 latency of 2.2 seconds and 36 to 48% fewer output tokens. Cloudflare's CTO reported tail latency up to 30% faster than an unnamed comparable model. Activepieces ran a small independent test in which Ember completed all three tasks correctly in 8.4 seconds total, while GPT-5.4-mini completed the same tasks in 2.8 seconds total.

Three tasks is a tiny sample, and the partner quotes come from Meta's own launch post. Neither side settles the question. Together they suggest that latency depends heavily on the workload and on how the model is configured and deployed.

Planner and Executor Routing in Meta's Demos

Meta published two demos of the planner and executor pattern. In a Python-to-Rust migration demo, Muse Wonder planned the work and Ember workers ported 16 lexers, all of which matched Python on every one of 383 test inputs and on 62 of 62 real files supplied only after the code was frozen. The Rust versions ran 3.0 to 7.3 times faster than the Python originals on about 1 MB of input.

The full run cost about $3.96 at pay-as-you-go prices, of which $2.12 was Muse Wonder and $1.84 was Muse Ember. Look at that split. The planner accounted for more than half the cost even though Ember workers ported all 16 lexers. The lesson still holds: frontier planning tokens are expensive, so keep the planner's job tightly scoped.

Google Cloud's documentation also recommends pairing Ember with Muse Wonder or Muse Spark 1.3 for multi-step planning and reasoning. We suggest treating these demos as illustrations of the architecture rather than as independent evidence. They don't predict your results, which will depend on your task mix, your validation rules and how often calls fail.

Availability: Meta's API Versus the Google Cloud Preview

Meta's published materials list the pricing along with the 1M context and 512K output limits. On Google Cloud, Ember is offered as a Preview partner model that accepts text and image inputs with a 1M-token context window. Meta advertises broader multimodality, including audio and video, which the Google Cloud Preview listing does not currently match.

So check modality support on the platform you'll actually deploy on, not in the launch announcement. We suggest reading the Preview terms, including any service levels and quotas, before you send production traffic. Ember is Meta's model and Google Cloud only hosts it, so features, limits and update timing may differ between the two.

The Plan-Execute-Escalate Routing Matrix for Muse Ember

We call this approach the Plan-Execute-Escalate routing matrix. Planning stays on a larger model. Well-defined calls execute on Ember. Anything that fails validation escalates back to the planner.

Step 1: Inventory and tag every model call

List every model call your agent makes and assign each one a lane. In many agent designs the mechanical calls probably outnumber the planning calls. Check that against your own logs before you assume it, because the ratio drives the savings.

Once calls are tagged, enforcing per-call-type routes at a gateway stops the matrix from drifting as your code changes and gives you one place to set budgets.

Step 2: Start with extraction, tool calls and routing

Their outputs are well defined and easy to check, so they're the obvious first candidates. Planning and decomposition stay in the Plan lane, as in Meta's demos. Keep knowledge-heavy calls off Ember unless retrieval puts the facts in the prompt.

Step 3: Build an eval set from real traffic

Sample real requests for each call type you plan to move. Compare cost per completed task, accuracy and failure modes against your current model. Per-token price alone will mislead you.

Step 4: Design for caching and the 200K threshold

Put the system prompt and tool definitions first as a stable prefix, with variable content after them. Keep routine executor calls well under 200K input tokens so they stay on the standard rate.

Step 5: Add an escalation path

If Ember declines, fails validation or returns output that breaks the schema, retry once and then hand the call to the planner. Log every escalation. If the escalation rate keeps rising for a call type, that call type probably doesn't belong on the small model. Our durable AI agents runtime selection checklist covers what to look for.

Step 6: Track latency and output tokens in production

The published latency evidence points in different directions, so track p95 latency and output tokens for each call type from day one. Our OpenTelemetry GenAI tracing playbook shows one way to capture those signals per call.

Pre-production checklist

• [ ] Every model call has a lane in the matrix
• [ ] Each call type moved to Ember has an eval set built from real traffic
• [ ] Cost per completed task is measured, not estimated from list prices
• [ ] System prompt and tool schemas form a stable, cacheable prefix, and routine calls stay under 200K input tokens
• [ ] Knowledge-dependent calls get their facts from retrieval or tools
• [ ] Schema validation and a logged retry-then-escalate fallback are in place
• [ ] Modality support and Preview terms are confirmed on your deployment platform

If a second pair of hands would help, Optijara can work with your team to tag agent calls and design a pilot eval set.

Caveats and Open Questions

Most of the strongest numbers come from Meta or its launch partners. Artificial Analysis has independently reported some of them, mainly cost per task and some benchmark scores, but not all.

Meta says Ember stayed below the high-risk thresholds of its Superintelligence Scaling Framework in pre-release safety evaluations, but this is the company's own assessment. You still need your own review of how your workflow handles data, validates outputs and guards against misuse.

Latency is still an open question. Partners report fast tail latency, while one small independent test found Ember about three times slower than GPT-5.4-mini.

Ember is also very new, so recheck pricing, availability and Preview status before you commit. In the end, the only reliable basis for a routing decision is how the model performs on your own workload.