Muse Spark Open is Meta's open-weight model for coding and agentic work, with 816B total parameters, 42B active per token and a 1M-token context. You can run it inside your own cloud account, but it needs a large GPU node, an always-on endpoint and a licence with real obligations. Price that before you plan a switch.
What was released
Muse Spark Open was released by Meta on 15 October 2026, according to the Muse Spark Open model card in Meta's verified Hugging Face organisation. On the same day AWS announced it was available in Amazon SageMaker JumpStart. It joins Meta's Muse family, which already includes Muse Spark 1.1, announced in July 2026.
What the model is
The model card describes a mixture-of-experts reasoning model built for coding and agents:
- Size: 816B total parameters, 42B active per token, with 256 experts of which 8 run for each token.
- Context: a 1M-token window at inference, aimed at reading large codebases in one pass.
- Inputs: text, image, video and audio in; text out. AWS lists screenshots and bug-report recordings turned into reproduction plans as a use case.
- Reasoning effort: defaults to xhigh, and Meta recommends high or xhigh for complex tasks.
- Weights: a BF16 build and an NVFP4 quantised build, both gated behind an access form.
- Runtimes: SGLang, vLLM, Transformers, TensorRT-LLM, Unsloth and llama.cpp, plus community quantised builds for Ollama and LM Studio.
Meta also says the open-weight version has extra safety post-training and recommends deploying it with system-level guardrails, so it is not meant to be dropped in front of users unwrapped.
What it takes to run
The hardware is the first filter. The model card gives a floor of 700GB of GPU memory for the NVFP4 weights and 2TB for BF16. On SageMaker JumpStart that maps to one ml.p5e.48xlarge instance for NVFP4 and one ml.p6-b300.48xlarge for BF16, and at launch only the US East (N. Virginia) and US East (Ohio) Regions were listed. You need a service quota for those instances before you can deploy at all.
AWS points out the cost trap directly: an endpoint is billed for as long as it runs, whether or not it serves a request. That is the opposite of per-token pricing on a hosted API. A coding assistant that a team uses during working hours still pays for the night unless you delete the endpoint and wait for a fresh deployment when it is needed again.
What you get in return is control. The endpoint can run in your own VPC, with a KMS-encrypted volume and network isolation, and it speaks an OpenAI-compatible chat format, so code that already calls a chat-completions API needs a new endpoint and auth rather than a rewrite. Responses include the reasoning text and reasoning token count, which you should log and cap.
The licence terms that matter for products
The weights come under the Muse Model License, and three clauses change product decisions:
- Every product or service built on it must show "Built with Muse Spark Open" in the interface, documentation, website or settings.
- A model trained or distilled on its outputs counts as a derivative, so it carries the same licence. That matters if you planned to use it to generate training data for a smaller in-house model.
- Offering it to third parties as an API above a revenue threshold set in the licence needs a separate agreement with Meta first. Internal use and ordinary commercial products are outside that clause.
The usage policy also puts the duty to make end-user deployments safe on you and rules out users under 18.
When it makes sense, and when not to switch
In our view it is worth evaluating if source code cannot leave your cloud account, if your agents work across large repositories where the long context earns its keep, or if your usage is heavy and steady enough to keep a dedicated node busy. For those teams the practical first step is the NVFP4 build, which AWS suggests trying first because it needs roughly a quarter of the BF16 memory, measured on your own repository tasks against the hosted model you use today.
Stay on a hosted model if usage is bursty, if you have no one to own GPU capacity, quotas and upgrades, or if your data must stay in a Region where the model is not yet offered. Run the same evaluation set on both before deciding, and keep your existing provider as a fallback. Our guide to running an AI agent on a self-hosted model covers the operating work that comes with the move, and controlling AI agent running costs covers the budgets to set either way.
Frequently asked questions
What is Meta Muse Spark Open?
Muse Spark Open is an open-weight model from Meta Superintelligence Labs, released on 15 October 2026. It is a mixture-of-experts reasoning model with 816B total and 42B active parameters, a 1M-token context and text, image, video and audio input. Meta built it for coding and agentic work, and the weights are on Hugging Face behind an access form.
Can I run Muse Spark Open on AWS?
Yes. AWS added it to Amazon SageMaker JumpStart on 15 October 2026 in BF16 and NVFP4 versions. You accept the licence, pick an instance type, and deploy an endpoint into your account. At launch it was listed in the US East (N. Virginia) and US East (Ohio) Regions, and you need a quota for the large GPU instances it uses.
How much hardware does Muse Spark Open need?
Meta's model card gives at least 700GB of GPU memory for the NVFP4 weights and at least 2TB for BF16. On SageMaker that means one ml.p5e.48xlarge instance for NVFP4 or one ml.p6-b300.48xlarge for BF16. The endpoint is billed for as long as it runs, so idle time costs the same as busy time.
Do I have to credit Meta if I use Muse Spark Open?
Yes. The Muse Model License requires each product or service that uses the model to display "Built with Muse Spark Open" in its interface, documentation, website or settings. Models trained or distilled on its outputs count as derivatives and fall under the same licence, and offering it to others as an API above a set revenue level needs a separate agreement with Meta.
Should we move our coding agent from a hosted model to Muse Spark Open?
Only after testing it on your own tasks. It suits teams whose code cannot leave their cloud account, or whose steady usage keeps a dedicated GPU node busy. If usage is bursty or nobody can own the infrastructure, a hosted model is usually simpler and often cheaper. Start with the NVFP4 build and keep your current provider as a fallback.
