Muse Ember: Meta's Smallest Model and the Economics of Agent Execution

An agent doing real work spends surprisingly little of its budget on the decisions that matter. A planner reads the request, settles on an approach, and hands off. What follows is a long tail of small, repetitive steps: read this file, call that tool, classify this ticket, pull three fields out of an invoice, run the tests, patch the one function that failed. Those steps are where most of the tokens go, and they are the reason agent bills climb faster than the value the agent produces.

Muse Ember, released by Meta Superintelligence Labs on November 9, 2026, is aimed squarely at that tail. Meta calls it the smallest and most efficient model in its Muse family and describes the target workload as the work agents repeat all day: tool calls, coding subtasks, routing, extraction, and long document parsing. The headline claim is cost: Ember matches the best score of Claude Haiku 5.5 on the Artificial Analysis Intelligence Index at roughly a third of the cost per task, while beating every setting of GPT-6 Luna.

The interesting part is not the sticker price. Ember lists at the same per-token rates as both competitors. The savings come from how many tokens it writes and how cheaply it reads cached context, which makes the model a case study in agent unit economics rather than a simple price cut.

What Meta shipped

Muse Ember runs as muse-ember-1.0 on two surfaces: the Meta Model API and Muse Code, Meta's terminal-based coding agent. The API accepts OpenAI-compatible clients, so an existing harness can point at the new endpoint without a rewrite. The spec sheet is short enough to memorize.

Two rows matter more than the rest. The million-token window means a full codebase slice or a stack of documents can go into a single call. The half-million-token output ceiling means a long structured extraction can come back in one response instead of a chain of them. Whether that is a good idea depends on which price tier the request lands in, which is the subject of the next section.

Ember sits at the bottom of a three-tier lineup. Muse Wonder handles planning and the hardest reasoning. Muse Spark 1.3 handles demanding coding and long-running agent workflows. Ember handles the volume, and Meta says it is the first model trained using Muse Wonder Full, the subscription-only variant of its largest model, which is a polite way of saying the big model taught the small one.

One point of index score separates Ember from Spark at roughly one-seventeenth the cost per task. That trade is the entire argument for a two-model stack, and it explains why the launch materials keep repeating Meta's one-line description of the intended split: Muse Wonder plans, Muse Ember handles the volume.

Same sticker price, a different bill

The three models in the comparison all list at $0.10 per million input tokens and $0.50 per million output tokens. On a straight per-token basis there is almost nothing to choose between them, which is why the marketing leans on cost per task instead. The published rates do have a second row that the launch post omits.

All figures in USD per million tokens.

Two mechanisms produce the gap between $0.14 and $0.41 per task. The first is caching. Ember's cached input rate is $0.004 per million tokens, about 60 percent below what Haiku 5.5 and Luna charge for the same thing. Agent harnesses resend the same system prompt, tool schemas, and reference documents on every turn, so cached input is often the majority of the bill in a long tool loop. The second is output volume. Running the full Artificial Analysis Intelligence Index at max reasoning, Ember generated roughly 115 million output tokens against Haiku 5.5's 298 million. At the same output price, less than half the output produces a cost per task near $0.14 versus $0.41.

Both figures deserve a caveat. Artificial Analysis describes Ember as somewhat verbose relative to the median model in its price class, so the advantage is against Haiku specifically and not a claim of unusual terseness. Meta's own cost chart is also built from estimates at proposed pricing, which makes the per-task numbers vendor arithmetic until someone reproduces them on a real workload.

The tier boundary deserves attention. Above 200,000 input tokens the rates triple, and the higher tier applies to the entire request, including cached tokens and carried conversation history, not just the portion past the threshold. A one-million-token document parse therefore bills at $0.30 per million input tokens rather than $0.10. That is still inexpensive for reading an entire codebase in one call, but it is three times the number people tend to quote. Ember stays cheaper than Haiku 5.5 on long prompts even after its own step up, because Haiku's long-context tier is higher still.

Benchmarks and the fine print

Meta published ten comparison rows against Claude Haiku 5.5 and GPT-6 Luna, all at maximum reasoning effort. Ember leads or ties on nine of them.

Higher is better in every row. Read the table with three things in mind.

First, five rows come from Artificial Analysis's independent runs, four are Meta internal evaluations, and one mixes sources. The two composite indexes, Agents' Last Exam and the Personal Superintelligence Index, are Meta's own constructions. Treat the independent rows as evidence and the internal rows as Meta's case.

Second, the Terminal-Bench row compares different harnesses. Ember's number comes from an Artificial Analysis run in the mini-swe-agent harness, Haiku's from Anthropic's self-reported Claude Code result, and Luna's from its Codex entry. When Artificial Analysis ran Haiku in its own harness, the score was 32.8 rather than 39.2, so the direction holds but the margin depends on the setup.

Third, AutomationBench circulates with two numbers. Meta's 37.8 percent is strict pass@1, meaning the whole workflow completed on the first attempt. Artificial Analysis reports 68.1 percent under partial credit, level with Muse Wonder. Both can be accurate; they measure different things. For production planning, the strict number is the one that predicts whether an end-to-end business workflow finishes unattended.

The decisive loss is FrontierCode 2.0-AA, where Haiku 5.5 scores 34.9 against Ember's 27.2. FrontierCode grades real changes in real repositories on whether a maintainer would merge them, which is the closest row in the table to asking whether the code is good enough to ship. If your agent opens pull requests rather than making scoped fixes, that row should outweigh the others.

Knowledge is the other weak spot. On Artificial Analysis's AA-Omniscience test, Ember's accuracy was 21.1 percent against 34.7 percent for Haiku 5.5, largely because it declined to answer 64 percent of the questions. The upside of that behavior is a hallucination rate of 17.4 percent, roughly half of Haiku's. Ember is a worker, not an encyclopedia. It is built to act on the documents and tools you hand it, not to answer from memory.

The planner and the worker

Meta's recommended deployment is a two-model loop, and it maps cleanly onto how mature agent harnesses already work. The planner reads the task, breaks it into bounded steps, decides what can run in parallel, and writes a brief for each step. The worker executes one brief at a time, in its own sandbox, and reports back a status line.

The brief is the whole contract, and it needs five parts: the task stated in full, the files the worker owns and may change, the checks to run with the exact expected last line of each, the result to return, and the escalation rule. If a worker discovers a dependency outside its brief or an ambiguous requirement, it stops and reports instead of improvising. That single rule is what keeps a cheap executor from quietly widening the blast radius of a project.

typescript type Brief = { stepId: string; task: string; files: string[]; checks: { command: string; expectedLastLine: string }[]; };

async function runPlan(briefs: Brief[]) { const results: string[] = []; for (const brief of briefs) { const res = await client.responses.create({ model: 'muse-ember-1.0', input: renderBrief(brief), tools: repoTools, }); const out = res.output_text; results.push(out); if (out.startsWith('STATUS: BLOCKED')) { return escalate(brief, out); } } return results; }

The important detail is not the API call, which is the same request shape Meta uses for its larger models. It is the machine-readable status line at the top of every worker response, which turns a natural-language answer into something the orchestrator can branch on. Without it, a worker that fails on a check reads exactly like a worker that succeeded, and the planner never learns.

Meta's developer blog walks through a concrete version of this pattern: porting 16 lexers from Python's Pygments library to Rust. Muse Wonder never opens a source file. One worker reads the Python implementations, the Rust engine, and the checker, and returns a map of how each lexer fits. Wonder turns that map into 16 briefs. Sixteen Ember workers each take one lexer in their own copy of the repository, port it, check it token for token and for speed, fix failures, and commit. Midway through, the map revealed that some Python lexers rewrite their token stream after lexing, which the shared engine could not express; Wonder had a worker add a post-filter to the engine while one lexer was already being ported, and the C, C++, Lua, and Swift ports picked it up. When one worker ran git in the main checkout by mistake, Wonder dispatched two workers to clean it up and the run continued. The 16 porters finished within about six minutes of each other.

Two lessons follow. The planner's job is not to write code; it is to be right about the shape of the work, which is where a frontier model earns its price. And supervision is a feature, not overhead. A cheap executor with no plan-level oversight produces cheap mistakes at scale, and cheap mistakes at scale are still mistakes.

Making the economics real in your own harness

A low list price is a hypothesis until it meets your workload. Five practices turn it into a number you can defend.

Cache the static prefix and keep it byte-identical. Anything that mutates the prefix, such as a timestamp near the top of the system prompt, breaks the cache hit and quietly reverts every call to the fresh input rate. Audit prompt assembly before assuming the $0.004 rate applies.

Bound the task and supply the source material. Meta's own guidance is to keep each request specific. Its invoice example asks the model to extract the invoice number, issue date, and total, and for each field to return the value, the source-page label, and a status of present, missing, or unreadable, with null when a value is unavailable. A structured output contract like that makes failures visible instead of plausible.

Do the arithmetic before designing fan-out. At published rates, the scenarios below are the difference between a viable pipeline and an expensive surprise.

Caching turns the extraction pipeline from $65 to $26.60, a 59 percent cut, purely by reusing a shared prefix. That is the calculation to run on your own traffic before deciding whether a migration is worth the engineering time.

Cap the spend. A model this cheap is easy to over-call. Parallel worker fan-out multiplied by retries multiplied by a document queue is a budget risk, and hard caps per task and per run cost less than a postmortem.

Treat tool output as untrusted input. Meta says it evaluated Ember's behavior when acting on a user's behalf, including whether it respects intent, handles sensitive information appropriately, resists instructions hidden in web pages, documents, and tool outputs, and seeks human input before high-impact actions. Meta did not publish numerical results for those checks. For a model that runs shell commands and edits repositories, sandboxing, approval gates, and network restrictions belong in the harness, not in a promise.

Where Ember is the wrong tool

What the launch actually signals

The release is less interesting as a leaderboard result than as a pricing decision. Two labs now sell a small model at the same headline rate, and the differentiator has moved to token efficiency, cache pricing, and how well the model behaves inside a tool loop rather than how it performs on a knowledge quiz. That is a real shift in what buyers should evaluate.

For teams building agents, the question is no longer which model is smartest. It is how to split a workflow so the expensive model touches only the parts that need judgment and the cheap model absorbs the volume. Ember's numbers make that split economically obvious, and its weaknesses make testing it operationally necessary: a knowledge gap that produces refusals, a FrontierCode deficit that matters for anything upstream of a merge, and a long-context tier that triples the rate for exactly the workloads the million-token window invites.

Run fifty of your own tasks through it - your routing, your extraction schemas, your worst tickets - and compare correctness, latency, and cost per finished task against whatever runs that step today. The launch page describes what Meta built. Your harness decides whether it is cheap.

References

• Introducing Our Smallest, Most Efficient Model: Muse Ember
• Artificial Analysis: Meta's Muse Ember is the cheapest model scoring 36 on the Intelligence Index
• Meta Developer Blog: Start building with Muse Ember