Meta launched Muse Ember, a lightweight multimodal model priced from $0.10 per million input tokens, according to The Defiant. It is available through the Meta Model API and Muse Code. The Defiant's summary says it handles repeated agent tasks while larger Muse models plan the work.
That last sentence is the real story. The price is a number. The division of labor is a design pattern, and it is the one most production agents end up with anyway.
What was actually announced
Here is what the source supports, and nothing more:
- ▸Model: Muse Ember, described as lightweight and multimodal.
- ▸Price: starts at $0.10 per million input tokens. "Starts at" means there is more than one number on the card.
- ▸Where: the Meta Model API and Muse Code.
- ▸Role: repeated agent tasks, with larger Muse models handling the planning.
What the article does not give us: an output-token price, context length, benchmarks, the names of the larger Muse models, or a launch-date breakdown. We also could not find a second source confirming the model's specs while writing this. So treat everything beyond the list above as unknown, not as zero, and read Meta's own pricing page before you put a number in a budget.
Why "planner plus worker" is the part to notice
Most agent loops are lopsided. One hard decision (what should I do, in what order, with which tool?) is followed by many small, boring ones: parse this response, fill this field, call this endpoint again, check this result. Paying planner prices for every boring step is how a demo that cost pennies becomes a bill that costs real money.
Splitting the loop is the obvious fix: a bigger model plans, a cheap one executes. Meta shipping a model explicitly positioned for the executor seat says the big labs see the same shape you do. The prompt is the cute part. The loop is where the cost lives.
What this means if your agent touches money
Onchain agents add a wrinkle. The repetitive work is often the sensitive work: reading balances, formatting a transaction, retrying a failed call. A cheap, fast executor is attractive there. It is also exactly where you want hard limits that do not depend on the model behaving.
So if you route repeated tasks to a lighter model, put the guardrails outside the model:
1. Spend limits at the wallet, not in the prompt. If an agent can move funds, "the model is careful" is not a control. 2. Unsigned objects for anything irreversible. Let the cheap model prepare a transaction; let a policy layer or a human approve it. 3. A checked tool list. Know which MCPs and skills the executor can reach, and whether each one is open, active and maintained. 4. Logs you can replay. If the planner and the worker disagree, you want to see which one drifted.
None of that is Meta-specific. It is the stack. A cheaper model makes it easier to run more steps, which makes the guardrails matter more, not less.
Claimed versus shown
The launch says Muse Ember is built for repeated agent tasks. That is a claim about intended use. Whether it holds up on your tool-calling workload, in your format, with your failure modes, is something you only learn by running it. Cheap input tokens do not help if the executor needs three retries where a bigger model needs one. Measure cost per completed task, not cost per token.
A fair test for any executor model:
- ▸Pick the five most repeated steps in your agent loop.
- ▸Run them on the lightweight model and on your current one.
- ▸Compare completion rate, retries and total cost per finished task.
- ▸Only then move the step over.
Where Sato fits
Sato Hub maps the stack around the model: skills, MCPs, wallets, payment rails and frameworks, with the Sato Score as a transparency and liveness signal. It is not a safety or quality grade, and it says nothing about how any given model performs. What it does give you is a place to check what your executor will be calling before you hand it a wallet. Describe the agent you want and Sato maps the stack.
What to watch
- ▸The rest of the price card. Output-token and cached-input pricing decide what a real agent loop costs. The headline number is only the floor.
- ▸Which larger Muse models plan. The pairing only works if the planner is good and the handoff is clean.
- ▸Tool-calling behavior in practice. Independent results from builders running repeated agent tasks will say more than a launch post.
- ▸Whether other providers match the pattern. If every lab ships a cheap executor next to a planner, the multi-model loop becomes the default architecture rather than an optimization.