Reflection Beam: 501B Stored, 23B Awake — A Must-Read for Self-Hosters

Reflection Beam Release: A 501B-Parameter Open-Source MoE Model

Reflection AI released Beam on October 5, a 501B-parameter open-weight MoE model (Apache 2.0, with weights to be published later this month) supporting a 1M token context window. The headlines all shout "501B," but for those who self-host and deploy models, the numbers that actually matter are hidden precisely outside the headline.

According to Reflection AI's announcement and reports from sources including TechCrunch and marktechpost.com, Beam's core selling point is not "#1 on benchmarks" but a cost ratio: reasoning capability comparable to GLM-5.2, but with reasoning compute roughly 1/3 to 1/4 of the latter. This claim is based on Reflection's own benchmark estimates, not measured dollar costs. On the day weights are released, you can absolutely reproduce and verify it yourself.

The Numbers That Actually Matter

The key to understanding Beam is distinguishing between "storage" and "activation":

Metric	Value
Total parameters	501B (all must reside in memory)
Activated parameters per token	23B (determines per-token compute)
Context	256K default, extendable to 1M after mid-training
Serving footprint	~500GB at 8-bit, ~half at 4-bit
Weight license	Apache 2.0, released later this month

MoE routing means only about 4.6% of the network is woken up per token. The inference bill follows the 23B, not the 501B. But the VRAM bill follows the full 501B — what's in the repo still counts. Until community quantizations appear, this is a multi-GPU server-class model, not something a workstation can run.

MoE (Mixture of Experts) is a sparsely activated model architecture: the model contains multiple parallel "expert" subnetworks plus a routing network. After each token enters the model, the router selects the top-scoring experts (typically 2 to 8) based on its representation, letting only those experts participate in computation while the rest stay silent. That's why Beam's 501B activates only 23B per token — about 4.6% of the network.

This design decouples "knowledge capacity" from "compute overhead": more experts mean more storable knowledge, but the per-token compute is determined solely by the activated portion. The cost is VRAM: all expert weights must be resident, even if a given token doesn't use them. Additionally, MoE places high demands on memory bandwidth and expert-parallel communication, and cross-device routing introduces extra scheduling overhead — which is why deploying MoE is more complex than a dense model of the same scale.

Comparison with Competitors (Company-Reported, Not Yet Independently Verified)

The benchmark data Reflection published is as follows, none independently verified by third parties:

• SWE-bench Verified: 80.9, versus Nemotron 3 Ultra's 70.7
• Terminal Bench v2.1: 80.1, versus GLM-5.2's 81.0, versus DeepSeek^Ad V4.1 Flash's 90.6
• DeepSWE v1.1: 44.4, trailing GLM-5.3 (61.0) and Kimi K3 (68.0)

By the benchmarks, Beam is not a clean sweep. On Terminal Bench it's roughly on par with GLM-5.2, on DeepSWE it's clearly behind, while on SWE-bench it has a substantial advantage. This confirms Reflection's positioning: not competing for "the strongest," but for "more compute-efficient at equal capability."

What You Can Do This Week

Regardless of how Beam ultimately performs, the following three things apply to any team self-hosting MoE:

1. Build an evaluation framework first. Get SWE-bench Verified and Terminal Bench running locally, connected to the open-source models you're currently serving. When Beam's weights land, swap them in and test — the "3-4x cost ratio" claim is testable, so test it.
2. Build a per-token cost model. Activated parameters (23B) determine compute cost; total parameters (501B) determine VRAM cost. Put both numbers into your infrastructure spreadsheet — this approach is universal to all MoE, not just Beam.
3. Don't plan production around unreleased weights. Weights, technical report, model card, fine-tuning tools are all coming "later this month." Build your serving path with downloadable models and treat Beam as a candidate replacement.

Engineering Details Worth Watching

According to information Reflection published, Beam's training configuration has several noteworthy aspects:

• Pre-training: 23.8T tokens, using 6,144 GB300 GPUs, taking under 4 weeks, about 48 tokens/parameter — right in the industry-converged compute-optimal ratio.
• Reinforcement learning: 10,500 GB300 GPUs for 4 weeks, over 100 million rollouts. Interestingly, browsing capability improved without mixed browsing tasks — real cross-agent-domain transfer.
• Safety alignment: an independent alignment teacher model combined with the RL teacher via multi-teacher on-policy distillation plus deliberative alignment. Specific evaluation results await the technical report.

"Compute-optimal" refers to configuring model parameter count and training token count at a specific ratio under a given training compute budget to minimize final model loss. The Chinchilla scaling law gives a classic rule of thumb of about 20 tokens per parameter; since then, the industry has widely observed ratios between 40 and 60 in large-scale training, partly because inference cost rises with parameter count, and over-training (training a smaller model on more tokens) makes the model cheaper to deploy.

Beam's 23.8T training tokens against 501B total parameters works out to about 48 tokens/parameter, right in that range. Note that MoE's "effective parameter count" should be measured by activated parameters rather than total parameters, so this ratio would be much higher if calculated using the 23B activated count — reflecting that MoE strikes a trade-off between training efficiency and inference efficiency that differs from dense models.

A New Yardstick for Open-Weight Competition

Beam's release sends a signal: the competitive metric for open-weight models is shifting from "capability" to "cost." The 501B total parameter count generates buzz, but the 23B activation is what determines who can actually afford to use it.

For self-hosters, this means the dimensions for evaluating models need updating — not just benchmark scores, but also per-token compute cost and the VRAM threshold for the full parameter set. If Reflection's 3-4x cost ratio holds up, it will change model selection logic for quite a few teams; but until weights are actually released and third-party reproduction verifies it, stay cautious.

Verify first, then adopt.

"Open-weight" and "open-source model" are not equivalent in law or practice. Open-weight typically only publishes the model parameter files after training completes; users can download, fine-tune, and self-host them, but training data, training code, and data processing pipelines are often not disclosed, making full reproduction or auditing difficult. Beam releases weights under the Apache 2.0 license, which is relatively permissive: it allows commercial use, modification, and redistribution, requiring only that the copyright notice be retained.

This differs substantively from the OSI definition of open-source software — the latter requires providing source code and build instructions. For self-hosting teams, open weights are already sufficient to support private deployment and fine-tuning; but if you need to audit data provenance, the safety alignment process, or training details, you still need to rely on accompanying materials like the technical report — which is precisely the part Beam has yet to complete.

One-line Summary

Reflection releases Beam, a 501B MoE model activating only 23B per token, touting more compute efficiency at equal capability.

Paragraph Summary

Reflection AI released Beam on October 5, a 501B-parameter open-weight MoE model supporting a 1M token context, with weights to be published later this month under Apache 2.0. Its core selling point isn't being #1 on benchmarks but a cost ratio: reasoning capability comparable to GLM-5.2, with reasoning compute about 1/3 to 1/4 of the latter. The key to understanding Beam is distinguishing storage from activation: 501B total parameters determine the VRAM threshold (~500GB at 8-bit), while 23B activated per token determines inference compute. Benchmark performance isn't a clean sweep — it leads Nemotron 3 Ultra on SWE-bench, ties GLM-5.2 on Terminal Bench, and clearly trails on DeepSWE. Reflection's self-reported data is not independently verified. For self-hosters, the recommendation is to first build an evaluation framework and per-token cost model, construct the serving path with downloadable models, and treat Beam as a candidate replacement.