Meta’s new model can work across code, images, audio, and video, but local use requires exceptional memory.
Meta has released Muse Spark Open, an open-weight model built for developers creating multimodal coding agents. It can read code, inspect images, process audio and video, write and debug software, and call tools while working through longer tasks, according to release materials published through Hugging Face.
That makes the release relevant to practical artificial intelligence development, not just model size. Developers can use one model interface for a screenshot of an error, a voice explanation, a screen recording, and the code changes needed to address the problem.
The release is an announcement with implementation and deployment recipes. Meta and NVIDIA report performance advantages, but the supplied reporting does not independently verify its accuracy, speed, cost per token, or standing against competing models.
A model built for long coding tasks
Muse Spark Open has approximately 816 billion total parameters, with about 42 billion active for each token. Parameters are learned values inside a model; they help determine how it processes inputs and produces outputs.
The model uses a mixture-of-experts design. It contains 256 expert networks in each layer, while a routing system selects eight experts for each token. This means the model calculates only part of its network for each step, rather than using every expert every time.
That does not make the model small. All 256 experts must remain in memory, so deployment still needs memory for the complete 816-billion-parameter model. The standard BF16 checkpoint is about 1.5 terabytes, according to Hugging Face.
Muse Spark Open also supports a context window of up to one million tokens. A context window is the amount of input and conversation a model can consider at once. For coding agents, that could provide room for large codebases, dependencies, test results, and earlier actions in one session.
The model’s release materials describe an agent that plans, acts, observes results, and self-corrects. In ordinary terms, it is aimed at software work that involves several steps: reading a repository, changing multiple files, running tools, responding to failures, and trying again.
What hardware does it need?
Serious server deployment depends on the model format and the software used to serve it. Meta’s documentation says the BF16 version runs across four nodes, each with eight H200 graphics processors. Its NVFP4 version uses four-bit parameters and is designed for NVIDIA Blackwell hardware; the documentation lists a single B200 node for a Transformers deployment.
Other supported serving systems use different arrangements. Hugging Face documents an NVFP4 setup for SGLang across four GB300 GPUs. Its vLLM example uses four-way parallelism and serves a 128,000-token context rather than the model’s full one-million-token limit.
That difference matters. A larger context needs more memory, and Hugging Face estimates that the key-value cache alone could require about 266 gigabytes at one million tokens in BF16. This cache stores information from earlier tokens so the model can continue generating efficiently.
Local use is possible, but it is not ordinary laptop software. TechCrunch reported that Meta designed the model to run on Apple computers. Hugging Face tested a two-bit version on an Apple M3 Ultra with 512 gigabytes of memory; the model used about 304 gigabytes and generated about 18 tokens per second in that test.
Hugging Face also tested a three-bit Apple configuration using about 344 gigabytes on the same 512-gigabyte machine. It reported about 21 generated tokens per second with a 1,024-token prompt. Those results apply to the tested quantized versions and hardware, not every Mac.
What changes for developers
The practical change is access to a single open-weight model for coding work that combines software with visual, audio, and video evidence. Hugging Face provides integrations for Transformers, llama.cpp, SGLang, vLLM, and Apple-focused tools, plus examples for multimodal input and tool calling.
Developers can experiment with local quantized versions, use a hosted endpoint, or deploy the model on specialized servers. TechCrunch also reported availability through multiple application programming interface platforms.
Open weights offer more control than a closed hosted model, including the ability to choose serving software and adapt the system for a particular workflow. But that flexibility comes with operational work: teams must manage hardware, memory, context length, latency, and tool permissions.
For most developers, the immediate question is whether long, multimodal coding tasks justify the infrastructure. Independent coding benchmarks, hosted prices, licensing terms, and safety testing will determine whether Muse Spark Open becomes a practical choice beyond specialized machines and well-equipped servers.