Muse Ember: what a 1M context and $0.14 per task change about routing

Meta's first sentence about Muse Ember is “our smallest and most efficient model.” The more useful sentence comes next: it is designed for “the work agents repeat all day: tool calls, coding subtasks, routing, extraction, and long document parsing.” Muse Ember is not a model that solves the hardest problem alone. It is one slot in a portfolio: handle repeated small steps cheaply, then escalate the difficult ones.

The official announcement is dated 9 November 2026. It introduced a 1M-token context, up to 512K output, the muse-ember-1.0 model ID, availability on Muse Code and the Meta Model API, and support on Google Cloud and Oracle Cloud. This article reads the published pricing and evaluation tables. We did not call the model or reproduce the benchmarks.

A price structure built for volume

For prompts up to 200K tokens, Muse Ember costs $0.10 per million input tokens, $0.004 per million cached input tokens and $0.50 per million output tokens. Above 200K, pricing rises to $0.30/M input, $0.012/M cached input and $1.50/M output. Supporting a 1M context is not the same as making a 1M context cheap. If you plan to route whole document sets through one call, calculate the cliff first.

Meta puts cost per Artificial Analysis task at about $0.14. Muse Spark 1.3 is listed at $2.39 on the same comparison. That is a 17× difference. Instead of sending every step to the strongest model, route repeated steps to Ember and escalate planning, ambiguous debugging and merge judgment.

How to read the evaluation table

Meta's table compares each model at its best setting. The key numbers:

Muse Ember leads on AutomationBench-AA, Agents' Last Exam, Coding Agent Index-AA and PerceptionBench. It trails Haiku 5.5 on FrontierCode 2.0-AA, 27.2 vs 34.9. FrontierCode judges real engineering tasks on mergeability. Being good at coding subtasks is a different claim from being the best judge of whether a change should merge.

OSWorld 2.1 needs the same care. The headline 69.5 is a partial-credit score; the binary score is 33.8. Haiku is 68.9/27.8 and Luna is 50.5/17.0. Mixing partial and binary numbers to say the models are “almost equal” changes what the number means.

Designing the routing policy

A practical starting point is to split work by failure cost and repetition count. Tool-call formatting, search-result classification, field extraction, file reads and test-failure summaries are cheap to retry and frequent. Ember fits. Architecture decisions, hypotheses for an unknown bug, security-sensitive review and final merge judgment are expensive to get wrong. Escalate those to Wonder or Spark and treat Ember's output as candidate generation.

task → classify
  ├─ repeated, low failure cost → Ember
  │    tool format · extraction · routing · file reads
  ├─ plan or ambiguous debugging → Wonder
  └─ coding / agentic workflow → Spark
       └─ final merge judgment → human + stronger model

This diagram is our proposal, not Meta's official architecture. Meta says Muse Wonder plans while Muse Ember handles the volume, but the concrete rules depend on the product. The important part is neither “one small model for everything” nor “one largest model for everything.”

Measure cost per successful task

A price list is only half the routing decision. Real cost is token price × token count × retries × escalation rate. If Ember succeeds eight times out of ten and escalates two, the average is ten Ember calls plus two stronger calls. If it fails five times out of ten, half the work pays twice.

The unit of a routing experiment should therefore be cost per successful task, not cost per token. Record the task definition, success criterion, retry cap, cache hit rate and escalation rule. Meta's $0.14 is an estimate under Artificial Analysis's task definition and list pricing. It is not your workflow's $0.14.

Safety and limits

Meta says it evaluated Muse Ember under its Meta Superintelligence Scaling Framework for chemical and biological, cybersecurity and loss-of-control risks, and found it below the framework's high-risk thresholds in the categories assessed. It also evaluated whether the model respects user intent, handles sensitive information appropriately, resists instructions hidden in web pages, documents or tool outputs, and seeks human input before high-impact actions. These are vendor-run evaluations, not independent verification.

The technical limits are clear. A 1M context lets you put a long document set in one call, but above 200K the price rises and latency and KV-cache cost grow. The Artificial Analysis Index of 36 is a composite. If your job is mergeability, FrontierCode 2.0-AA's 27.2 matters more. And “more intelligence per dollar” is Meta's framing; a different task definition or harness can change the cost ranking.

Insight: from model choice to routing design

The real meaning of Muse Ember is not “a small model beat a large one.” It is that the same Artificial Analysis Index of 36 is available at roughly one-third the cost, and the model is explicitly positioned for repeated work. As portfolios grow, competitiveness comes from which task goes where, when to escalate, and how failure is measured—not from a single leaderboard score.

The next time you adopt a small model, do not look for the leaderboard winner. Split your work into repeated/low-risk and planning/high-risk, then measure success and escalation cost for each. Ember is a useful baseline for that experiment, but it is not the model to trust with the final merge decision.

For another cost-reduction path, see Nota AI's 1.58-bit 30B. For the system-level infrastructure bill, see TPU 8tx and 8i Max.