Muse Spark 1.2 Contributor: Cheap Tokens, Paid For With Data

Muse Spark 1.2 Contributor is not a smaller or weaker model. It is Muse Spark 1.2 under a different contract. You get the same weights, the same 1M-token window and the same multimodal input at a price low enough to change what you would bother automating. In return, Meta may train future models on your prompts and completions.

That makes it one of the few model choices where the deciding question belongs to whoever owns your data policy rather than whoever owns your eval suite.

Same weights, different contract

Meta introduced the contributor tier alongside 1.2 on 5 August 2026, under its own model id, muse-spark-1.2-contributor. Meta later announced the tier was expanding globally, describing it as the same model with the same 1M context and multimodal input, at its lowest prices.

Meta's model documentation draws the line in one sentence: standard mode content is not used to train Meta models, while contributor mode content may be used to train future Meta models in exchange for a lower price. Nothing about capability differs. If your eval passes on muse-spark-1.2, it should pass on the contributor id too.

The discount, worked through

Prices per million tokens at the time of writing, as listed on OpenRouter and in reporting on Meta's own rates:

• Standard — $1.25 input, $0.15 cached input, $4.25 output
• Contributor — $0.10 input, $0.002 cached input, $0.20 output

That is 12.5 times cheaper on input and over 21 times cheaper on output. Take an agent run that reads 2 million input tokens and writes 100,000 output tokens, with no caching. On standard it costs about $2.93. On contributor it costs about $0.22.

Across a team running a few hundred of those a day, the difference is the gap between a budget line someone has to approve and one nobody notices. It is also why the tier exists: Meta is buying training data, and the discount is the price.

What you agree to, and what is unwritten

The documented condition is permission to use your prompts and completions to train future Meta models. As of the reporting we could find, several things a privacy review would ask about are not documented:

• how long contributor data is retained
• whether humans review it
• whether you can delete or revoke it after submission
• whether file attachments, tool-call arguments and tool results count as prompts

The last point is the one that bites agent workloads. In a coding loop the sensitive material rarely sits in your instruction. It arrives in tool results: the file contents the agent read, the environment variables a command printed, the stack trace with a customer's email in it. Assume all of that is in scope unless Meta says otherwise in writing.

Standard-tier traffic is not used for training, but it is still processed and retained by Meta under its normal terms. The contributor tier adds a use; it does not replace the baseline. PII in prompts covers how personal data ends up in a request without anyone choosing to put it there.

The rate limit is the other catch

Third-party reads of Meta's pricing page put the 1.2 contributor tier at 60 requests per minute and 2.1 million tokens per minute per team, against 3,000 requests per minute on standard. Check the current figures on Meta's pricing page, since they were reported rather than confirmed directly.

Even if they have moved, the shape matters. A cheap tier with a low request ceiling suits one developer, a batch job, or a small prototype. It does not suit a parallel agent fleet, where a few dozen sub-agents firing tool calls will hit the ceiling in seconds and spend their time in retry backoff. Work out which limit binds first, requests or tokens, before you design around the price.

Workloads that fit, and ones that do not

A reasonable split:

• Fits: open-source contributions, public documentation, synthetic test data, learning and personal projects, generating fixtures from public schemas, evaluating Muse Spark before committing to the standard tier.
• Does not fit: client code under NDA, proprietary source, credentials or anything an agent might read from a .env file, regulated personal data, and anything covered by a processing agreement that restricts training use.

The grey zone is internal code that is not secret but is not public either. Default it to standard. The saving on a single repository is rarely worth a conversation with legal after the fact.

Enforce it at the gateway, not in a wiki

The tier is selected by a model id string. Nothing in the request body changes, so data-loss tools inspecting content will not notice when someone swaps muse-spark-1.2 for muse-spark-1.2-contributor to save money. A policy page will not stop that; a rule in your proxy will.

1. Block every id ending in -contributor by default at your LLM gateway.
2. Allow it per project, with a named owner, for workloads that meet the fit list above.
3. Log the model id on every request so an audit can show which traffic went where.
4. Revisit when Meta publishes retention and deletion terms.

If you are already on the contributor tier and want the newer model, Muse Spark 1.3 Contributor carries the same data terms with a few differences in what it supports. Proxying LLM traffic covers building the gateway rule itself.