In the space of a few days this month, several large AI models shipped with downloadable weights. Meta released Muse Spark Open on October 15, and Reflection released Beam a day later, alongside releases from StepFun, NVIDIA and DeepSeek. Open-weight models are a serious option for coding and agent work again. The details that decide whether one fits a real project are less exciting than the benchmarks: the license, the hardware and the testing.
Both headline releases are built for long, multi-step software tasks. Muse Spark Open is a mixture-of-experts model with about 816 billion parameters, 42 billion active per token, a one-million-token context window, and text, image, audio and video input. Beam is text-only, with 501 billion parameters and 23 billion active, the same context length, and support in common serving tools like vLLM and SGLang from day one.
What open-weight models still ask of you
Start with the license, because "open" covers a wide range. Meta's model ships under its own Muse Model License with limited commercial terms. Beam uses Apache 2.0, which is about as permissive as licenses get. AIToolCrunch's comparison of the week's releases lists a different license for each of the five models, from MIT to vendor-specific terms with commercial thresholds. Someone should read them before a product depends on one.
Then the hardware. Every expert stays in memory even though only a few run per token, so these models need the memory of their full size. Hugging Face notes that the full-precision Muse checkpoint is about 1.5 TB and runs across four nodes of eight H200 GPUs. Beam's 4-bit version shrinks to roughly 280 GB, and the guidance is to plan for four B200 GPUs. Called through a hosted API instead, most of these models are not cheaper than the budget closed models, and independent scores still trail the closed frontier. Beam's first independent score also came in below the company's own launch figures.
None of that makes open weights a bad idea. The good reasons to use them are about control: keeping data on your own infrastructure, fine-tuning on your own material, avoiding lock-in to one vendor, and predictable costs at high volume. The practical approach is unglamorous. Read the license, price the hardware or hosting honestly, test the model on your own tasks rather than the leaderboard, and keep a person reviewing what it produces. We would be curious which of these releases, if any, your team is planning to try.