Muse Ember wants the subagent slot. Its list price matches Haiku and Luna

Meta wants a specific job inside agent systems: the worker that runs dozens or thousands of small, bounded tasks while a larger model plans. Muse Ember, released on 9 November 2026 as muse-ember-1.0, is the model it built for that slot. Meta’s documentation puts it on “sub-agents and background tasks, which run many short, focused jobs where cost adds up”, with Muse Wonder or Muse Spark doing the planning above it.

The headline price, $0.10 per million input tokens and $0.50 per million output tokens, is not what separates it from the competition. Claude Haiku 5.5 and GPT-6 Luna list at exactly the same base rates. What differs is the structure around the price: Ember charges $0.004 per million cached input tokens against $0.01 for the other two, keeps its base rate up to 200K input tokens where Haiku switches at 100K, and defaults to maximum reasoning effort where both rivals default to medium. Those details, plus how many tokens each model spends to finish a subtask, decide what an executor actually costs.

For a team running a planner and executor design, that makes Ember a candidate worth testing rather than a default to adopt. The capability evidence is mostly Meta-reported or Meta-selected, and several of the comparisons pit Ember in one harness against rivals in another. This article sets out what was released, reconstructs what Meta’s own showcase run cost from the published token counts, sorts the benchmark claims by who measured them, and proposes a test for the executor role. GenAI Brief has not run the model.

What Meta released on 9 November

The announcement on Meta’s research blog, dated 9 November 2026 with no author byline, calls Ember Meta’s “smallest and most efficient model designed for complex reasoning execution”. It lists the intended work as “tool calls, coding subtasks, routing, extraction, and long document parsing”, and closes the positioning with a single line: “Muse Wonder plans, Muse Ember handles the volume.”

The developer documentation carries the specifications. The table below collects them from the pages read on 12 November 2026.

The Muse Ember documentation page says Ember “accepts the same request body as Muse Spark”, so Spark examples should need little more than a change of model ID, at Ember’s lower per-token price. It also states the limits plainly: “For hard single-shot coding problems, knowledge-heavy questions, or visual coding, use Muse Spark or Muse Wonder.”

Two small inconsistencies are visible across sources. Meta’s documentation lists audio, video and PDF input, while Artificial Analysis’s model page records text and image input only. And the announcement says Ember is “now available on Google Cloud and Oracle Cloud”, while the developer model page links only a Google Cloud Marketplace listing. Neither changes the executor question, but a team that depends on audio input or an Oracle deployment should confirm it directly.

Closed weights, unlike Muse Spark Open

Ember is an API model. Meta’s documentation index files it under “API-hosted models” alongside Wonder and Spark, and lists only Muse Spark Open and Muse Glimmer under open-weight models. It says you run Muse Spark Open “yourself or through a hosted provider, not on Model API”, and that Glimmer is self-hosted. Artificial Analysis labels Ember proprietary with weights not available. Meta’s announcement itself never uses the words open or closed, so this is an inference from Meta’s own catalogue rather than a quoted policy.

That matters for executor design because the executor is often the component teams most want to self-host: it runs at the highest volume, sees the most raw data and sits deepest in the loop. Our analysis of what changes when Muse Spark Open’s weights are available covers the deployment paths an open checkpoint creates. None of those paths exists for Ember. A team choosing it accepts Meta’s hosting, rate limits and model lifecycle in exchange for not operating the model.

Dates to keep apart

Several dates attach to this release and they answer different questions.

Prices, rate limits and leaderboard positions move. Everything quantitative below is as listed on 12 November 2026 unless a different date is given.

The executor role, in Meta’s own words

Meta is unusually specific about how it expects Ember to be used. The Build with Muse Ember post describes it as the model for “repeated, bounded work” and lays out a division of labour: Wonder or Spark plans repository-wide changes, dependencies and acceptance criteria; Ember takes bounded subtasks with the relevant files, constraints and tests; Wonder or Spark, “alongside developer review”, reviews the combined changes and reasons through unresolved issues.

The handoff is defined in one sentence: “Define the handoff: the task, relevant context, files the worker can change, acceptance checks and the result to return.” The escalation rule is defined in another: when a worker finds “a broader dependency or an unclear requirement”, it should “send the finding back to the planner before continuing”.

Those two sentences are the interface a planner and executor design depends on. The first fixes what the executor receives. The second fixes when it must stop. A cheap executor that ignores the second rule and pushes ahead on an unclear requirement can be more expensive overall than a pricier one that escalates correctly, because the planner then has to unwind the work.

The model-selection guide adds two practical points. It states that “a larger model plans, and sub-agents run many bounded tasks”, and it records how third-party harnesses map onto the Muse family: Claude Code and the Claude Agent SDK map opus to Wonder, sonnet to Spark and haiku, plus the sub-agent model, to Ember. In other words, Meta has slotted Ember directly into the position Haiku occupies in Anthropic’s own tooling. For developers calling the API directly, the guide’s advice is to “pass a different model on each request”, which means the routing between planner and executor lives in the developer’s code or harness, not in the API. Our explainer on what an agent harness is covers why that surrounding loop moves results as much as the model does.

Anthropic’s positioning of Haiku 5.5 is close to identical. Its Haiku 5.5 page says the model “pairs well with Opus 5.5 and Sonnet 5.5 as a subagent on coding work” and is “designed for high-volume, cost-sensitive tasks”. OpenAI’s Luna model page calls it “our most efficient model for focused, high-volume tasks”. Three vendors are now selling the same slot at the same base price.

Three small models, one list price

The base rates match. The structure does not. The table compares the three executors on the terms that change a bill, from each vendor’s pricing documentation as read on 12 November 2026.

Four differences follow from the table.

Ember’s cache read costs 40 per cent of its rivals’. At $0.004 against $0.01, and with no cache-write fee on Meta’s pricing page, Ember is the cheapest of the three for workloads where many calls share a long prefix: the same repository map, tool definitions and instructions sent to every worker. Meta’s prompt-caching documentation says the API “caches the stable prefix automatically” with no flag to set, and that the optional "24h" retention setting “is a hint, not a guarantee”. The caching page does not name Ember explicitly; the price is on the pricing page. Our guide to prompt caching costs explains why cache hit rate, not list rate, usually determines the input bill.

Haiku’s long-context cliff arrives first and falls furthest. Anthropic’s pricing notes say a Haiku 5.5 request “whose prompt is over 100,000 tokens pays higher prices”, including when part of the prompt is a cache hit. The higher tier is five times the base rate. Ember’s tier starts at 200K and is three times base. Luna’s starts at 272K and is gentler again. Executors that receive large slices of a codebase can cross these lines without anyone noticing.

Luna has a discount Ember does not. OpenAI prices Batch and Flex at 50 per cent of standard rates; Anthropic offers 50 per cent off batch. Meta’s pricing page lists no batch rate for Ember. For offline extraction or classification that can wait, Luna and Haiku in batch mode list at half Ember’s base price.

Ember’s default is the most expensive setting. This is covered in its own section below, because it is the line most likely to surprise a team that switches model IDs without changing anything else.

Meta’s other cheap option trains on your data

Ember is not the cheapest token Meta sells. The pricing page lists Muse Spark 1.3 in Contributor mode at $0.10 input, $0.002 cached input and $0.20 output, in exchange for permission to “use your content to train future Meta models”. Ember runs only in Standard mode, which the same page says is not used for training. A team comparing Meta’s options on price alone could land on Spark Contributor and inherit a data-use term it did not intend. For most executor workloads, which see source code, documents and customer records, Standard mode is the relevant comparison.

Standard Spark 1.3 lists at $1.25 input and $4.25 output. Meta’s announcement shows Ember at 36 on the Artificial Analysis Intelligence Index against Spark 1.3’s 37, at $0.14 per index task against $2.39, roughly a seventeenth of the cost for one point less. That is the strongest internal argument Meta makes for Ember, and it is also an argument about Spark’s pricing.

What Meta’s showcase run actually cost

Meta’s cookbook publishes enough data to check its own cost claim, which is rare and useful. The Python-to-Rust recipe has Muse Wonder (muse-wonder-1.0, at high reasoning effort) plan the work, write each worker’s handoff and check the results, while Muse Ember workers, running at "effort": "max", port 16 Pygments lexers from Python to Rust in parallel, each in its own worktree. A port counts as done when “it matches the Python reference on every input and Rust is no slower than Python”. The blog reports a match on all 383 test inputs and 62 held-out files, with Rust running 3.0 to 7.3 times faster.

The recipe’s README lists token usage across its three prompts, with cached input included in the input totals:

The blog post says the run “cost about $3.96 at pay-as-you-go prices: $2.12 for Muse Wonder and $1.84 for Muse Ember”.

Reconstructing the bill

We recomputed both lines from the published tokens and Meta’s list prices. This is GenAI Brief’s arithmetic, not a measured invoice.

The planner line matches Meta’s $2.12 exactly. The worker line does not: base-tier pricing gives $1.46 against Meta’s $1.84, a gap of $0.38. The most plausible explanation is that some worker calls exceeded 200K input tokens and were billed at long-context rates for the whole request; if roughly 13 per cent of the worker token volume had been billed at the higher tier, the totals would agree. The average worker call carried about 107,000 input tokens, so a tail above 200K is plausible. The recipe does not break calls down by size, so this is an inference, and it is equally possible that the blog’s run and the README’s token table come from different recorded runs. The README says its results come from one of three recorded runs, all of which passed every check.

Either way, the reconstruction shows three things about how an executor’s cost is made up.

Caching carried the economics. 97.8 per cent of Ember’s input tokens were cache hits. Without caching, the same tokens at $0.10 would have cost about $16.25 instead of $1.46. Ember’s cache-read rate, not its headline input rate, was the price that mattered.

The cache-rate difference is visible at this scale. Applying Haiku’s or Luna’s $0.01 cache-read rate to the same tokens, and ignoring their cache-write fees, gives about $2.39 instead of $1.46. That is a sensitivity on list prices, not a prediction: the other models would use different tokenisers, take different paths through the task and produce different token counts.

Sending the volume to the planner would have been expensive. The same worker tokens at Wonder’s rates come to about $64.60; at Standard Spark 1.3 rates, about $31.69. Again, different models would spend different tokens, but the order of magnitude is the point of the planner and executor split.

The second example has two totals

Meta’s second showcase, organising a 10,000-photo camera roll, is less tidy. The same blog post states in its introduction that the photos were “captioned, renamed and sorted into albums for $1.59 in total, and only $0.50 of that was Muse Ember”, and in its results section that “the whole job cost $1.33: $0.81 for Muse Wonder and $0.52 for Muse Ember”. The post does not reconcile the two. The run used 16 Ember subagents, eight photos per request, minimal reasoning effort and 512-pixel images, and the albums “agreed for about 86% of photos” with the dataset’s own labels after mapping to the closest categories. Meta adds that at Wonder prices the photo requests “would have cost about $20”.

The inconsistency is small in dollars and does not change the conclusion. It is a reminder that vendor worked examples are illustrations, not audited results.

The benchmark evidence, sorted by who measured it

Meta’s headline claim is that Ember “delivers more intelligence per dollar than Claude Haiku 5.5 or GPT-6 Luna at any reasoning setting”. The supporting tables mix results run by Artificial Analysis, results run by Meta and results taken from each rival vendor’s own reporting. The evaluation methodology explains which is which, and it adds a caveat that belongs next to every comparison: “Internally generated competitor runs use common settings where practical but remain best-effort: prompts, tools, and runtime may not be optimally tuned for proprietary models.”

All results below are at max reasoning effort, through the Meta Model API for Ember, as Meta reports them.

Where the comparison is like for like

The Artificial Analysis rows are the closest to controlled comparisons, because one third party ran all three models. On those, Ember’s strongest result is AutomationBench-AA, where agents complete business workflows through simulated SaaS APIs and deterministic checks inspect the final state. The metric is the share of tasks completed in full, “with every objective met and no guardrail violated”. Ember’s 37.8 per cent against 13.9 and 20.2 is the result most directly relevant to an executor that calls tools, and it is the largest margin in the table.

The same source shows the limits. Haiku 5.5 leads FrontierCode 2.0, which grades whether a maintainer would merge a change in a real repository. Ember and Luna tie on GDP.pdf. The Coding Agent Index runs each model inside a different coding agent, Muse Code for Ember, Claude Code for Haiku and Codex for Luna, so it measures model-plus-product combinations rather than models alone.

Where it is not

Terminal-Bench 4.0 is the clearest case of mixed sourcing. Meta’s methodology says Ember’s 40.9 per cent “is Artificial Analysis’s run in the mini-swe-agent harness”, Haiku’s 39.2 per cent is “Anthropic’s self-reported Claude Code result from the Claude Haiku 5.5 system card”, and Luna’s figure is “the Codex result on the Terminal-Bench leaderboard”. Three models, three harnesses and three different reporters. The 1.7-point gap between Ember and Haiku says little when the harness changes between columns.

The Meta-internal rows carry their own conditions. Agents’ Last Exam excludes five of 105 Linux tasks “for every model” because of storage limits or scripts that returned no score, uses partial credit, and relies on GPT-5.5 for its few model-judged checks. Meta notes that the official leaderboard compares agent products, while Meta ran every model in one internal loop. OSWorld 2.1 runs outside the official runner with Claude Sonnet 4.6 as judge. The Personal Superintelligence Index blends eight evaluations, two of which, the Verifiable Browsing Task and FocusBench, are internal Meta evaluations.

The methodology does contain practices worth crediting. Refusals receive zero credit and “remain in the denominator rather than being dropped”, and truncated responses are graded as they are. Samples lost to infrastructure or grading errors “are not scored”, which is common but means the denominator is not always the full task set.

What independent pages show

Two third-party pages carried Ember results by 12 November. Artificial Analysis lists Ember at 36 on its Intelligence Index at max effort and 34 at xhigh, with costs of $0.14 and $0.12 per index task, about 452 output tokens per second and Meta as the only listed provider. The page gives 5.05 seconds to first answer token in its summary without naming the setting, and 3.89 seconds for xhigh in its comparison, so we do not rely on either figure for the max-effort configuration.

Vals AI, evaluating on 9 November at max effort with maximum output tokens and default sampling, reports 60.48 per cent on its Vals Index, ranked 13th of 36 models in its results table, at $0.153 per test, which its update notes call “the lowest cost per test of any model on the index”. On Terminal-Bench 4.0, Vals measured 39.39 per cent against the 40.9 per cent Meta cites from Artificial Analysis. A one-and-a-half-point difference between two harnesses is ordinary; it is useful as a sense of how much a single benchmark moves when someone else runs it.

Checking the “third of the cost” claim

Meta’s cost chart plots each model’s Intelligence Index score against cost per index task at several reasoning settings. Ember’s two points are $0.116 for 33.9 and $0.136 for 35.8. Haiku’s four points run from $0.092 for 24.6 to $0.411 for 36.2. Luna’s three run from $0.073 for 21.4 to $0.152 for 27.8. The chart does not label each point explicitly; the mapping to effort levels is inferred from the order.

On those numbers, Ember’s best point costs 33 per cent of Haiku’s best point for a score 0.4 lower, which supports Meta’s statement that Ember “matches Haiku’s best score at about a third of the cost”. Because all three models share a token price, the whole difference comes from how many tokens each spends per task. That is a claim about Ember’s token efficiency on Artificial Analysis’s task mix, and it is the claim a team should try to reproduce on its own subtasks. Our analysis of how benchmarks became a marketing channel covers why a vendor’s choice of comparison set deserves the same scrutiny as the scores.

Default max effort is the first setting to change

Meta’s reasoning documentation is explicit about the default: when the parameter is omitted, the model “reasons at its default level”, and that level is max on Muse Wonder and Muse Ember. On every Muse Spark version the default is high. Haiku 5.5 and Luna both default to medium. The same page states that “reasoning tokens are billed at the same rate as visible output tokens”, that higher effort means “more reasoning tokens, latency, and cost”, and that at max reasoning tokens make up a larger share of output, “so set the output-token limit generously”.

A team that changes a model string from Haiku or Spark to muse-ember-1.0 and leaves everything else alone therefore moves from a medium or high default to max on every executor call. For a classification or field-extraction subtask, that is likely to buy little. Meta’s own guidance is to “use the lowest level that gives you acceptable results” and, for direct-answer tasks such as lookups, formatting and translation, to set effort to low.

Meta’s examples follow that advice selectively. The Rust-porting workers ran at max, while the photo pipeline ran at minimal effort. Artificial Analysis’s two Ember settings show what the top of the range costs on its task mix: xhigh scores 34 for $0.12 per task, max scores 36 for $0.14. The Ember documentation lists levels from minimal to max, and the reasoning page says none is not supported and returns HTTP 400, so there is no reasoning-off mode; teams that relied on none with other models need a different floor.

The practical rule is to treat effort as part of the executor’s configuration, set per task type, and recorded with every evaluation result. An Ember score without an effort level is not comparable to anything.

A proposed test for the executor slot

The useful unit for an executor is cost per accepted subtask, not cost per token or score on a public benchmark. The following protocol is proposed by GenAI Brief; it is not a Meta procedure and we have not run it.

1. Collect real handoffs. Take 200 to 500 subtasks your planner has already issued, with Meta’s five handoff fields made explicit: task, context, editable files, acceptance checks and expected result. Keep a held-out set you do not inspect while tuning prompts.
2. Make acceptance mechanical. Each subtask needs a check that does not depend on the executor’s own report: tests that pass, a schema that validates, a diff that applies, an extracted field that matches a label.
3. Fix effort per task type. Run each candidate at two or three explicit effort levels. Never rely on defaults, which differ across the three vendors.
4. Record five numbers per call. Uncached input, cached input, output including reasoning, wall-clock latency and the long-context tier the request fell into.
5. Count escalations separately. Score whether the executor correctly sent a broader dependency or unclear requirement back to the planner, and whether it pushed ahead when it should have stopped.
6. Include the planner’s review cost. Every escalation and every failed check costs planner tokens. Add them to the executor’s line.
7. Repeat runs. Meta’s own README warns that “models are non-deterministic; your code, time and results may differ”. Three runs per configuration is a minimum for a decision.

A worked example with hypothetical inputs

Suppose a code-maintenance planner issues subtasks with 60,000 input tokens each, of which 50,000 are a cached prefix and 10,000 are new, and each subtask produces 2,000 output tokens including reasoning. Holding token counts equal across models, which isolates price structure, list prices give:

Cache-write fees for Haiku and Luna are excluded, which flatters both slightly. The table shows that the cheapest executor depends on prompt size. At 60K the three are within 15 per cent of each other. At 150K, Haiku’s whole request has crossed its 100,000-token threshold and costs more than six times Ember’s. At 250K, Ember has crossed its own 200K threshold and Luna, still under 272K, is cheapest. A planner that ships whole files rather than relevant slices can move an executor from one column to another.

Now add quality, again with hypothetical numbers. Executor A costs $0.0022 per attempt, passes acceptance 80 per cent of the time and escalates 10 per cent of subtasks to a planner review costing $0.05. Executor B costs $0.0050 per attempt, passes 92 per cent of the time and escalates 4 per cent. Cost per accepted subtask is the attempt cost plus expected planner cost, divided by the pass rate:

• Executor A: ($0.0022 + 0.10 × $0.05) ÷ 0.80 = about $0.0090
• Executor B: ($0.0050 + 0.04 × $0.05) ÷ 0.92 = about $0.0076

The executor with more than twice the token cost is cheaper per accepted result, because planner time dominates. This is the arithmetic behind the planner and executor split, and it is why a lower token price is necessary but not sufficient for Ember to win the slot. The measured inputs, pass rate and escalation rate, have to come from your own handoffs.

What remains unknown

Several facts a production team would want were not available on any page read for this article.

The model’s size and training. Meta gives no parameter count. The announcement says Ember “is the first trained using Muse Wonder Full”, Meta’s subscription-only top model, but does not say what that means: distillation, synthetic data, grading or something else. Without it, there is no way to reason about which of Wonder’s behaviours Ember is likely to inherit.

A full model card. The announcement includes a short safety summary: Ember was evaluated under Meta’s Superintelligence Scaling Framework for chemical and biological, cybersecurity and loss-of-control risks and “remained below the framework’s high-risk thresholds”, and its agentic behaviour was tested for respecting user intent, handling sensitive information, resisting instructions hidden in web pages and seeking human input before high-impact actions. The announcement publishes no results for those agentic tests. For an executor that may take actions, those numbers matter more than a leaderboard position. Our guide to reading a model card sets out what a complete disclosure looks like.

Lifecycle commitments. Anthropic’s models overview commits to retiring Haiku 5.5 “not sooner than October 7, 2027”. We found no equivalent statement for Ember. An executor wired into hundreds of handoff prompts is costly to re-qualify, so the notice period is a real procurement question.

Batch pricing and retention. Meta’s pricing page lists no batch rate and no data-retention period for Ember. It does say that in Standard mode “your content is not used to train Meta models”.

Latency under load. The latency claims come from partners quoted in Meta’s announcement: You.com reports “a p95 of 2.2 seconds” and 36 to 48 per cent fewer output tokens, and Cloudflare says Ember “ran up to 30% faster at the tail than the comparable model we tested”, without naming that model. These are vendor-selected testimonials, not reproducible measurements, and Artificial Analysis’s page does not say which setting its 5.05-second time-to-first-token figure applies to.

Independent executor-specific evidence. No third party has yet published a study of Ember as a subagent under a planner: escalation behaviour, handoff compliance or failure modes in long parallel runs. The cookbook runs are the only evidence of that kind, and Meta produced them.

What would change the conclusion

Three findings would move the judgement. An independent controlled run, with all three models in the same harness at matched effort, showing Ember’s token-efficiency advantage holding on agentic tasks would make the “intelligence per dollar” claim much stronger. Evidence that Ember escalates appropriately rather than pressing on would address the failure mode that makes cheap executors expensive. In the other direction, a batch discount or a cache-rate cut from Anthropic or OpenAI would remove Ember’s main structural price advantage, since base rates are already level.

What to do if you run a planner and executor stack

Ember is a credible entrant for the executor slot, from a vendor that has documented the handoff interface more clearly than most. The case for it is not its token price, which it shares with Haiku 5.5 and Luna, but its cache-read rate, its 200K long-context threshold and a token-efficiency claim that its AutomationBench result supports and its FrontierCode result does not.

• Set effort explicitly before anything else. The default is max. Choose per task type and record it with every result.
• Measure tokens per accepted subtask, not price per token. The three models cost the same per token, so the whole difference is in how many they spend and how often the planner has to step in.
• Log which pricing tier each request lands in. Haiku switches at 100,000 tokens, Ember at 200K and Luna at 272K, and each applies the higher rate to the whole request.
• Keep prefixes stable. Ember’s economics depend on caching; Meta’s showcase run had 97.8 per cent cache-hit input.
• Check the data terms on Meta’s cheaper option. Spark 1.3 Contributor mode is cheaper per token than Ember because it trains on your content.
• Keep the executor swappable. With three vendors selling the same slot at the same base price, and none yet independently tested as a subagent, the model behind the executor role should be a configuration value with its own evaluation set, not a dependency written into every handoff prompt.