What changed
Meta now exposes separate standard and contributor model IDs for Muse Spark 1.2 and Muse Code. The contributor tier is described in official pricing documentation as heavily discounted token pricing in exchange for permission to use prompts and completions to train future Meta models.
Why it matters
This turns data-governance policy into a direct unit-economics choice. Builders handling proprietary code, customer content or confidential business data cannot evaluate the contributor tier on price alone; the training-use permission changes the risk profile of the same inference workload.
The discount is tied to a different data-use bargain
Meta's Model API documentation distinguishes standard model IDs from contributor IDs and states that the contributor tier trades lower token pricing for permission to use prompts and completions in future model training. This is not merely a promotional discount on otherwise identical contractual terms.
The practical decision is workload-specific
Public or synthetic evaluation workloads may tolerate contributor terms that would be unacceptable for proprietary repositories, customer support transcripts, regulated information or unreleased product plans. Teams should classify traffic by data sensitivity rather than setting one global default.
Coding use raises the stakes
Muse Code and Muse Spark are positioned for coding and developer workflows, where prompts may contain source code, credentials accidentally pasted by users, internal documentation or customer-specific context. Price routing therefore needs to sit behind data-loss prevention and policy controls, not just an SDK switch.