Meta’s own Model API documentation is refreshingly blunt about its newest release. For Muse Spark Open, the docs state: “You don’t call it over Model API.” Instead, you download the weights and run them yourself. That one line tells you more about who this model is for than any launch announcement could. Meta isn’t selling you a service here. It’s handing you a very large box of parts and trusting you to have the workshop to assemble them.
As someone who spends most of the week testing AI toolkits to see what actually holds up outside a demo, I find that framing honest. It’s also a warning label, and it’s worth reading before you get excited.
What Meta actually shipped
On October 15, 2026, Meta Platforms released Muse Spark Open, an open-weight version of its Muse Spark model, aimed at coding and AI agents. The confirmed specs:
- 816 billion total parameters
- 42 billion active parameters, using a mixture-of-experts design
- Downloadable weights that developers can modify
- Support for serving through SGLang, vLLM, TensorRT-LLM, or llama.cpp
- An option to skip self-hosting and use a hosted inference provider instead
Open-weight means the trained parameters are available for you to take, adapt, and deploy. It is pitched as a lower-cost alternative to closed systems, and for the right team that pitch holds up. For the wrong team, “lower cost” can turn into an expensive weekend.
The number that matters is 42, not 816
Headlines will lead with 816 billion parameters because big numbers travel well. The figure I care about as a reviewer is the 42 billion active parameters. In a mixture-of-experts model, only a slice of the network fires for any given token. That makes inference far more practical than the total count suggests, since you’re not pushing every token through the entire model.
The catch is that all 816 billion parameters still have to live somewhere. Active parameters help with compute per token. They don’t shrink the memory footprint of the full set of weights. So this is not a model you casually spin up on a gaming laptop to autocomplete your side project. The llama.cpp listing will tempt hobbyists, and quantization may make some setups possible, but I haven’t tested that yet and I’m not going to promise anything I haven’t run.
A sensible runtime list
The supported runtimes are the right ones. SGLang and vLLM are the workhorses of production serving. TensorRT-LLM is the obvious pick for teams already committed to NVIDIA tooling. llama.cpp covers the local, tinker-friendly crowd. Meta isn’t inventing a proprietary serving stack and asking you to learn it. It’s meeting developers on tools they already use, and that counts for a lot when you’re deciding whether to adopt something.
The hosted inference option is the quiet but important part. Plenty of teams want the freedom of open weights without the burden of running GPU clusters. Being able to start on a hosted provider and move in-house later is real flexibility, not marketing copy.
The strange backstory
The release lands with some odd context. Earlier coverage around Muse Spark carried headlines like “Meta Launches Muse Spark, Its First Proprietary AI Model” and “Meta Just Went Closed Source,” framing the original model as a turn away from Meta’s open-model reputation. An open-weight version of that same model complicates the story.
My read is that Meta wants it both ways: a proprietary product for its own platforms and an open release that keeps developers building on its ecosystem. That’s not a criticism. It’s a fairly pragmatic split. But anyone who wrote Meta’s open-model obituary may want to revise it.
Who should care, and who shouldn’t
Based on what’s confirmed so far, here’s how I’d sort potential users:
- Good fit: teams building coding assistants or agent pipelines that need to fine-tune, inspect, or keep data on their own infrastructure.
- Good fit: companies already running vLLM or SGLang at scale who can absorb a large model into existing serving setups.
- Maybe: startups curious about open weights but short on hardware. Start with a hosted provider and measure before committing.
- Poor fit: solo developers expecting a lightweight local model. The size alone makes this a serious infrastructure decision.
What I still need to see
Meta hasn’t given me benchmark numbers I can verify, and I won’t repeat claims I can’t check. The questions that will decide whether this earns a spot in anyone’s toolkit are practical ones. How well does it handle multi-step agent tasks without wandering off? How does code quality hold up on messy, real repositories rather than tidy test problems? What does serving it actually cost per request once you factor in hardware?
Those are the tests I’ll be running. For now, Muse Spark Open looks like a serious release with a sensible deployment story and a clear target audience: builders who want control and have the infrastructure to back it up. Meta has handed over the keys. Just make sure you have a garage big enough to park it.
🕒 Published: