Reflection Beam: 501B Parameters and Open Weights
Reflection Beam is a new sparse mixture-of-experts model aimed at coding, reasoning and agentic work. Reflection introduced it on October 5 with 501 billion total parameters and 23 billion active parameters. However, the announcement is a preview: the company plans to release the weights later in October. Reflection’s launch post explains the specifications and timing.
Event date: October 5, 2026 · Sources checked: October 8, 2026
What Reflection Beam promises
Reflection says Beam reaches performance comparable to GLM-5.2 on advanced reasoning benchmarks while using three to four times less estimated inference compute. The comparison comes from the company’s evaluation, so it should not be presented as a universal independent ranking or a guaranteed reduction in a cloud bill.
Its compute estimate excludes prompt processing, context-dependent attention and serving overhead. Meanwhile, Beam is undergoing final evaluations and red-teaming, with early-access registration available. Reflection plans an Apache 2.0 weight release together with technical and developer materials later this month.
What active parameters tell you
A sparse model selects part of its expert network for each token. Therefore, total parameters and active parameters describe different aspects of the architecture. A lower active count can be relevant to computation, but it does not eliminate the need to store and serve the full model.
Likewise, an estimate of compute is different from measured latency or cost on a production deployment. Hardware, memory requirements and batch size can change the result. A useful comparison should report those settings alongside quality, rather than rely only on the parameter count.
Reflection Beam — xpu live analysis
Our view is that the planned weight release will be the next practical milestone. Access to weights and deployment materials lets teams examine a model in their own environment. Until that release, the available announcement establishes the intended direction and the company’s reported performance.
For example, a coding evaluation can test successful task completion, tool use and recovery from errors. Next, record generated tokens and elapsed time at several reasoning settings. This makes efficiency claims easier to compare with the work a team actually needs.
Similarly, distinguish the license announcement from the release of downloadable artifacts. Check the final model card and implementation requirements when they arrive. Finally, compare hosted and self-managed options using the same workload; additional control can be useful, but operating a large model also adds responsibility.
Sources and further reading
Related on xpu live: Choosing AI model APIs.