23 out of 501. That is the ratio that matters in Reflection AI’s new model, Beam: a sparse Mixture-of-Experts network carrying 501 billion total parameters while activating roughly 23 billion per token. About 4.6 percent of the model does the work on any given forward pass. Everything interesting about Beam as an agent substrate follows from that number.
Reflection announced Beam on October 5, 2026, calling it the company’s first open-weight model, built for coding, reasoning, and agentic workloads. Weights are not out yet. The company says it will finish red-teaming and then publish the weights, a technical report, a model card, and developer tools across the rest of October, with access initially gated behind an early access waitlist. Licensing is planned as Apache 2.0 and MIT.
Sparsity is an agent decision, not a benchmark trick
Most coverage of MoE models frames sparsity as a cost story: fewer active parameters, cheaper tokens, happier finance team. That framing undersells what it does to agent architecture.
An agent is not one inference. It is a loop. Plan, call a tool, read the result, revise, repeat. A coding agent working through a repository might burn dozens of generations before it produces a patch worth looking at. The dominant cost in agentic systems is not the single clever answer, it is the long tail of intermediate reasoning that the user never sees. That tail scales with active compute per token, not with total parameter count.
Reflection’s claim is that Beam competes with larger open models such as GLM 5.2 while using three to four times less inference compute on reasoning benchmarks. If that holds under independent testing, the practical consequence is not a cheaper chatbot. It is a wider search budget. The same hardware that supported one reasoning trajectory now supports three or four. For agents, that changes what strategies are affordable: parallel hypothesis exploration, self-consistency voting across trajectories, speculative tool calls that get discarded when they turn out wrong. Those techniques are well understood and mostly priced out of production. A 3 to 4x compute reduction moves them into range.
What 80.9 percent on SWE-bench Verified does and does not tell us
Reflection reports 80.9 percent on SWE-bench Verified. Taken at face value, that is a strong number on a benchmark that requires producing working patches against real repository issues rather than completing isolated functions.
Two caveats from someone who reads these tables for a living. First, these are scores as published in Reflection’s own announcement, not independent replications, and SWE-bench results are notoriously sensitive to scaffolding. The agent use, retrieval strategy, retry policy, and test-time compute budget can swing a score substantially on an unchanged model. Until the technical report lands, the number describes a system, not just a set of weights.
Second, SWE-bench measures a narrow slice of agentic competence: single-repository, single-language, well-specified issue resolution with a test oracle to check against. Real agent deployments involve ambiguous specifications, no oracle, multi-service state, and the need to recognize when to stop. A model can be excellent at the first and mediocre at the rest.
The smallest model in its comparison set
By total parameters, Beam is the smallest model in the lineup Reflection compares itself against, and its 23B active count sits below GLM-5.2 and Nemotron 3 Ultra. That positioning is a design statement. Reflection is not competing on capacity, it is competing on capacity efficiency.
There is a real engineering tension in that choice, and it is worth watching once the weights drop. Sparse MoE models trade dense capacity for routing. Total parameters still have to live in memory, which means a 501B model needs serious hardware to serve even if only 23B fire per token. The savings are in compute and latency, not in VRAM. Teams reading “23 billion active” as “runs on my workstation” will be disappointed. Separately, routing quality matters more in long agent loops than in single-turn evaluation. If the router makes correlated errors on a particular class of inputs, those errors compound across a trajectory rather than averaging out. I would want to see per-trajectory variance, not just aggregate pass rates.
Why the license is the second-most important detail
Apache 2.0 and MIT, if delivered as planned, make Beam genuinely modifiable. Agent builders do not just run models, they surgically alter them: distilling into smaller routers, replacing the reasoning head, fine-tuning on internal tool schemas, quantizing experts selectively. Permissive licensing is what makes that work publishable and commercially usable.
Beam is, for now, a well-specified promise. The claim is interesting because it targets the right bottleneck. The verification happens when the weights, the report, and the scaffolding details are public and someone outside Reflection runs the loop.
🕒 Published: