Meta Muse Ember Targets Agent Grunt Work — Tool Calls and Routing at $0.10/M

On 9 November 2026 Meta Superintelligence Labs released Muse Ember, calling it their lightest and most cost-efficient model. It is built for the work agents repeat all day: tool calls, coding subtasks, routing, extraction, and long-document parsing. It ships with a 1 million token context window, up to 512K output tokens, native multimodal input (text, image, audio, video), and pricing of $0.10 per million input tokens / $0.50 per million output tokens (cache reads at $0.004).

Artificial Analysis numbers put it level with Claude Haiku 5.5 on the Intelligence Index (score 36) while costing roughly a third as much per task (~$0.14 vs ~$0.41). It is hosted only via Meta Model API and Muse Code; no open weights.

That split — cheap execution model versus expensive planner — is the part that matters for anyone shipping tools that have to stay responsive.

Why the execution layer is the bottleneck

Most agent loops still look like this in practice:

1. Big model plans or decides the next high-level step.
2. Small/cheap model (or the same model again) extracts parameters, routes to a tool, or parses a result.
3. Tool runs.
4. Result is stuffed back into context.
5. Repeat until done or the budget dies.

When the loop is a coding agent or a research pipeline that can take minutes, the extra 200–800 ms of a larger model is noise. When the loop sits inside a live Windows overlay that must update on partial STT results under ~150–250 ms end-to-end, every extra model hop is visible.

A concrete latency budget for a dual-track interview or call helper looks roughly like this:

Stage	Typical cost
WASAPI shared-mode capture period	5–10 ms
Format convert + ring buffer	1–3 ms
Lightweight VAD / energy gate	2–5 ms
STT first partial (hosted or local)	35–100 ms
Routing / extraction model call	40–200 ms (depends on size and location)
Overlay paint	<16 ms

A model that is both cheap and competent at tool-calling and extraction lets you keep the routing step on the hot path without blowing the budget or the bill. Ember’s stated targets (tool calls, routing, extraction) line up with exactly that slot.

Practical routing pattern

You do not need a full multi-agent framework. A thin router that calls a small model works:

# Pseudocode for a latency-sensitive router
async def route_turn(partial_text: str, context: dict) -> dict:
    prompt = f"""You are a router for a live call overlay.
User said (partial): {partial_text}
Available tools: translate, summarize_last, extract_names, none
Return JSON: {{"tool": "...", "args": {{...}}, "confidence": 0.0-1.0}}"""

    # Call the cheap execution model (Ember-style)
    resp = await client.chat.completions.create(
        model="muse-ember-1.0",
        messages=[{"role": "user", "content": prompt}],
        max_tokens=150,
        temperature=0.1
    )
    return json.loads(resp.choices[0].message.content)

Tradeoffs worth measuring:

• Hosted only. No local GGUF fallback for Ember itself. If the network blips, the router fails. Pair it with a tiny local classifier (even a fine-tuned embedding + rules, or a 1–3B model) for the critical path.
• Multimodal is free extra capacity. You can feed a screenshot of the remote participant’s shared screen into the same call when you need visual extraction, instead of spinning up a second vision model.
• 1M context is useful for dumping a long transcript or a set of prior call notes, but first-token latency on long contexts still dominates. Keep the routing prompt short; dump the big context only when the planner needs it.
• Cache hits at $0.004/M make repeated system prompts cheap. Put the tool schemas and few-shot routing examples in the cached prefix.

Architecture sketch for a Windows overlay

[WASAPI loopback + mic] → ring buffers
        ↓
[STT partials] ───────────────┐
        ↓                     │
[Tiny local VAD/classifier]   │
        ↓                     │
[Ember-style router] ←────────┘  (tool call / extract / none)
        ↓
[Tool execution or local post-process]
        ↓
[Overlay update on dedicated thread]

The planner (larger model) runs asynchronously on a slower cadence — after a full turn, or when the user explicitly asks for a summary or suggested reply. The router stays on the partial path.

This is the same pattern Browser Use 1.0 is exploiting on the browser side (emit thin actions directly) and that local STT pipelines have been forced into for years: keep the hot path thin.

What to measure before you adopt it

1. End-to-end p95 from speech end (or partial threshold) to overlay paint, with the router in the loop.
2. Failure rate when the hosted endpoint is slow or returns malformed JSON (always parse defensively and fall back to “none”).
3. Cost per minute of live use at your actual token rates, not the benchmark per-task number.
4. Whether the multimodal path is actually faster than “screenshot → separate vision call”.

Ember is one more data point that the execution tier is becoming a distinct product category. The models that win that tier will be the ones that stay under the latency and cost budgets of the systems developers actually ship, not the ones that win the next leaderboard on planning.

I'm building Talkaside, a Windows app for job interviews and calls in another language.
Drafted with AI assistance from this project's code and logs.