Muse Spark Open: Meta's open-weight coding model lands in Microsoft Foundry and on your own GPUs

Meta's coding-focused open-weight model, Muse Spark Open, now appears in Microsoft Foundry Models, according to a Microsoft Foundry blog post dated October 15, 2026. Meta's developer documentation explains how to download the released checkpoints and serve them yourself with runtimes such as vLLM, SGLang, llama.cpp, Unsloth or MLX, or call the model through a hosted provider.

What Muse Spark Open is and where to get it

Microsoft's announcement describes Muse Spark Open as a model tuned for coding agents. These are agents that have to understand an existing codebase, work across many files and dependencies, call tools reliably and keep a long task moving. Being listed in Foundry Models means Azure customers can choose it from Microsoft's model catalog without running the GPUs themselves.

Meta also publishes the weights. Its documentation sits in a new "Open-weight models" section of the Meta Model API docs. The section has pages for getting the model, prompting, recommended settings, running inference, hardware platforms and post-training. The checkpoint names in those docs use the label "816B-A42B". Meta calls the model a mixture-of-experts design, which means only part of the network is active for each token.

The docs offer two main checkpoint formats: full-precision BF16 and a smaller NVFP4 version. Community builds are also listed, including GGUF files from ggml-org for llama.cpp and Unsloth Dynamic GGUFs.

Hardware needed to self-host Muse Spark Open

This is not a laptop model in its full form. According to Meta, the NVFP4 checkpoint runs with tensor parallelism across four NVIDIA B300 GPUs, and the BF16 checkpoint needs eight. The TensorRT-LLM path is aimed at a single four-GPU node on NVIDIA Blackwell hardware.

There are two lighter options. The MLX route targets Apple silicon and splits the model across two or four Mac Studio machines. Unsloth's quantized GGUF builds support local inference on macOS, Windows, Linux and WSL. Meta tells readers to check its checkpoint guide before buying or renting hardware.

The model can produce very long reasoning traces when set to higher reasoning strengths. Meta recommends streaming responses for those workloads so that long generations don't hit request timeouts. In the Transformers example, reasoning effort can be set to low, medium, high or xhigh, and xhigh is the default.

Supported runtimes: vLLM, SGLang, llama.cpp, Unsloth and MLX

Meta's inference page lists eight ways to run the model:

• SGLang and vLLM for production serving to many users at once, with BF16 and NVFP4 checkpoints
• TensorRT-LLM and NVIDIA Dynamo for optimized or disaggregated serving on NVIDIA hardware, NVFP4 only
• Hugging Face Transformers for research and custom Python pipelines
• llama.cpp for portable inference across Metal, CUDA, ROCm, Vulkan and CPU
• Unsloth for local use, with both OpenAI- and Anthropic-compatible HTTP endpoints
• MLX for clusters of Mac Studio computers

Most of these runtimes expose an OpenAI-compatible HTTP server, so existing tools that already talk to that API format should be able to connect. The vLLM example sets a maximum model length of 1,048,576 tokens. SGLang has a dedicated Docker image for the model, and Meta links speculative-decoding draft models for both SGLang and vLLM.

Who should pay attention

• Teams building coding agents that want a model they can host inside their own infrastructure, or pick from the Foundry catalog on Azure.
• Companies with data-residency or privacy rules that rule out sending code to a third-party API. Self-hosting is possible, but the GPU requirements are significant.
• Hobbyists with Apple hardware. The MLX and Unsloth paths are the most realistic options, though the full model still needs several high-end Macs or heavy quantization.

If you already run vLLM or SGLang, the quickest test is to pull the NVFP4 checkpoint and use Meta's sample command. If you don't have the hardware, Foundry or another hosted provider is the simpler route. Pricing for hosted access isn't covered here, so check the provider's own pricing page.

What Hacker News commenters are saying

The launch drew a busy discussion on Hacker News. Several commenters were glad to see a major lab release open weights, and some hoped other labs would follow. Others noted the work Meta put into supporting many runtimes, from Unsloth to MLX. One thread argued that open models like this weaken the case for paying premium prices for frontier APIs.

There were complaints too. One commenter said the license requires large inference providers to get a separate license from Meta before serving the model, and worried this could reduce price competition. Another raised the general risk of hidden backdoors in open-weight models.

Frequently asked questions

Is Muse Spark Open available in Microsoft Foundry?

Yes. A Microsoft Foundry blog post on October 15, 2026 says the model is available in Microsoft Foundry Models.

What hardware do I need to run Muse Spark Open?

Meta's docs list four B300 GPUs for the NVFP4 checkpoint and eight for BF16. Lighter options include MLX across two or four Mac Studios, or Unsloth's quantized GGUF builds.

Which inference engines support it?

SGLang, vLLM, TensorRT-LLM, NVIDIA Dynamo, Hugging Face Transformers, llama.cpp, Unsloth and MLX are all documented by Meta.

Can I use it with OpenAI-style tools?

Most listed runtimes serve an OpenAI-compatible HTTP API, and Unsloth also offers an Anthropic-compatible endpoint.