On October 16, 2026, Reflection AI released the weights of Beam, its first open-weight AI model, under the Apache License 2.0. The company had announced on October 5 that the release would come within the month. Alongside the model itself, it has now made available three versions at different numerical precisions, plus an auxiliary model that speeds up inference. Companies and developers can now run the model on their own computing infrastructure and test its performance and operating costs.
Beam is a Mixture of Experts (MoE) model with 501.3 billion total parameters, of which 23.4 billion are active for each token processed. It is designed mainly for programming and agentic work involving multiple steps, and its defining feature is that it generates fewer tokens before arriving at an answer. Reflection claims that this more efficient reasoning can reduce computing costs, but whether it actually saves money for a company depends on checking both the model's performance and the conditions under which it is run.
How Reinforcement Learning Encourages "Shorter Reasoning"
In Beam's reinforcement learning, Reflection added a mechanism that discourages unnecessary token generation, on top of the reward for solving a task correctly. Specifically, the training reward includes an adjustable penalty that scales with the number of tokens generated. According to the technical explanation published on October 5, in the early stages of reinforcement learning the number of tokens needed to reach an answer fell while the model's ability to solve tasks improved at the same time.
However, as training progressed and the model became able to handle complex agentic tasks, the number of generated tokens rose again. In some phases, doing more reasoning helped solve harder problems. In other words, Reflection's aim is not to shorten reasoning on every problem, but to concentrate resources on the computation needed to get the right answer. According to the company, this reinforcement learning used 10,500 NVIDIA GB300 GPUs and ran for four weeks, covering more than 100 million attempts.
The amount of computation spent on reasoning can also be adjusted when the model is used. According to the official API documentation, there are five reasoning settings, from "low" to "max." However, Beam is designed to always reason before answering, so reasoning cannot be turned off entirely. The settings let users choose between simple tasks where fast responses matter and complex tasks where higher answer quality is worth the extra time.
What Does "One-Third to One-Quarter of the Reasoning Compute" Actually Compare?
Reflection claims that Beam can match the performance of GLM-5.2 on difficult reasoning tasks using one-third to one-quarter of the inference compute. When interpreting this figure, though, it is important to check what is being counted as compute. The official comparison chart and its explanation make clear that the measurement is limited to the generation process.
The compute estimate uses the following formula:
Generation compute ≈ 2 × active parameters × average tokens generated per attempt
The generated tokens include both intermediate reasoning and the final answer. For MoE models, the calculation uses the number of parameters actually active during processing, not the total parameter count. The estimate does not include the compute needed to read the input text, the attention processing whose cost grows with longer contexts, or the system load of serving the model. It is therefore a rough comparison of generation compute, and does not mean that actual GPU operating costs or API bills would fall to one-third or one-quarter.
Beam also uses weight quantization and auxiliary-model acceleration, in addition to training that reduces the number of generated tokens. However, each technique reduces a different computing resource or improves a different metric. The main differences are summarized below.
| Optimization method | Main area improved | What still needs to be verified |
|---|---|---|
| Reinforcement learning that encourages shorter reasoning | Tokens generated before reaching an answer | Whether accuracy and success rates hold up on your own tasks |
| Weight quantization | Model storage size and runtime load | Answer quality at reduced numerical precision |
| Candidate generation by an auxiliary model | Speed of token generation | How the effect changes with GPU configuration and number of concurrent users |
When a company judges the benefit of adopting a model, what matters is not any single metric but the total cost of completing one job. For example, with an agent that repeatedly reads past work history or large numbers of files, cutting generated tokens may deliver only limited overall savings if input processing is the heavy part. And if lower answer quality leads to more retries or more human correction, the savings in generation could be offset. To judge whether short reasoning is a practical advantage, you need to compare task success rates, time required, and the burden of retries and corrections.
Quantized Model Sizes and the GPU Requirements to Actually Run Beam
Beam is released in three numerical precisions: BF16, FP8, and NVFP4. Quantization, which represents the model's weights with fewer bits, reduces storage size, but lowering precision may also affect answer quality. According to Reflection's published model card and official download guide, the size of each format and its main evaluation results are as follows.
| Item | BF16 | FP8 | NVFP4 |
|---|---|---|---|
| Weight download size | 933.81 GiB | 468.72 GiB | 273 GiB |
| Terminal Bench v2.1 | 80.1% | 78.9% | 78.4% |
| SWE-bench Verified | 81.6% | 80.2% | 80.7% |
| HLE (no tools) | 36.0% | 36.0% | 34.8% |
In the results Reflection published, moving from BF16 to NVFP4 lowers the Terminal Bench v2.1 score from 80.1% to 78.4% and the no-tools HLE score from 36.0% to 34.8%. On SWE-bench Verified, however, NVFP4 slightly outperforms FP8, so quantization does not worsen every benchmark uniformly. The common evaluation settings were a temperature of 0.7 and top_p of 0.99, and the table lists only figures comparing the different precisions of the same model released this time. Because the margin of error and the number of repeated runs are not disclosed, it is impossible to tell whether small score differences are statistically significant.
The size reduction is clear: the NVFP4 download is about 30% of the BF16 version. But 273 GiB is only the weight download size, not the total GPU memory needed to run the model. Beam's MoE design limits the parameters active per token to 23.4 billion, but the full set of weights still has to be held in memory. A relatively small active parameter count therefore does not mean the model can run on the same hardware as a small model.
The SGLang setup guide Reflection published uses a server with four NVIDIA B300 GPUs connected by NVLink. This configuration pairs the NVFP4 version of Beam with the auxiliary model for faster inference. In the settings for development and evaluation, the context length is limited to 262,144 tokens and concurrent requests to eight. Beam itself is said to support a context of up to 1 million tokens, but this differs from the limit set when launching it exactly as the official guide describes. The 262,144-token and eight-request limits are likewise just the settings in this example, not upper limits common to every Beam configuration.
A 1.93-Billion-Parameter Auxiliary Model Speeds Up Generation by Up to 3x
Alongside Beam itself, Reflection also released DFlash2, an auxiliary model with 1.93 billion parameters. DFlash2 is used for speculative decoding, in which it drafts candidate token sequences ahead of time and the main Beam model verifies them in batches. According to its published model card, it uses rejection sampling to preserve the output distribution of the main Beam model. DFlash2 is not an independent language model for standalone use; it is an auxiliary model that accelerates Beam's generation.
Unlike the reinforcement learning approach that reduces the number of tokens needed to reach an answer, this technique speeds up the token generation process itself. In Reflection's official speed evaluation, Beam in NVFP4 ran on four B300 GPUs with DFlash2 drafting eight tokens at a time, and generation was 1.72 to 3.03 times faster than without the auxiliary model.
The highest result, 3.03x, came from processing the math benchmark GSM8K with one concurrent request, where generation speed rose from 288 to 874 tokens per second. By contrast, processing MT-Bench with 16 concurrent requests improved speed by only 1.72x. All results were measured using a generation method that selects the highest-probability token at each step.
It is therefore not possible to simply multiply DFlash2's speedup by the reduction in reasoning tokens from reinforcement learning to calculate how many times faster an entire workload will run. The benefit of speculative decoding depends on how many of the auxiliary model's candidates the main Beam model can accept, and it also varies with the type of task and the number of concurrent users. Moreover, for work in which reading inputs or running tools takes much of the time, speeding up token generation alone will not necessarily shorten the whole job by the same proportion.
Apache 2.0 Weights and the Challenges That Remain for Enterprise Adoption
With Beam's weights released under the Apache License 2.0, companies and developers gain the option of running the model in their own environments and training it further for their purposes. The model card states explicitly that it does not prohibit fine-tuning or quantization, nor distillation or training other models on Beam's outputs. These license terms are a significant advantage for companies that want to adapt the model to their own business. However, because Beam's training also used data obtained under commercial agreements, publishing the weights does not mean the full training process can be reproduced with the same data.
Reflection says it combined Beam's training with Mirror CLI, an agent tool for code development. According to the launch announcement, Mirror CLI can switch between the models and servers it connects to, and developers can use it while reviewing what it does. The company also offers a verification tool, Beam Verifier, which can separately run checks on whether APIs and tool calls work correctly and performance evaluations using benchmarks such as GPQA and AIME. This provides a way to verify expected behavior and performance, not just to confirm that the model starts up.
When integrating Beam into existing applications, however, conversation history handling also needs attention. The official API requires that, in multi-turn conversations, past reasoning content be kept as is in the conversation history. For systems that store only final answers as history, swapping in the model is therefore not enough; teams need to check how reasoning history is stored and passed to the next request. Compatibility with surrounding systems, not just model capability, is part of what must be verified at adoption.
For further training, too, it is necessary to distinguish between features listed as supported and procedures that are actually available. The official customization documentation lists foundations that support LoRA fine-tuning and reinforcement learning, but notes that concrete procedures for using each are coming soon. For self-distillation, the October 16 announcement said procedures would be published within the next few days. Having planned features described is not the same as having all the necessary tools and procedures available.
It is also worth noting that Beam is a text model developed mainly for English. For work involving Japanese internal documents, or code review based on instructions in Japanese, answer quality needs to be tested with real business data. Beyond that, it will be important to compare the cost of completing a job, including differences in accuracy from quantization, reasoning settings, and the number of retries. With the weights now public, companies and developers can test for themselves, on their own equipment and under their own evaluation conditions, whether the "efficiency through shorter reasoning" that Reflection promotes holds up in real work.