Muse Ember API Pricing: The 200K Context Limit That Changes Your Bill

Meta released Muse Ember on November 9 for repeated agent tasks, coding subtasks and document processing. Its API starts at $0.10 per million input tokens and $0.50 per million output tokens, but crossing 200,000 input tokens triples the rates for the entire request.

That detail matters more than the headline price if your agent keeps adding files, tool results and conversation history. A cheap model can still become an unnecessarily expensive worker when every small task arrives with the whole project's context attached.

Muse Ember pricing has two tiers

The Meta pricing documentation sets the tier using total input tokens, including cached input. Continuing a stored conversation with previous_response_id includes that conversation in the count. Above 200K, the higher rates apply to the whole request, rather than only the excess tokens.

Usage	Up to 200K input tokens	More than 200K input tokens
Uncached input, per million tokens	$0.10	$0.30
Cached input, per million tokens	$0.004	$0.012
Output, per million tokens	$0.50	$1.50

A cache hit lowers the bill, but it does not keep a request in the cheaper tier. Meta separately charges web search at $2.50 per 1,000 queries. Those charges need their own budget line.

A worked example near the boundary

Consider a hypothetical extraction worker with 180,000 cached input tokens, 20,000 uncached input tokens and 2,000 billed output tokens. It lands exactly at 200,000 input tokens, so its token charge is $0.00372: $0.00072 for cached input, $0.002 for new input and $0.001 for output.

Now add another 1,000 uncached input tokens, keeping everything else fixed. The request has 201,000 input tokens and costs $0.01146: $0.00216 for cached input, $0.00630 for new input and $0.003 for output. A 0.5% increase in input has pushed the token bill to a little over three times its previous size.

At 10,000 identical requests, those illustrative totals become $37.20 and $114.60, before tool charges or other costs. These are calculations from the published rates, not results from an API test. Real requests will vary in output length, cache hits and retries.

The useful engineering question is whether that extra context changes the answer. If it contains a necessary cross-document dependency, paying for it may be sensible. If it is old terminal output carried forward because nobody trimmed the session, the cost buys very little.

Context window, API access and reasoning settings

Muse Ember's model documentation lists a 1,048,576-token context window and a maximum output of 524,288 tokens. It accepts text, images, audio, video and PDFs, and produces text. The model ID is muse-ember-1.0; supported interfaces include Responses, Chat Completions and Messages.

The context capacity and the pricing boundary answer different questions. A request can fit comfortably inside the model's context window while already paying long-context rates. That makes a million-token limit a capacity option, not a recommendation to fill every call.

Meta lists reasoning effort from minimal to max, with max as the default. Set effort deliberately when comparing costs. A routing step that chooses between three queues and a difficult code repair should not automatically inherit the same reasoning configuration just because they use the same model.

For a first integration, the API overview specifies https://api.meta.ai/v1 as the base URL and bearer-token authentication. Use a dedicated test workload before replacing a production model. An API-compatible request format does not establish equivalent tool choices, failure handling or output quality.

Should Muse Ember replace Claude Haiku 5.5?

Artificial Analysis's launch evaluation gives Ember at maximum effort an Intelligence Index score of 36 and an average benchmark task cost of $0.14, against Haiku 5.5's 36 and $0.41. That is a useful reason to evaluate it, not a promise that your application will cost one-third as much.

The same evaluation shows an uneven coding comparison. Ember leads on Terminal-Bench 4.0, 40.9% versus 32.8%, but trails on FrontierCode 2.0, 27.2% versus 34.9%. Artificial Analysis also reports that Ember declines to answer 64% of its AA-Omniscience questions. A system that supplies the evidence for an extraction task has different needs from one that expects the model to answer broad knowledge questions unaided.

Replace a workload after measuring it, not a model because its average score matches. For a support-ticket worker, compare correct routing, missing evidence, invalid outputs, retries and the cost of escalation. A cheaper first attempt that repeatedly needs a stronger model can erase its own advantage.

Keep the worker's context smaller than the planner's

A practical starting design is to let the planning step decide what needs doing, then send Ember the bounded evidence required for each task. For example, an invoice-checking worker usually needs the invoice, relevant purchase-order fields and validation rules. It should not receive every earlier customer conversation unless the decision actually depends on them.

Track total input, cached input and output separately, along with success and escalation. Put an application-level warning below the 200K boundary so ordinary growth does not silently change the cost profile. Keep essential evidence intact when shortening a request; splitting documents blindly can lose the relationships the task needs.

There is a real opportunity here for inexpensive execution, especially when the same verified procedure repeats across many records. The teams that benefit most will be the ones that can define what each worker needs to know and what a correct result looks like. A lower token price makes that discipline more valuable because it makes running the workflow many more times affordable.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn model capabilities, engineering decisions and product launches into clear stories developers can use and share.

Book a 30-minute call.