Meta's Muse Spark Open needs about a terabyte of memory. Downloading the weights is the easy part

Meta’s showcase for its new open-weight model is two Apple M5 Ultra Mac Studios, each with up to 512 GB of unified memory, wired together to act as one machine with about a terabyte. On that setup, Meta’s coding agent made iOS changes to an open-source Mastodon client and drove a video editor frame by frame. It is a good demonstration, and an honest hint about scale: the smallest thing Meta chose to show it running on is a terabyte of fast memory.

Muse Spark Open, released on October 15, is a multimodal mixture-of-experts model with 816 billion total parameters, 42 billion active per token and a context window of up to one million tokens. Meta built it for coding, tool use and long-running agent work. The weights are on Hugging Face and in the model catalogs of Amazon SageMaker AI, Google Cloud Model Garden and Microsoft Foundry. Hosted inference is offered by Baseten, Fireworks AI, Groq, Modal, Nebius, OpenRouter and Together AI, and the model runs on the common inference engines, from vLLM and SGLang to MLX and llama.cpp.

For an enterprise, the release adds a serious option. It also adds a decision that is easy to make for the wrong reason.

Sparse is not small

Mixture of experts makes each token cheaper to compute, because only 42 billion parameters are active. It does not make the model small to hold. All 816 billion parameters have to sit in memory on whatever serves it, and a long context adds to that. Meta’s page does not state minimum hardware or official quantized formats, so the first engineering task is to establish what it really takes to serve the model at the latency and concurrency you need, on hardware you can get.

Meta’s performance claims are its own. The page calls Muse Spark Open the most capable U.S. open-weight model to date; the quantified numbers it gives are kernel-level speedups, not task results on work like yours. A million-token window is a capacity, not evidence that reasoning holds across it.

Four questions before you run it

1. Does the license fit your use? Muse Spark Open ships under the Muse Model License, which Meta describes as having “limited commercial terms, which allow many developers to use the model for free.” Open weights are not open source. Before an engineer downloads anything, legal should read the terms for commercial thresholds, redistribution, use inside a service you offer to customers, attribution and restricted uses.

2. What problem do the weights solve? The good reasons to hold weights are custody (code and prompts never leave infrastructure you control), customization (fine-tuning on your own codebase and conventions) and predictable cost at high, steady volume. “Avoiding vendor lock-in” alone is weak, because the hosted providers above already give you that with the same model.

3. Can you keep it busy? Self-hosting pays when the hardware is used. We saw a rented H100 earn four times its cost in a busy morning and lose money over the week. A model this size raises the stakes: idle capacity is expensive capacity. Price it per completed task over the hours you pay for, not per token at peak.

4. Who operates it? Running a frontier-scale model means patching the serving stack, monitoring quality drift, handling capacity incidents and evaluating every new release before it replaces the old one. As we wrote when Reflection released Beam, with open weights the operating duty moves to you. That duty is the real price of custody.

Three ways to hold it

The same weights now come with three operating models, and they are not equivalent:

• A hosted API from one of the inference providers: no hardware, but your prompts and code go to that provider, under its terms and its regions.
• A managed deployment in your cloud, through SageMaker AI, Model Garden or Foundry: your account, your network boundary, your capacity bill, with the cloud handling much of the serving.
• Your own hardware: maximum custody, maximum operating burden.

Many enterprises will start with the first to evaluate quality on their own repositories, and only move to the second or third if the evaluation and the volume justify it. That is the sequence we suggested for Mistral Large 4, and it holds here.

What the release changes

The practical change is in negotiation and architecture rather than in any single deployment. A frontier-class coding model with open weights gives enterprises a credible alternative to closed APIs for coding agents, which matters at contract renewal even if you never self-host. It also makes the model layer more replaceable, which raises the value of the parts that are not: your evaluation sets, your routing policy and the context your agents work from.

Start with the evaluation. Run Muse Spark Open against the tasks your coding agents already do, through a hosted endpoint, and compare cost per accepted change with what you use today. If it does not win there, the hardware question never needs an answer.