Meta’s Muse Ember Starts at $0.10—Which Tasks Can You Hand It?

Meta puts a price on repetitive execution

Meta released Muse Ember on November 9 as a lightweight model for agent execution. TechCrunch reported the launch. For builders reading on November 10, the immediate question is practical: which parts of an existing workflow deserve a cheaper model, and which still need the expensive one?

Meta lists starting API rates of $0.10 per million input tokens, $0.004 for cached input and $0.50 for output. Its announcement names the model muse-ember-1.0 and says it is available through Meta Model API and Muse Code. These are published rates and availability claims, rather than measurements from our own deployment. Meta’s launch announcement

The interesting purchase here is delegation. A system may need substantial reasoning to decide what to do, then spend much of its run extracting fields, checking records or carrying out a narrow coding instruction. Paying the same model for every step makes sense only if those steps actually need its capabilities. Ember gives developers a concrete new candidate for separating those jobs.

That is a reason to run an evaluation, not a reason to replace your default model before lunch. The useful unit of comparison is an accepted result: something your application can use without another model or a person repairing it. A low token bill attached to an unusable answer is still a bill.

Start with a job you can describe precisely

Meta’s developer documentation positions Ember for repeated execution, including delegated tasks, tool calls and routing. It lists text, image, video, audio and PDF inputs, with text output. That distinction matters: accepting a video does not mean generating one. The documentation also lists adjustable reasoning effort, defaulting to max. Muse Ember documentation

A sensible first assignment is something with an explicit contract. For a hypothetical invoice workflow, that might mean returning a supplier identifier, an invoice date and the evidence supporting each field. The application can then check required fields, compare identifiers against its records and reject unsupported values. The model has a defined job, and you have a way to tell whether it did it.

“Review this customer account and resolve the issue” is a much larger assignment. It bundles interpretation, policy selection, information retrieval and a potentially consequential action. Before routing that request to Ember, split it into decisions you can inspect. Fetching a record and deciding whether to issue a refund do not need the same permissions or evaluation criteria.

The strongest initial candidates are therefore steps where your team already knows what success looks like. A function with existing tests, a document extraction with reference answers or a routing decision with clear labels gives you useful feedback. An open-ended task judged by whether its prose sounds confident gives you very little.

The starting price is only the first line of the calculation

There is a qualification to the headline rate. Meta’s model page distinguishes requests below and above 200K context. Its longer-context row lists $0.30 per million input tokens, $0.012 for cached input and $1.50 for output. Check the applicable tier before estimating a document-heavy workload; a large supported context does not imply one flat rate. Muse Ember model and pricing page

Consider a hypothetical short-context call with 10,000 uncached input tokens and 1,000 output tokens. At the starting rates, the token charge is $0.0015: $0.001 for input plus $0.0005 for output. That is arithmetic using the published prices, not a measured Ember workload. It excludes any additional billable activity and says nothing about whether the answer passes your checks.

Now put that call inside a real application. A rejected result may trigger another attempt. An unresolved case may go to a larger model. A tool may charge separately. A human may need to inspect an exception. Your accounting needs to follow the request through those branches, rather than stopping when the first model returns text.

For an evaluation, divide total measured spending by the number of accepted tasks. Keep completion time beside that figure, including retries and escalation. Otherwise, a configuration can appear economical because it abandons difficult requests, or appear quick because the slow repair work happens outside the timer. Neither result tells you what operating the product will feel like.

Read the benchmark labels before the leaderboard

Meta reports an AutomationBench-AA score of 37.8% for Ember at maximum reasoning effort, identifying the measure as strict pass@1. It also reports 61.6% on Agents’ Last Exam, explicitly labeling that result an internal evaluation on the Linux subset. Those qualifications belong beside the numbers. Meta’s benchmark disclosures

These results provide evidence about particular evaluation conditions. They do not establish a success rate for your application. A strict pass@1 score describes a specific evaluation rule; an internal subset describes a particular test population. Neither tells you how Ember handles your oldest documents, your unusual tool schemas or the ambiguous requests your support team sees every Friday.

The model page provides another useful reminder against declaring a universal winner. On FrontierCode 2.0-AA, it lists Ember at 27.2 and Claude Haiku 5.5 at 34.9. A model can look attractive for one kind of execution and trail on another coding measure. Read across the tasks that resemble your work, rather than choosing the most flattering chart. Meta’s published benchmark table

For a builder, the next experiment is more valuable than a victory lap. Replay representative work through your current configuration and an Ember variant. Preserve the same inputs, tools and acceptance criteria. Record failure types separately: a wrong argument, an unsupported extraction and an incomplete code change demand different fixes, even if all three receive a failing grade.

Routing needs an exit, not just an entrance

An Ember trial needs an explicit escalation policy. If an extraction lacks supporting evidence, return the case for review. If a coding change fails the relevant checks, stop or hand it to another model. If a tool returns an unfamiliar error, avoid treating another confident explanation as proof that the underlying operation succeeded.

Keep that policy in application logic wherever possible. Asking a model whether it feels certain is a weak substitute for checking the property you care about. A parsed record can satisfy a schema while containing the wrong account number. A patch can compile while changing the wrong behavior. Validation needs to match the consequence of the task.

Model routing also leaves tool permissions intact. A less expensive executor does not need broader access to compensate for narrower reasoning. Give a lookup task read access; give a proposed change a reviewable destination. This is an architectural recommendation for an Ember deployment, rather than a claim that Meta supplies those controls automatically.

Existing agent guidance supports keeping the system understandable. Anthropic’s engineering article distinguishes predefined workflows from more autonomous systems and recommends starting with simple, composable approaches. Applied here, that means introducing Ember at a visible boundary before allowing it to choose its own responsibilities across an entire application. Building effective agents

The useful launch experiment is deliberately narrow

Pick one recurring task that already has examples of acceptable and unacceptable results. Include awkward cases, not just clean demonstrations. Preserve the original response, validation outcome, token usage, elapsed time and any later intervention. This gives you a trace of what happened when a cheap first attempt became an expensive finished job.

Test reasoning settings deliberately, too. Because Meta documents max as the default, leaving the setting unspecified is still a configuration choice. Compare settings against the same acceptance criteria before deciding which belongs in production. There is no verified basis here for promising a particular latency improvement from changing that setting.

Keep the first rollout reversible. A document parser can produce suggestions alongside the existing parser. A coding subtask can generate a patch for review. A routing model can propose a destination while the current logic remains responsible for delivery. These arrangements let you observe disagreement before it becomes a customer problem.

Ember’s release makes task-level model selection worth another look. The decision is whether its published pricing and measured behavior improve a specific part of your system after validation and escalation. If the trial passes, expand that responsibility. If it fails, you have identified a boundary instead of buying a cheaper route to the same unresolved work.

Frequently asked questions

What is Muse Ember?

Meta’s new lightweight model for repeated execution tasks, including tool use, routing and focused coding work.

What is its starting API price?

Meta lists $0.10 per million input tokens and $0.50 per million output tokens; cached input and long-context requests have separate rates.

What is the best first test?

Try one bounded task with existing acceptance checks, then measure total spending, completion time and escalation before expanding its role.