Muse Ember: Agent Workflows, API Pricing, and the 200K Cost Threshold

Meta Muse Ember targets repeated agent work. Understand its direct API, standard and long-context pricing, and when to keep a larger planning model.

Muse Ember: Agent Workflows, API Pricing, and the 200K Cost Threshold

An agent that classifies a thousand records or executes a queue of small coding tasks needs a different cost model from an assistant answering one difficult question. Muse Ember, announced by Meta on November 9, 2026, is aimed at that repeated execution work. Its low headline price is interesting, but the 200K-input threshold is just as important: above that boundary, the higher rate applies to the whole request.

Key takeaway

  • Meta documents muse-ember-1.0 as the direct API model ID for Muse Ember.
  • Standard pricing up to 200K input is $0.10 input and $0.50 output per million tokens.
  • Above 200K input, those rates become $0.30 and $1.50 for the entire request.
  • Ember is intended for bounded agent work; Meta points to Spark or Wonder for harder single-shot coding and other demanding tasks.
  • The November 13 SandBase catalog search did not find an exact Ember listing. A Meta API example is not a SandBase integration claim.

The analysis below uses official documentation checked November 13. It includes hypothetical cost arithmetic and a suggested evaluation design, not measured throughput or model-quality results.

The role Meta gives Ember

Meta’s announcement and model documentation describe an efficient execution model for repeated tasks: routing, extraction, tool calls, and focused work delegated by a larger model. That is a useful product position when many small requests dominate the total bill.

Meta's Muse Ember model documentation Meta’s model page captured November 13 establishes the documented identifier and feature surface. It does not establish the success rate of an application built on it.

A practical example is an issue-triage queue. Each request receives one issue, a short repository description, and an allowed label schema. The output must select a label and cite the evidence used. A more capable model can handle ambiguous cases after the worker explicitly reports uncertainty. This is an application design proposal, not a claim that Ember has been tested on that queue.

The split works only if delegation saves more than it costs. Passing an entire conversation to every worker, asking the worker to reconstruct the plan, and then requiring a larger model to rewrite every answer can erase the expected saving. Start by making the task package small and the acceptance contract explicit.

Documented capabilities and boundaries

ItemMeta’s documented value
API model IDmuse-ember-1.0
Context window1,048,576 tokens
Maximum output524,288 tokens
InputsText, images, video, audio, PDF
OutputText
ReasoningMinimal through max; default max
API formatsResponses, Chat Completions, Messages
Model API modeStandard only; no Contributor variant

A maximum output allowance should not become the default budget for every queue item. A classification request should return a small validated object. A coding task may require more room, but its budget should reflect the expected artifact and the consequences of truncation.

The default reasoning setting also deserves an explicit choice. A high-volume workload should test whether additional reasoning improves its acceptance rate enough to justify the time and output usage. Neither the lowest setting nor the default is automatically the economical choice.

Meta’s documentation recommends Spark or Wonder for the hardest single-shot coding, knowledge-heavy questions, and visual coding. That does not prohibit evaluating Ember on them; it means the vendor itself does not frame Ember as the universal best model for every task.

Pricing has a discontinuity at 200K input

The official pricing and rate-limit page lists these per-million-token rates:

Input lengthUncached inputCached inputOutput
Up to 200K$0.10$0.004$0.50
Above 200K$0.30$0.012$1.50

The threshold includes cached input and stored conversation history. Crossing it changes the rate for the entire request, not just the portion above 200K. Web grounding has separate query charges, so it must be budgeted separately when used.

For 10,000 uncached input tokens and 2,000 output tokens, the illustrative model-only cost is:

10,000 / 1,000,000 × $0.10 + 2,000 / 1,000,000 × $0.50 = $0.002

At 210,000 uncached input tokens and the same 2,000 output tokens:

210,000 / 1,000,000 × $0.30 + 2,000 / 1,000,000 × $1.50 = $0.066

These are calculations, not actual invoices. They exclude tools, retries, and any other service charges. The difference illustrates why forwarding a large history can change the economics even when the requested answer remains short.

Do not remove essential evidence merely to stay below a pricing threshold. Instead, separate independent jobs, retrieve relevant material, and make any summarization policy visible in the evaluation. A cheaper request that loses the detail needed to make the right decision is not a saving.

Cloudflare also documents a Muse Ember route. Its provider page is useful for integration discovery, but use the chosen route’s own terms and billing rules rather than assuming every platform charges identically.

Cloudflare's Muse Ember provider page Cloudflare’s model page captured November 13. This is another documented access surface; the full long-context rules above come from Meta’s pricing documentation.

A direct Meta request, with the provider boundary visible

The following request follows Meta’s Responses example. It is a documented starting point, not a command executed for this article. MODEL_API_KEY must be a Meta key, not a SandBase key.

Shell
curl --fail-with-body https://api.meta.ai/v1/responses \
  -H "Authorization: Bearer $MODEL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "muse-ember-1.0",
    "input": "Classify this ticket as billing, bug, or feature request. Give one sentence of evidence: I was charged twice for October."
  }'

Before putting it in a worker queue, add bounded retries, timeout handling, schema validation, and accounting for failed attempts. A successful request returning text proves connectivity; it does not prove that the label is correct or that a more complex tool workflow is safe to repeat.

Model API billing is also separate from a Muse Code subscription. Keep the chosen product surface in the cost report so that an included subscription allowance is not confused with a generally available API discount.

What to delegate, and what to keep on the main loop

WorkCandidate assignmentVerification
Ticket routing or field extractionEvaluate Ember on bounded inputsSchema plus labeled reference cases
Narrow code editWorker with a small file/task scopeTests and review of the diff
Tool-driven lookupWorker with explicit stop conditionsEvidence and tool-result provenance
Ambiguous architectural decisionKeep a proven reasoning model initiallyHuman review and downstream consequences

For a coding worker, require the actual changed files and test results. A polished summary is not a substitute for an artifact. For extraction, require the source span or document location so an error can be audited without repeating the whole workflow.

Run the same examples through the incumbent model and compare cost per accepted output. Include difficult negatives: an issue with missing facts, a record that does not fit the labels, and a tool response that arrives empty. The correct behavior may be escalation rather than a confident guess.

For a currently listed alternative, inspect GPT-6 Luna on SandBase. Luna is a different model, not an Ember route. The card provides a place to evaluate an existing option while Ember’s SandBase integration remains unverified.

SandBase's GPT-6 Luna card The Luna card captured November 13 is an alternative access path, not evidence of Muse Ember availability through SandBase.

For another approach to fast execution alongside a larger model, read our Gemini 4 Hydrogen guide. For Meta’s developer tooling context, see Muse Code in the terminal.

A queue needs application-level safeguards

A repeated worker should have a stable job identifier and an explicit distinction between proposing an action and executing it. If a request times out after a tool has written a change, the next attempt must inspect the external state before repeating the write. Model selection does not supply this idempotency automatically.

Also set a maximum number of tool steps and an escalation condition. For Ember’s intended high-volume work, a small fraction of looping jobs can dominate both cost and operator attention. Report those jobs separately from ordinary successful requests; averaging them away hides the operational problem.

Keep the original input, structured result, and verification outcome together. That record lets the team discover whether errors cluster around ambiguous labels, long history, or a particular tool response. Increase traffic only after those failure classes have a clear handling path.

FAQ

Is Muse Ember open-weight?

The sources reviewed establish hosted API access. This article did not verify a downloadable Ember weight release; do not infer one from Meta’s other model families.

Is $0.10/$0.50 the price for a million-token request?

No. Those rates apply up to 200K input. Above the threshold, Meta documents higher rates for the entire request.

Does cached history count toward the threshold?

Yes. Meta’s pricing documentation includes cached input and stored prior conversation in the threshold calculation.

Should every agent step move to Ember?

Only after evaluation. It is a plausible candidate for repeated bounded work, but the extra planning, retries, and review required by the surrounding application determine the actual saving.

Next step: choose one queue, cap its task scope, and measure acceptance and total cost together before increasing traffic.

Found this useful? Share it