Reflection Beam weights arrive with Apache 2.0 serving recipes

Reflection AI's Beam has crossed the availability boundary that mattered in its earlier launch: Hugging Face now links downloadable BF16, FP8, and NVFP4 checkpoints under Apache 2.0. The release supplies deployment and training recipes for the text-only model, while leaving its performance claims open to independent evaluation.

Key facts

• Beam has 501B total parameters and 23B active per token, with a documented maximum context of approximately one million tokens.
• Hugging Face describes the BF16 checkpoint as roughly 1 TB and NVFP4 as roughly 280 GB, before allowing for runtime state.
• The serving guide includes Transformers, vLLM, and SGLang integrations and checkpoint-specific hardware recommendations.
• Its published comparison table reports 81.6% SWE-Bench Verified for BF16 and 80.7% for NVFP4; the guide attributes these benchmark results to Reflection.

What is new since the announcement

In DeAI's October 6 coverage, Beam was announced but downloadable weights were still due later in the month. The October 17 feed captured Hugging Face's integration post linking the actual release artifacts. That is a distinct development: a builder can now evaluate a specified checkpoint instead of relying on a waitlist and a future release promise.

The guide describes Beam as a long-context coding and agentic model. It links multiple precisions, a speculative-decoding drafter, a Rust-based custom harness, and examples of supervised and reinforcement-learning adaptation. Each artifact answers a different question about using the model: how to acquire it, serve it, connect tools, or adapt behavior.

The download also enables comparisons of the released model against the announcement's claims. It does not retroactively verify those claims. A checkpoint's existence is independently observable in a way a claimed efficiency advantage is not; the latter still requires an appropriate workload and measured deployment.

Sparse computation still needs a large host

Hugging Face's architecture explanation says all experts stay in memory even though only a routed subset runs on each token. The active count therefore should not be used as the weight-memory requirement. Quantization reduces storage, but memory for caches, activations, and concurrent requests remains additional.

The guide recommends leaving headroom rather than treating the smallest configuration that can hold the weights as a production capacity plan. It distinguishes Blackwell-oriented NVFP4 from FP8 options for other hardware and gives backend-specific launch examples. Operators should match the precision to the serving engine and accelerator instead of assuming every checkpoint is equally efficient everywhere.

Beam uses sliding-window attention in most layers and global attention in the remaining layers. Hugging Face calculates 36.08 GiB of dynamic BF16 cache for a full-context sequence, compared with a larger hypothetical all-global configuration. That published architectural calculation is useful for sizing, but it is not a measurement of throughput under many simultaneous long-context users.

Tool parsing and reasoning are part of the release

The integration material describes a tokenizer response template that separates reasoning, answers, and tool calls. Its examples pass the tool schemas into response parsing so argument types can be recovered correctly. A server that simply returns unparsed text is not necessarily a drop-in replacement for an application expecting typed function calls.

Reasoning effort is another variable. The guide documents several effort settings and preserving thinking across turns. Those settings affect context use and generated output. Tests that compare one model's low-effort run with another model's longer reasoning budget may answer a useful cost question, but they do not isolate model quality alone.

Hugging Face includes small, inspectable task trials alongside the vendor benchmark table. It labels those trials as exploratory evaluations rather than benchmarks and describes failures or ambiguities in the output. That is the appropriate limit: a handful of task traces can help diagnose an integration without establishing general reliability across repositories.

Background and what remains unresolved

The model hub and open-weight explainer treat practical artifact availability as a core release question. Beam now has substantially more evidence on that front than at announcement. DeAI's self-hosting economics guide covers the next question: whether maintaining the required hardware makes sense at a team's utilization.

The original Beam article also recorded differences between some announcement benchmark figures and other published tables. This follow-up does not overwrite those historical observations or silently reconcile changed scores. The downloadable release and its current integration table are new evidence, with their own provenance and conditions.

Builders can now pin a checkpoint and run the same harness against the incumbent model on their own tasks. Useful measurements include completion rate, total tokens, elapsed time, peak memory, tool-call failures, and the selected precision. The context length should match realistic repository or document inputs rather than only a short demonstration prompt.

The concrete result of the release is more deployer control: the model can be acquired and adapted under the published license instead of accessed only through an announced service. Whether it delivers the earlier efficiency pitch remains a separate test. Downloadable artifacts make that test possible; they do not decide its outcome.