Muse Spark Open, parallel agents and a frontier model on your desk

The news, and what is confirmed

In the same week, Meta released a frontier-scale model anyone can download and run on two desktop computers, and OpenAI let ChatGPT split one task across several agents working at once. One story is about where a model runs; the other is about how work is divided. Both come down to arithmetic you can do yourself: bytes per parameter, tokens per step and the longest chain of tasks.

What was released?

Muse Spark Open (15 October) is an open-weight model from Meta Superintelligence Labs, “trained for long-horizon agentic work such as coding and customer service agents” (Meta). It is a mixture of experts with about 816 billion parameters in total, of which about 42 billion are used for each token. According to Hugging Face’s launch post, it has 62 layers, 256 experts in each MoE layer with 8 chosen per token, and a context of up to 1,048,576 tokens. It reads text, images, audio and video and writes text. Meta describes it as “the most capable US open-weight model running on the desktop”, and says it runs on two Mac Studios with 512 GB of memory each, or four with 256 GB.

GPT-6 Astra Pro, the Pro model in ChatGPT (OpenAI’s first post called it GPT-6 Pro), got an upgrade on 16 October. In OpenAI’s words: “faster responses and improved use of plugins and tools. And now, multiple agents can tackle different parts of a task in parallel. You can follow each agent’s progress and open completed tasks to review their work.” It is rolling out to Pro users.

Key takeaways

• Muse Spark Open is an open-weight mixture of experts: about 816B parameters in total, 42B active per token, 1M-token context, text, image, audio and video in.
• GPT-6 Astra Pro in ChatGPT can now run several agents on parts of one task in parallel; OpenAI has not explained how.
• Neither maker has disclosed training data; Meta gave no benchmarks in its developer post, and press figures are Meta’s own.

Open weights, open source, API

“Open” is doing a lot of work in AI headlines. There are three common ways to get a model, and they give you very different things.

What is it?

An API model runs on the maker’s servers; you send text and get text back. An open-weights model ships its trained parameters, the numbers the model learned, so you can run it yourself. Open source, in the sense of the Open Source Initiative’s definition, asks for more: freedom to use the system “for any purpose and without having to ask for permission”, plus the training code and “sufficiently detailed information about the data used to train the system so that a skilled person can build a substantially equivalent system”.

How does Muse Spark Open fit?

It is open weights. The licence is Meta’s own Muse Model License. As VentureBeat reports its terms, you may run, modify, fine-tune and redistribute the model with a “Built with Muse Spark Open” attribution, but a company with more than $20 million in annual revenue must contact Meta before offering it to others as a hosted model service. Internal use is not restricted that way. Because of that condition, and because the training data is not described, it does not meet the OSI definition. Read the licence itself before building a business on it.

Why does it matter?

Weights on your own machines mean your data never leaves them, the model never changes unless you change it, and you can make it smaller or faster: everything in the rest of this lesson, from quantization to speculative decoding, is something you can only do with the weights in hand. The price is that you now pay for the hardware and run the service yourself.

Key takeaways

• API, open weights and open source are different: weights let you run and change a model; open source also needs unrestricted use and data information.
• Muse Spark Open is open weights under a custom licence with attribution and a condition for large companies offering it as a service.
• Having the weights is what makes quantization, local hosting and custom decoding possible.

Total and active parameters

816 billion parameters sounds impossible to run on a desk. 42 billion sounds ordinary. Both numbers describe the same model, and each one answers a different question.

What is it?

In a mixture of experts, some layers are split into many parallel sub-networks called experts. A small router looks at each token and sends it to a few of them (Shazeer and colleagues). Muse Spark Open has 256 experts in each MoE layer and uses 8 per token (Hugging Face), so each token touches about 3% of the experts, plus the attention and other shared layers that every token uses. That adds up to about 42 billion active parameters, about 5% of the 816 billion total.

How does it work out in cost?

Computation follows the active parameters. A forward pass costs about two operations per parameter used, per token (Kaplan and colleagues), so Muse Spark Open does roughly the arithmetic of a 42B dense model, not an 816B one.

Ignoring attention over the context, which adds a term that grows with context length.

Memory follows the total. The router can pick any expert for the next token, so all 256 experts in every layer must be loaded and ready. That is why an MoE is fast for its size but still big to host: you pay for 816 billion parameters in memory and about 42 billion in compute.

Why does it matter?

It tells you what to buy. The question for running Muse Spark Open is not “is my machine fast enough for 816B?” but “does it have enough memory to hold 816B, and enough bandwidth to read 42B worth of weights for every token?” The next section does that memory sum.

Key takeaways

• Muse Spark Open routes each token to 8 of 256 experts per MoE layer: about 42B of its 816B parameters are active.
• Compute per token scales with active parameters; memory scales with total parameters, because any expert may be needed next.
• So an MoE runs at roughly the speed of its active size but must be hosted at its total size.

Will it fit? The memory sum

Whether a model fits on your hardware is a multiplication: parameters times bytes per parameter, plus the memory for the conversation itself. Here are the real numbers for Muse Spark Open.

What goes into memory?

Two things dominate. The weights: 816 billion parameters at 2 bytes each in BF16 is 1,632 GB, which matches the deployment guide’s 1.63 TB for the language-model weights. And the KV cache: the keys and values the model stores for every token of context so it does not recompute them. Hugging Face puts it at about 250 KB per token, about 266 GB for a full million-token context. Every simultaneous conversation needs its own.

Bytes per parameter: BF16 2, FP8 1, 4-bit 0.5, 2-bit 0.25. The KV cache grows in proportion to the tokens held.

In BF16 the weights alone are more than a full node of eight H200 GPUs holds, which is why the reference BF16 deployment spans four such nodes (Hugging Face). A 4-bit build the size of Meta’s 530 GB NVFP4 checkpoint fits on two 512 GB Mac Studios with room for a long context, which is how Meta can call it a desktop model; on Macs it runs through MLX rather than NVFP4 (Meta). No single 80 GB GPU comes close at any precision.

Why is 530 GB larger than the naive 408 GB? Two reasons. First, NVFP4 is not exactly 4 bits: it stores one 8-bit scale for every block of 16 values, which makes about 4.5 bits per value (NVIDIA). Second, Meta says “only the experts are quantized” (Meta); attention and the other dense layers stay at higher precision for stability (deployment guide). If the experts sit at 4.5 bits and the rest at 16, a 530 GB file is consistent with roughly 50 billion parameters outside the routed experts. That split is our estimate from the totals, not a figure Meta has published.

Key takeaways

• Weights: 816B parameters × bytes per parameter, 1.63 TB in BF16. KV cache: about 266 GB per full 1M-token conversation.
• Meta’s NVFP4 checkpoint (~530 GB) is above the naive 408 GB because of block scales and because only the experts are quantized.
• That is why BF16 needs several GPU nodes while the 4-bit model fits on two 512 GB Mac Studios.

Quantization trade-offs

Muse Spark Open ships in more than one size: BF16, Meta’s NVFP4, and community GGUF files down to about 2 bits. Fewer bits mean less memory and faster reading, but every bit you remove is information the model loses.

What is it?

Quantization stores each weight with fewer bits, by rounding it to one of a small set of levels. With 4 bits there are only 16 levels, so each block of weights gets its own scale that stretches those levels to fit the block’s range. Methods such as GPTQ choose the rounding carefully, so the errors in one weight are compensated by others, and can reach 3 or 4 bits with little loss.

How do real checkpoints decide what to quantize?

Not all weights are equally sensitive. Dettmers and colleagues found that large language models develop a few features of very large magnitude that naive low-bit rounding destroys. So practical schemes keep the sensitive parts at higher precision. Meta’s NVFP4 build quantizes only the routed experts, which hold most of the parameters but each see only a fraction of tokens, and keeps the dense layers that every token passes through at higher precision (deployment guide). Unsloth’s GGUF files go further, and the guide lists about 300 to 315 GB of total memory for its 2-bit version, well above the naive 204 GB, for the same reason.

Why does it matter?

Generating each token means reading the active weights from memory, so on a desktop the speed limit is often memory bandwidth, not arithmetic. Halving the bits halves the bytes read per token as well as the memory needed. The cost is quality, and it does not fall evenly: long reasoning chains, code and rare languages tend to suffer first. The NVFP4 checkpoint is described as having “negligible loss in accuracy” (Hugging Face); no comparable claim comes with the 2-bit files, so measure on your own tasks.

Key takeaways

• Quantization rounds weights to fewer levels, with a scale per block; good methods choose the rounding to cancel errors.
• Real checkpoints keep sensitive layers at higher precision, which is why they are larger than bits × parameters.
• Fewer bits means less memory and faster decoding but some lost quality; test low-bit builds on your own work.

Speculative decoding

Meta released Muse Spark Open with two small draft models, and reports that on AMD MI355X GPUs they make a single request run 3.7 times faster. The trick is called speculative decoding, and it produces the same output as the big model alone.

What is it?

A language model writes one token per forward pass, and each pass has to read the weights. Speculative decoding (Leviathan and colleagues; Chen and colleagues) lets a small, fast draft model guess the next several tokens. The big model then checks all the guesses in a single pass, which costs about the same as writing one token, because reading the weights dominates.

How does it work?

The big model accepts guesses from left to right until the first one it disagrees with. It then adds one token of its own: a correction at the point of disagreement, or a bonus token if every guess passed. The acceptance rule is designed so the result has exactly the distribution the big model would have produced alone. If each guess is accepted with probability α, the expected number accepted from k drafts is a short geometric sum.

Leviathan and colleagues’ result. Each pass of the big model yields this many tokens plus one of its own.

For Muse Spark Open, the DFlash2 draft model “proposes a block of eight draft tokens per step” (deployment guide), and Meta reports that “6.4 drafted tokens are accepted per step”, giving 3.7 times the throughput for a single request and 2.9 times at 16 concurrent requests (Meta).

At 6.4 accepted drafts plus the big model’s own token, each pass yields about 7.4 tokens, yet the measured gain is 3.7 times. The gap is real cost: running the draft model, checking nine positions instead of one, and serving overheads. It shrinks further with 16 users at once because a busy GPU is no longer idling while it reads weights, so the extra checking work is no longer free. Speculative decoding helps most exactly where a desktop model lives: one user, memory-bound.

Key takeaways

• A small draft model guesses several tokens; the big model verifies them in one pass and keeps the accepted prefix plus one token of its own.
• Expected accepted drafts are α + α² + … + α^k; Meta’s 6.4 of 8 corresponds to about 95% acceptance per token.
• The output is unchanged; the speedup is largest for single, memory-bound requests and smaller under heavy batching.

Parallel agents

OpenAI’s update lets several agents work on different parts of a task at once. Whether that makes you faster depends less on the model than on the shape of the task.

What is it?

An AI agent is a model in a loop: plan, call a tool, read the result, repeat. Parallel agents split one request into subtasks and run several of these loops at the same time, then merge the results. OpenAI says you can “follow each agent’s progress and open completed tasks to review their work” (OpenAI); it has not said how the split is decided.

How does it work?

Draw the subtasks as a graph of dependencies. Independent subtasks can run side by side; a subtask that needs another’s output must wait. However many agents you add, the job cannot finish faster than its critical path, the longest chain of tasks that each depend on the one before. This is Amdahl’s old point about parallel computers: the part that must happen in sequence sets the limit. On top of that come coordination costs: planning the split, handing results between agents and merging them.

With these numbers one agent takes 20 minutes. Two agents bring it to 13.5 and four to 9.5, close to the 8-minute critical path (prices, then chart, then summary) but never below it, because of the planning step and hand-offs. Raise the hand-off delay to 3 minutes and the four-agent plan slows to 12 minutes while still using more agents. Doubling agents again would change nothing: there are only four independent pieces of work.

Key takeaways

• Parallel agents run independent subtasks at the same time and merge the results.
• Wall-clock time can never beat the critical path, and planning, hand-offs and merging add to it.
• Parallelism buys time with extra tokens; it pays off for broad, loosely coupled tasks and much less for tightly coupled ones.

Choosing, and what to watch

Two different promises: a big model you can own, and an assistant that works on several things at once. Here is how to think about each.

How should you decide?

For a self-hosted model, start from the memory sum: total parameters times bytes, plus KV cache for the contexts and number of users you need, plus headroom. Then test the quantized build you can afford against your own tasks, as the evaluation lesson describes, because Meta has published no benchmark numbers in its developer post. For parallel agents, sketch the task’s dependency graph first; if the longest chain is most of the work, more agents will not help.

What should you watch next?

• Independent benchmarks of Muse Spark Open, and of its NVFP4 and 2-bit builds against BF16.
• Real desktop speeds. Meta has not published measured generation speed on its two-Mac setup (VentureBeat).
• How the licence is read. The revenue condition on hosted services will decide which cloud providers offer it.
• What OpenAI documents about parallel agents: how tasks are split, how many agents run, and how usage is counted.

Key takeaways

• Self-hosting is a memory question first: parameters × bytes plus KV cache per user.
• Test quantized builds on your own tasks; Meta’s developer post gives no benchmarks.
• Use parallel agents for broad tasks that split cleanly; the critical path sets the floor.

Check your understanding

Six scenarios, from hosting a model in-house to deciding when more agents will actually help.

A hospital wants to analyse patient notes with an AI model, and the data may not leave its own servers. It is choosing between an API model and Muse Spark Open. What does the open-weights release make possible?

References

Model details come from Meta’s developer blog and deployment guide, Hugging Face’s launch post and OpenAI’s announcement, checked on 19 October 2026. Benchmark and licence summaries quoted from the press are labelled as such. Background on mixtures of experts, quantization, speculative decoding and multi-agent systems comes from papers and engineering write-ups.

Sources

1. [1]

   Build with Muse Spark Open(opens in a new tab)

   Meta, 2026

   Developer announcement (15 October 2026): an 816B-parameter open-weight model from Meta Superintelligence Labs, about 42B active per token, “trained for long-horizon agentic work such as coding and customer service agents”; Muse Model License; NVFP4 checkpoint about 530 GB with only the experts quantized, BF16 about 1.6 TB; two Mac Studios (M5 Ultra, 512 GB) or four with 256 GB; speculative decoding 3.7× single-request throughput on AMD MI355X, 2.9× at 16 concurrent requests, 6.4 drafted tokens accepted per step. No benchmark numbers or training data details.

2. [2]

   Welcome Muse Spark Open: open-weight frontier multimodal mixture-of-experts model from Meta(opens in a new tab)

   Hugging Face, 2026

   Architecture: about 816B total and 42B active parameters, 256 experts per MoE layer with 8 selected per token, 62 layers, up to 1,048,576 tokens of context; text, image, audio and video in, text out. BF16 checkpoint about 1.5 TB; KV cache about 250 KB per token and about 266 GB for a full 1M-token context; BF16 served on 4 nodes of 8 H200 GPUs (TP=32), NVFP4 on a single B200 node.

3. [3]

   GPT-6 Astra Pro in ChatGPT: parallel agents (post on X)(opens in a new tab)

   OpenAI, 2026

   16 October 2026 (a repost of an earlier post that called the model “GPT-6 Pro”): “GPT-6 Astra Pro in ChatGPT got an upgrade with faster responses and improved use of plugins and tools. And now, multiple agents can tackle different parts of a task in parallel. You can follow each agent’s progress and open completed tasks to review their work.” Rolling out to Pro users.

4. [4]

   Meta unveils Muse Spark Open, the new top U.S. open weights model, and it runs on two paired Mac desktops(opens in a new tab)

   VentureBeat, 2026

   Licence terms: running, modifying, fine-tuning and redistributing allowed with “Built with Muse Spark Open” attribution; licensees above $20 million in annual revenue must contact Meta before offering it as a hosted model service. Meta-reported Artificial Analysis Intelligence Index of 39, behind several Chinese open models on coding; no measured generation speeds from Meta.

5. [5]

   The Open Source AI Definition 1.0(opens in a new tab)

   Open Source Initiative, 2024

   An open source AI system must grant the freedoms to use it for any purpose without asking permission, study it, modify it and share it, and must come with the weights, the training and inference code, and detailed information about the training data.

6. [6]

   Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer(opens in a new tab)

   Shazeer, N., Mirhoseini, A., Maziarz, K., Davis, A., Le, Q., Hinton, G., Dean, J., 2017

   A learned router sends each token to a few experts out of many, so capacity grows with the number of experts while computation per token grows only with the few that run. ICLR 2017.

7. [7]

   Scaling Laws for Neural Language Models(opens in a new tab)

   Kaplan, J., McCandlish, S., Henighan, T., Brown, T. B., Chess, B., Child, R., Gray, S., Radford, A., Wu, J., Amodei, D., 2020

   Counts the forward pass of a transformer at about 2 operations per parameter per token, plus an attention term that grows with context.

8. [8]

   Muse Spark Open: run inference(opens in a new tab)

   Meta, 2026

   Deployment guide: BF16 language-model weights about 1.63 TB; NVFP4 checkpoint with “routed-expert weights pre-quantized to NVFP4”, dense layers kept at higher precision; Unsloth GGUF memory about 300 to 315 GB at 2-bit; the DFlash2 draft model “proposes a block of eight draft tokens per step”, served in SGLang.

9. [9]

   Introducing NVFP4 for Efficient and Accurate Low-Precision Inference(opens in a new tab)

   NVIDIA, 2025

   NVFP4 stores 4-bit values in 16-value blocks, each with one FP8 (E4M3) scale, plus one FP32 scale per tensor: about 4.5 bits per value.

10. [10]

    GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers(opens in a new tab)

    Frantar, E., Ashkboos, S., Hoefler, T., Alistarh, D., 2023

    Quantizes GPT models to 3 or 4 bits per weight after training with little loss in accuracy, using second-order information to correct the error each rounding introduces. ICLR 2023.

11. [11]

    LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale(opens in a new tab)

    Dettmers, T., Lewis, M., Belkada, Y., Zettlemoyer, L., 2022

    Shows that large language models develop a few outlier features of very large magnitude that naive low-bit quantization destroys, and keeps them in higher precision. NeurIPS 2022.

12. [12]

    Fast Inference from Transformers via Speculative Decoding(opens in a new tab)

    Leviathan, Y., Kalman, M., Matias, Y., 2023

    A small draft model proposes several tokens; the large model checks them all in one parallel pass and keeps the longest accepted prefix, with an acceptance rule that leaves the output distribution unchanged. With acceptance rate α and γ drafts, the expected tokens per step is (1 − α^(γ+1)) ÷ (1 − α). ICML 2023.

13. [13]

    Accelerating Large Language Model Decoding with Speculative Sampling(opens in a new tab)

    Chen, C., Borgeaud, S., Irving, G., Lespiau, J.-B., Sifre, L., Jumper, J., 2023

    Independent proposal of draft-then-verify sampling, reporting 2 to 2.5× decoding speedups for a 70B model without changing its samples.

14. [14]

    Validity of the single processor approach to achieving large scale computing capabilities(opens in a new tab)

    Amdahl, G. M., 1967

    The classic argument that the part of a job that must run in sequence limits the speedup from adding processors. AFIPS 1967.

15. [15]

    How we built our multi-agent research system(opens in a new tab)

    Anthropic, 2025

    A lead agent plans and spawns sub-agents that search in parallel. Reports that multi-agent runs use about 15 times more tokens than chats, and that the approach suits broad, parallelisable tasks better than tightly coupled ones such as most coding.