TECH NOTE
Meta Muse Spark 1.3 and the Contributor tier: the discount is paid in training data
Meta released Muse Spark 1.3 on 2 September 2026 with a model trained to ask before it acts, and kept a Contributor tier that costs a fraction of Standard in exchange for training on your prompts and completions. The behaviour is the better story. The pricing is the one that needs a policy.
Meta released Muse Spark 1.3 on 2 September 2026. The headline change is behavioural: in Meta's words, the model "asks clarifying questions when prompts are ambiguous, invokes help from the user when stuck, and confirms before taking consequential actions." It is available in Muse Code, Meta's coding tool for macOS and Linux, and through the Meta Model API.
The detail that deserves more attention sits on Meta's pricing page. Muse Spark 1.3 is sold in two tiers. One of them is priced at a small fraction of the other, and the difference is not speed or quality. It is whether Meta may train future models on what you send.
What Meta shipped
The model itself is an incremental release with a clear direction. Meta describes 1.3 as tuned for agentic workflows, meaning multi-step tool use, browser tasks and long-horizon work, with improved coding over 1.2. On coding specifically, Meta says that relative to Muse Spark 1.2 it uses "~20% fewer tool calls and ~25% fewer tokens". The context window is 1,048,576 tokens.
The collaboration behaviour is the part I will come back to, because it changes how you design around the model. First, the pricing.
Two tiers, one model name apart
Meta's own Model API documentation lists both tiers side by side.
| Standard | Contributor | |
|---|---|---|
| Input, per million tokens | $1.25 | $0.10 |
| Cached input, per million tokens | $0.15 | $0.002 |
| Output, per million tokens | $4.25 | $0.20 |
| Requests per minute | 3,000 | 100 |
| Tokens per minute | 4,000,000 | 3,000,000 |
| Training on your data | Not used to train Meta models | Permission to train future Meta models |
Worked through, Contributor is 12.5 times cheaper on input, about 21 times cheaper on output and 75 times cheaper on cached input. The documentation is explicit about the trade. The Standard tier states that "your prompts and completions are not used to train Meta models". The Contributor variant, as Meta's models page puts it, "trades a lower price for permission to train on your prompts and completions".
The tier is not new. Meta's models page also lists a muse-spark-1.2-contributor
variant, and VentureBeat noted that Meta "retains its unusually cheap
Contributor tier" with 1.3, adding that it "creates a materially different
data-governance calculation for enterprises working with proprietary code or
sensitive internal information." It is also not confined to Meta's own API.
OpenRouter lists meta/muse-spark-1.3-contributor as a model in its own right,
which means a team using an aggregator can select it without ever visiting
Meta's pricing page.
The discount is a data term
For most of the short history of these APIs, the price of inference has had two variables: how many tokens, and at what rate. Muse Spark adds a third. What happens to your data afterwards is now priced, and the price difference is large enough that it will be noticed by anyone looking at a bill.
Credit where it is due: Meta has not hidden this. The terms are on the pricing page, in plain language, next to the numbers. The risk is not deception. It is drift.
Picture how this goes wrong in a real organisation. A developer is asked to cut the cost of an internal assistant. They benchmark the options, find a tier that is more than twenty times cheaper on output, and change one string in a configuration file. The capability is presented as the same model. The tests pass. Nothing in the application changes, except that every prompt it sends, including whatever documents, tickets or code the assistant retrieved into its context, is now licensed for training.
With a context window of over a million tokens, the prompt is often not a question. It is the question plus the entire contract, the whole module, or a week of support tickets. The data term applies to all of it.
The rate limits tell you who Contributor is really for. One hundred requests per minute is a prototyping ceiling, not a production one. I think that is a deliberate signal and a fair one: this is the tier for experiments, evaluation runs and public code, not for systems handling other people's information.
What I would check before anyone picks the cheaper tier
None of this requires a new process. It requires treating the model identifier as the data decision it now is.
- Allowlist model identifiers at the gateway. If requests to model providers pass through a proxy or gateway, block contributor variants by default for any workload that can see client or personal data. Make using one an explicit exception with a named owner.
- Search for them. Grep configuration, environment files and code for
-contributor. Include aggregator configuration, where the variant appears as a separate model entry rather than a setting. - Classify the prompt, not only the output. Ask what actually ends up in the context window: retrieved documents, code, customer records. That is the material the training permission covers.
- Write the decision down. Whether client data may be used to train someone else's model is a question for your contracts and your data protection obligations, including PDPL here in Saudi Arabia. It should be answered in writing before a developer answers it in a config file.
- Use Contributor where it genuinely fits. Synthetic data, public benchmarks, open-source code, throwaway prototypes. There is a legitimate use for a cheap tier, and pretending otherwise just pushes people to use it without asking.
For the kind of work I build at MyAdvisor.ai, where the prompt is frequently a client's legal document, the answer is no before the price is even read. The principle I apply there, no source, no claim, has a data-side counterpart: no licence you have not decided to give.
Asking before acting is a behaviour, not a control
Now the part of the release I think matters more over time.
A model trained to ask clarifying questions when a prompt is ambiguous, to ask for help when stuck, and to confirm before consequential actions is a better component for agents. The most expensive agent failures I think about are not wrong answers. They are confident actions taken on a misread instruction. A model that pauses at the right moment removes a whole class of those.
Two cautions, though.
The first is that "consequential" is now a judgement the model makes. It will sometimes judge wrong, and it can be pushed to judge wrong. Meta says 1.3 has "improved resistance to adversarial inputs and prompt injections", which is welcome, but improved resistance is not immunity. The decision about which actions need confirmation should still be enforced in the tool layer, where a payment, a deletion or an outbound email simply cannot execute without an approval that the model does not control. I made the longer version of this argument in production agents: the model's good behaviour is a bonus, and the permissions model is the guarantee.
The second is that an agent which asks questions needs somewhere to ask them. An unattended background job that suddenly wants clarification will stall unless you have designed for it: a channel for the question, a timeout, and a defined fallback. The protocol layer is moving in the same direction. The recent MCP specification added a way to request a mid-call user confirmation without holding a stream open. Models that ask and protocols that can carry the question are two halves of the same design, and your application has to supply the third: a person who can answer.
What I would watch next
The first thing is whether Meta publishes more about what training permission involves in practice. The documentation I read is clear about the permission itself. It does not say how long contributed data is retained, whether it is de-identified, or whether a customer can withdraw it later. Those are the questions a data protection review will ask.
The second is whether other providers start pricing a data term explicitly. If they do, the model identifier becomes a governance object across the whole industry, and gateways will need to label tiers by their data terms rather than by model name alone.
The third is whether the clarifying-question behaviour survives contact with real agent workloads, or gets tuned down because users find the questions annoying. The value of a model that asks before acting depends entirely on it asking at the right moments, and that is something you can only measure on your own tasks.