What Reflection's Beam announcement actually means
Reflection has announced Beam, a sparse mixture-of-experts model with 501 billion total parameters and about 23 billion active for each token. The company positions it around inference efficiency. The public weights are still promised later in October.
On 5 October 2026 Reflection announced Beam, describing it as the company's first open-weight model. The number attached to that announcement is 501 billion parameters. It describes how much capacity the model stores, not how much of it runs for every token it produces.
Beam is a sparse mixture-of-experts model. Instead of using the entire stored network for each step of generation, it selects a subset of specialists. Reflection says about 23 billion parameters are active for a given token.
The company trained Beam particularly for coding, reasoning and tasks that use tools. It says the model was pretrained on 23.8 trillion tokens, then taught longer coding, reasoning and tool-using work through a reinforcement-learning stage that produced more than 100 million rollouts on 10,500 NVIDIA GB300 GPUs over four weeks. Those training figures are Reflection's account of its own run. An early version is available to a limited group of users. The public weights, technical report, model card and developer artefacts are still promised later in October.
Two parameter counts answer different questions
Total parameter count can tell you something about the capacity stored across the whole model. Active parameter count is closer to the amount of model computation used for an individual generation step. Organisations that treat 501 billion as a proxy for hosting cost will overstate the generation work and miss everything else that serving a large model involves.
That does not make Beam a 23 billion-parameter model. The unused experts still have to be stored, loaded and routed. Serving a sparse model has its own machinery: deciding which experts to run, moving their weights, and keeping them available. Reflection has not shown that Beam's operating cost matches a dense model with 23 billion parameters. What the two numbers do establish is more limited. Taken on its own, 501 billion is a poor way to reason about what it will cost to generate an answer.
How Reflection is measuring efficiency
Reflection's main claim is about inference: the work of producing output once the model is already trained. The company says Beam can reach scores comparable to some larger open models while using less generation compute, and it acknowledges that models such as Kimi K3 remain ahead on some raw capability comparisons. The judgement it is asking for is the combination of capability and the compute used to produce an answer.
The comparison Reflection publishes is an estimate, not a measured hosting bill. It approximates generation compute from active parameter count and the average number of tokens produced, and it explicitly leaves out prompt prefill, context-dependent attention work and serving overhead. Those omitted pieces can be a large part of what an organisation actually pays for. The comparison is useful as one model of generation compute, and it is not evidence that Beam will cost less to run end to end.
The scores come from the company that trained the model
The announcement includes vendor results across coding, reasoning, tool use and general tasks. They remain Reflection's own reported figures. No independent evaluation of Beam was available when this article was published. Reflection itself treats some larger open models as ahead on raw capability, which is a reason not to read the post as if the highest published score were the only thing that mattered. Until other groups can run the weights, the tables show how Reflection wants the model compared, not how it will behave on an organisation's own work.
Open-weight is still a promise
Reflection calls Beam an open-weight model because it intends to publish the trained parameters. Those weights are not public. There is no model card, no technical report, and no licence text attached to a download. Reflection says the intended licence is Apache 2.0, and that it will also publish documentation and software for running, evaluating and fine-tuning the model. Early access exists for selected users. Final red-teaming and evaluations are still underway.
Open weight and open source are easy to collapse into one phrase. An open-weight release means the trained parameters are available under a licence. It does not automatically mean the training data, the training code or the full pipeline are available, or that the result can be reproduced from scratch. Reflection says it wants to publish more than the weights. Until those artefacts exist, the accurate description is an announced model with limited early access and a later release that has not happened yet.
If the Apache 2.0 weight release happens, organisations gain choices they do not have with a closed hosted API: where the model runs, who operates it, how it is integrated and evaluated, and whether it can be adapted. Those choices do not remove the infrastructure. A sparse model that stores 501 billion parameters still has to be held or loaded, and the serving system still has to choose and run the active experts. Organisations that want that control will need the capacity to operate it. A public release would let them try that work themselves, rather than only through a hosted interface.
What to look at when the weights arrive
Choosing a model for an organisation is an operating decision. Parameter count and a vendor score table are starting information, not the decision. Someone still has to know what the workload actually requires, what infrastructure the model needs, how much inference compute it consumes on real tasks, how it behaves on the organisation's own work, whether it can be deployed and controlled in the way the organisation needs, and whether the published scores survive independent testing.
The announcement cannot close those questions. They become answerable if the weights, the licence and the supporting artefacts arrive as promised. Until then, the useful reading of Beam is as a set of claims about architecture, cost and availability, rather than as a single number.
Connecting a model to the systems where work happens, and deciding what that model is allowed to do, is the usual AI integration problem. A newly announced model only becomes part of that work once it can actually be obtained, evaluated and operated.