Meta Muse Ember: what it is, what it's for, and how to start using it

TL;DR

Meta Muse Ember is the cheap worker model in Meta's lineup. It costs $0.10 input and $0.50 output per million tokens, has a 1M token context window, and Meta built it for the small jobs an agent repeats all day: sub-agent tasks, tool calls, routing, and bulk work over files or records. The intended setup is two models: Muse Wonder or Muse Spark plans, Ember handles the volume.

Don't make it your only model. Meta's own docs send hard coding and knowledge-heavy questions to the bigger models. In support, Ember suits sorting and tagging tickets, and eesel's AI helpdesk teammate does that step on your helpdesk already. With the eesel CLI, a coding agent can upload your tag list and routing rules, then run test tickets before anything goes live.

What is Meta Muse Ember?

Muse Ember is the smallest model Meta Superintelligence Labs sells. It launched on November 9, 2026, with a launch post that pitches it at "the work agents repeat all day": tool calls, coding subtasks, routing, extraction and long document parsing.

Two facts set it apart from earlier small models:

• It was trained using Muse Wonder Full. When Meta shipped Muse Wonder, it said it would use the big model to build smaller ones. Ember is the first.
• It's a reasoning model with no off switch. Effort runs from minimal to max, and the none setting returns an error. Every call thinks a little.

I build the integrations and API plumbing for eesel's AI teammates, and the small-model slot is where most of the calls land. A support agent reads a ticket, decides what it is, tags it, looks up an order, and only then writes a reply. Most of those steps need a fast, accurate model more than a brilliant one. That's the slot Meta designed Ember for, and it's why I care about it more than another frontier launch.

Where does Muse Ember fit in Meta's lineup?

Meta now sells three reasoning models on the same endpoints. Meta's Choose a model page puts them side by side:

The gap between Spark and Ember is the interesting one. On the Artificial Analysis Intelligence Index, Meta's launch post puts Muse Spark 1.3 at 37 and Ember at 36. The cost of running the index was $2.39 per task for Spark and $0.14 for Ember. One point of index score for about 17 times the cost is a hard trade to justify on routine work.

That doesn't make Spark pointless. Meta still points knowledge-heavy questions and visual coding at Spark or Wonder, and an index average hides the tasks where the bigger model pulls away. But for anything you run thousands of times a day, Ember is where Meta wants you to start. My Muse Spark 1.3 pricing and Muse Wonder pricing breakdowns cover the other two cards.

What jobs should you give Muse Ember?

Meta's docs list four jobs, and they line up with how a real agent spends its tokens:

1. Sub-agent tasks. The focused coding tasks, terminal commands and lookups a main agent hands out.
2. Tool calls. Driving tool calls inside a larger workflow, where cost and delay per call add up.
3. Routing. Classifying requests and sending each one to the right handler or model.
4. Work across large collections. The same task over thousands of images, files or records, run in parallel.

The first example in Meta's own Ember docs is a support ticket: classify "I was charged twice for my October invoice" as billing, bug or feature request, with a one-line reason. Meta picked ticket classification as the showcase, which tells you who they expect to use it.

Here's Meta's workload table as a quick picker. Click a job to see which model Meta recommends for it.

How do you call Muse Ember?

Ember lives on the Meta Model API at api.meta.ai, and it accepts the same request body as Muse Spark. If you already call Spark, switching is a change to the model field. Here's Meta's first-call example, trimmed:

curl -X POST "https://api.meta.ai/v1/responses" \
  -H "Authorization: Bearer $MODEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "model": "muse-ember-1.0",
  "reasoning": { "effort": "low" },
  "input": "Classify this support ticket as billing, bug, or feature request: \"I was charged twice for my October invoice.\""
}'

A few details from Meta's reasoning docs that are easy to miss:

• Effort lives in different places per endpoint. Chat Completions takes a top-level reasoning_effort. The Responses API nests it as reasoning.effort.
• Unset effort means max. Spark defaults to high. If you copy a Spark call and leave effort out, Ember thinks as hard as it can on every request. Reasoning tokens bill as output, so pick a level on purpose.
• Reasoning carries across turns only on the Responses API. Chain turns with previous_response_id. On Chat Completions each turn starts fresh.
• It also speaks Anthropic's format. Ember supports the Messages endpoint, which is why existing Claude Code setups can point at it.

That last point matters for coding teams. Meta's model guide tells Claude Code subagents users to map the opus alias to Muse Wonder, sonnet to Muse Spark 1.3, and haiku plus the sub-agent model to muse-ember-1.0. Codex users get a similar recipe, with Wonder as default and Spark for cheaper sessions. My Claude Code model selection post explains how those aliases work.

Where can you get Muse Ember?

Ember launched in four places:

• Meta Model API. Pay as you go, Standard mode only. There's no Contributor-mode discount for Ember, unlike Spark.
• Muse Code. On pay-as-you-go and every subscription plan. A request over 200K input tokens uses your plan allowance faster. My Muse Code pricing guide covers the plans.
• Google Cloud. Through the Model Garden, alongside Spark and Wonder.
• Oracle Cloud. Announced in the same launch post.

There are no open weights. Meta's open model remains Muse Spark Open, a much larger download.

On price, the full card from Meta's pricing page is:

The second row is the one to watch. Once a request crosses 200K input tokens, the whole request bills at three times the base rate, and cached tokens plus stored conversation history count toward the threshold. Wonder and Spark charge the same at any length. My Muse Ember review goes deeper on that cliff, the missing batch discount, and the per-task math against Claude Haiku 5.5.

How does Muse Ember compare with other small models?

Meta benchmarked Ember against Claude Haiku 5.5 and GPT-6 Luna, all at max effort. The rows that matter most for agent work:

AutomationBench is the row I'd watch. It scores end-to-end business workflows: pull a record, call tools in order, update another system. That's most of what an AI agent does between messages, and Ember nearly triples Haiku there.

Read the table with two caveats. Terminal-Bench ran each model in its own best harness, so it isn't a like-for-like test. And FrontierCode 2.0, which grades whether code would actually get merged, goes to Haiku by almost eight points. If you're also weighing Gemini 3.8 Flash or DeepSeek V4 Flash, my Haiku 5.5 alternatives roundup covers the wider field.

What did Meta's launch partners say?

Five companies tested Ember before launch, and their notes are the most concrete early evidence:

• Cloudflare: its CTO said Ember ran "up to 30% faster at the tail" than the comparable model it tested, and handled multi-repo investigation well.
• You.com: reported a p95 latency of 2.2 seconds on its coding tests, with 36 to 48% fewer output tokens than leading open-weight models.
• Box: used it to score contracts clause by clause against a negotiation playbook, and to screen candidates against a hiring brief.
• Cline: called it built for subagent work like coding and document analysis.
• Oracle: said it showed promise on complex engineering tasks in early testing.

These are partner quotes on Meta's own launch page, so treat them as early signals, not independent tests. Still, the pattern is consistent: speed, fewer tokens, and good results on bounded jobs.

On safety, Meta says Ember went through the same core training and testing as its bigger models under its Superintelligence Scaling Framework, and stayed below the high-risk thresholds for chemical, biological, cyber and loss-of-control risks. Meta also tested whether it resists instructions hidden in web pages, documents or tool outputs, which matters for any model that reads customer emails.

What does Muse Ember mean for support teams?

For support, Ember is a model for the sorting work, not the whole agent. The steps it suits are the ones that happen to every ticket before a human or a bigger model writes a reply:

• AI ticket classification and ticket prioritization
• Routing to the right team or queue
• Ticket summarization for handoffs
• Pulling order numbers, emails and dates into ticket fields

That's real work at real volume. smava, a German loan comparison company, runs eesel on Zendesk across two brands. In one month it handled 27,000 tickets, categorized 14,600 of them by language, reply eligibility and topic, and prepared 15,300 draft replies. The sorting step alone runs thousands of times a month, which is exactly where a cheap, fast model pays off.

The request shows up on eesel's sales calls too. One B2B telematics team asked for automatic tagging from a fixed tag list, auto-filled ticket fields, and translation for agents, all before anyone writes a reply. None of that needs a frontier model. All of it needs to be right on every ticket.

What Ember doesn't give you is the rest of the job. A model on its own has no Zendesk or Freshdesk connection, no knowledge of your help center, no handoff rules, and no way to check itself against your past tickets. Qontro, an ERP software company, shows what that extra layer looks like: every Freshdesk ticket arrives with a draft and linked help articles, after about two knowledge searches per ticket across 9,800 past tickets and articles.

If you want to build it yourself on Meta's models, my Muse for support ticket triage and Muse for Zendesk guides walk through the wiring. If you'd rather hire the finished worker, see below.

Should you use Meta Muse Ember?

Use it if:

• You run an agent that hands out many small jobs and the bill is mostly sub-agent calls.
• You classify, tag, extract or route at volume and want a cheap model that holds up on agent benchmarks.
• You already use Claude Code or the Responses API and can test it with a model ID swap.

Skip it, or pair it, if:

• Your main loop needs deep planning or hard coding. Meta itself sends that to Wonder or Spark.
• Your requests routinely pass 200K input tokens, where the price triples.
• You need open weights or a batch discount, neither of which Ember offers today.

For most teams the answer is "both": a bigger model for the thinking, Ember for the volume. That's Meta's own advice, and it's how I'd set it up. For more context on how small models fit an agent stack, see my best AI model for support tickets guide.

Hire eesel for the sorting step instead

Ember makes the tagging and routing step cheap to run. eesel makes it something you don't have to build. eesel's AI helpdesk teammate joins your helpdesk, learns from your past tickets and help center, then tags, routes and drafts replies on the tickets that come in. Before it touches a customer, you run it against your historical tickets and see what it would have done.

It's the same job Meta designed Ember for, already connected to Zendesk, Freshdesk, Gorgias and more, with the handoff rules built in. And if you'd rather drive the setup from a terminal, the eesel CLI lets a coding agent upload approved knowledge, adjust instructions and run test questions, while someone with admin access still approves the helpdesk connection. Pricing is on the eesel pricing page.

Try eesel on your own ticket history and see how it sorts your queue.