On October 16, 2026, Reflection AI published the weights for Beam at reflection/Beam-1.0-501B-A23B under Apache 2.0: 501B total parameters, 23B active per token. The same name had appeared in the company's announcement blog eleven days earlier — at that point there were no weights, only a waitlist.
Repository: huggingface.co/reflection/Beam-1.0-501B-A23B
This piece covers three things: how a promised release actually landed, what the architecture and the hardware bill look like, and which traps to check before downloading. All benchmark figures below are Reflection's self-reported numbers; we have not run independent replications. Items marked as relayed or rumor are secondhand and labeled as such.
1. From promise to delivery: the eleven-day record
The timeline is part of the story, so it comes first.
October 5: Reflection's announcement blog introduced Beam at 501B total and 23B active parameters and promised weights under Apache 2.0 "this month." The actual deliverable was a blog post and a waitlist; you could sign up, but you could not download. October 8: an updated benchmark table — the scores changed, the parameter count did not. October 13: a third-party check of the Reflection organization on Hugging Face found no public repository at all. By the usual script of AI release announcements, this is where a delay or a quiet downgrade happens.
October 16: the weights landed. Hugging Face's official blog ran "Welcome Beam: a 501B open model you can own, customize, and scale," Reflection declared the model available on its own blog, and AWS shipped a SageMaker deployment path the same day. Eleven days from promise to delivery, with no verifiable artifact at any point in between. Not the fastest open-source release, but "announced, actually shipped, license intact" is a combination that has been rare in this year's large-model announcements.
The package itself checks out at the model-card level: Safetensors totalling 501B parameters, tensor types BF16/F8_E4M3/F32. As of our October 18 collection date, the card showed 603 downloads last month and stated that the model is not deployed by any Inference Provider — Hugging Face's blog names Baseten, Fireworks and Together as the serving channels, so treat the page's live status as the source of truth.
The significance is worth pinning down. It is not "yet another open model." It is that the verification loop closed: a company trained a 501B-class model — two months on several thousand high-end GPUs, by its own account — and released the entire package under Apache 2.0 with no revenue threshold attached. Whether the playbook can be repeated matters less than the fact that it happened, with a paper trail at every step.
2. Architecture: 501B total, 23B awake, and two context numbers
Beam is a sparse MoE, text in and text out — the official phrasing is "Although Beam is text-only," with other modalities reached through text representations. Fifty-two layers; each MoE layer holds 256 experts and routes each token to 8 of them, an activation rate of about 4.6%. So 501B is the ledger and 23B is the payroll.
That structure dictates the resource profile: compute scales like a 23B dense model, while memory must hold all 501B parameters of expert weights. In deployment the bottleneck tends to be VRAM and expert scheduling rather than raw FLOPs — the hardware bill in the next section grows directly out of this asymmetry.
Two context numbers, two different definitions, and they must not be merged. The effective context is 1M, stretched deliberately during midtraining. The RL rollout length was 256K — a training-time configuration, not an inference window. Collapsing both into "a 1M context window" is wrong. Separately: the server-side context ceiling and the maximum output length are unpublished. How far you can push a deployment depends on your serving stack and your memory headroom; do not treat 1M as a promise.
Reasoning depth has five levels: low, medium (default), high, xhigh, max — "how long to think" becomes a tunable parameter, and one set of weights covers both budgets. The weights bundle a DFlash2 drafter for speculative decoding: a small draft model proposes tokens, the large model verifies in one pass. The architecture list — interleaved local/global attention, fine-grained routed experts, controlled residual stream, SandwichNorm, elementwise attention gating, FP32 residual accumulation, auxiliary-loss-free load balancing — reads as stability-first engineering, and the training log backs it up: no unrecoverable loss spikes, and data-quality failures roll back to earlier checkpoints instead of restarting, per the official post.
The training recipe carries a few more readable numbers. Pre-training ran on 23.8T tokens — for scale, DeepSeek-V3 used about 14.8T and Kimi K2 about 15.5T, both encyclopedia-sourced and secondhand, useful as magnitude only. For RL, the official blog says two months on several thousand high-end GPUs; a third-party encyclopedia entry claims 10,500 GB300s running for four straight weeks. The two accounts disagree; we take the official figure and note the gap. One claim worth pausing on: Reflection says it can predict reward improvement before RL even starts, with a correlation of 0.79 against 0.46 for a best-of-n ceiling baseline — in plain terms, estimating whether the GPU bill is worth paying before burning the cards.
3. The hardware bill: 1TB, 280GB, four B200s — and no 24GB option
This is the section to remember, because it runs in the opposite direction from everything else this site has covered lately.
The BF16 full-precision checkpoint is about 1TB. NVFP4 (Blackwell-native 4-bit) compresses it to about 280GB — and Hugging Face's blog says two B200s fit it "barely, with no headroom for long context," recommending four B200s (720GB total) as the planning target. FP8 goes through AWS SageMaker: ml.p5.48xlarge (H100), ml.p5e.48xlarge and ml.p5en.48xlarge (H200); the NVFP4 variant defaults to ml.p6-b200.48xlarge (B200); BF16 needs multiple machines. JumpStart availability is currently US East (N. Virginia and Ohio) only.
The quantized floor sits lower: the smallest GGUF build is about 103GB. That sounds like "one card," but GGUF leans on CPU and system memory — 103GB is first a RAM requirement, then a VRAM question. A 64GB desktop fails at the loading step, before inference even starts. The byte math explains why: at BF16 each parameter costs 2 bytes, and 501B parameters multiply out to roughly 1TB; NVFP4 squeezes a parameter to just over half a byte to reach 280GB. That is one order of magnitude down from 1TB — but from 280GB to 24GB is another order of magnitude, and the official materials promise nothing about quality at any more aggressive quantization.
Put the three tiers side by side and the conclusion is singular: Beam is not a consumer model, not a single-GPU model, not even a "two gaming cards" model. Its practical floor is a multi-GPU data-center server. The contrast with our recent piece on Meta's open model is direct: that article covered the desktop path where a pair of Macs is enough; this one covers Beam's data-center path. Both lines are real. They serve different budgets and different machine rooms.
4. Self-reported benchmarks: three columns, zero replications
| Benchmark | BF16 | FP8 | NVFP4 |
|---|---|---|---|
| SWE-bench Verified | 81.6% | close to BF16 | close to BF16 |
| SWE-Bench Pro v1 | 66.1% | close to BF16 | close to BF16 |
| Terminal-Bench v2.1 | 80.1% | close to BF16 | close to BF16 |
| GPQA Diamond | 90.6% | close to BF16 | close to BF16 |
| AIME 2026 | 97.7% | close to BF16 | close to BF16 |
| Humanity's Last Exam (no tools) | 36.0% | close to BF16 | close to BF16 |
Only the BF16 column carries numbers, because for FP8 and NVFP4 the model card offers only the qualitative "scores close to BF16" without decimal-point deltas — we will not invent them. The standing caveat comes first: every figure is Reflection self-reported (October 8 revision), and not one has been independently replicated. The methodological problem with self-reported suites is not honesty but selectivity: the prompt set, sampling parameters, scoring method and even which benchmarks to display are all the vendor's choices. The direction is credible — 81.6% on SWE-bench and 90.6% on GPQA are numbers a vendor would not publicize lightly — but exact magnitudes only third-party runs will answer.
The vendor's own placement, relayed for completeness: Reflection says Beam's advanced reasoning matches GLM-5.2 and approaches Qwen3.8-Max, while falling short of Kimi K3; it also claims 3-4x lower inference compute than peers for comparable tasks. Vendor framing — discount accordingly.
On independent rankings: as of October 13, Artificial Analysis had no Beam entry; by our October 18 collection date it had indexed one — Intelligence Index 30, ranked second among US open-weight models. That figure is relayed from an Artificial Analysis post, secondhand, with methodology and sample unverified. Treat it as a reference line, not a verdict.
5. Ecosystem and a trap: what ollama run beam actually runs
Day-zero support: Transformers (5.20.1+), vLLM (Inferact), SGLang (RadixArk), Unsloth, Axolotl, TokenSpeed, and NVIDIA Dynamo. Reflection also shipped Mirror CLI, a Rust terminal agent harness with checkpointing and endpoint switching, tool approval, resumable sessions, parallel agent worktrees, and skills/MCP/Python extensions — it positions the surrounding network of 40+ partners as an "open operating system for agents," alongside a contest sending $10,000 in Hub credits to the best project.
Fine-tuning and safety materials, in order: the weights bundle TRL and Miles recipes; the self-distillation recipes were promised "in the coming days" and, as of October 18, have not arrived. The safety side deserves a closer look because the pre-release promise was kept: the Beam Safety Technical Report is published on Hugging Face alongside the weights. The recipe uses two teachers — a large-scale RL teacher and a dedicated safety-alignment teacher merged through multi-teacher on-policy distillation — with a three-layer safety framework and red-team prompts fed back into SFT data for adversarial iteration. Shipping a safety report with the weights remains rare in open releases; it counts in Beam's favor.
One background item: the Financial Times reported on October 10 that Nvidia is in talks to acquire or deepen its investment in Reflection — FT-reported, unconfirmed by both parties, background only, and it does not affect any factual claim in this article.
Now the trap. Ollama offered day-zero support with a limited-time free tier, but ollama run beam pulls beam:cloud — Ollama's hosted cloud inference, not local weights on your machine. The command looks identical to every local model invocation, which makes it easy to believe you are running locally. A genuinely local run requires an explicit local GGUF variant, and the 103GB RAM floor from the previous section still applies.
6. Pull it now, or wait
Pull it now if:
- You run four B200s or equivalent and want self-hosted agent inference; the FP8 path (H100/H200) is usually the cheaper entry point.
- You research quantization and serving stacks; a 501B-A23B model at 4.6% activation with three official quantized builds is ready-made material.
- You need Apache 2.0 redistribution rights; the "informational only" notes on the model card do not modify the license.
Wait if:
- You want it on consumer hardware; the 103GB RAM floor has no workaround yet — wait for more aggressive quantization.
- You only trust independent replications; every benchmark today is self-reported and the AA entry is relayed.
- You need the self-distillation recipes; promised, not shipped.
- You came for the free tier; Ollama's window is cloud compute, and when it closes, the model still will not run locally.
The takeaway is not a benchmark score. It is that the promise-to-delivery loop closed in eleven days, and the bill that came with it: 1TB of BF16, 280GB of NVFP4, four B200s recommended, 103GB of RAM for the smallest GGUF. "Open" now stretches from "runs on a gaming GPU" to "owned by a data center." Pick your path by your machine room first, then by your budget.
FAQ
Q1: Is Beam truly open source?
A1: The weights ship under Apache 2.0 — no revenue threshold, no usage gate; commercial use, redistribution and fine-tuning are all within scope. The "informational only" notes on the model card are informational and do not modify the license. On license cleanliness, this sits at the top of what this column covers.
Q2: Is the 1M context a real window I can deploy?
A2: 1M is the effective context, stretched during midtraining; the RL rollout length was 256K, which is a training configuration. The server-side context ceiling and maximum output are unpublished, so your real limit depends on your serving stack and memory headroom — even four B200s leave little slack for long context, per Hugging Face's blog.
Q3: Can my PC run Beam?
A3: Realistically, no. BF16 is about 1TB, NVFP4 about 280GB, and Hugging Face recommends four B200s; the smallest GGUF is about 103GB and demands RAM first, VRAM second. Consumer 24GB cards and 8GB laptops sit outside the gate. For a taste, use Ollama's cloud route or the HF-named channels: Baseten, Fireworks, Together.
Q4: Should I trust the self-reported benchmarks?
A4: As direction, yes; as magnitude, hold. Every figure is Reflection self-reported with no independent replication, and FP8/NVFP4 get only a qualitative "close to BF16." Artificial Analysis has indexed Beam (Intelligence Index 30, second among US open-weight models), but that is a relayed, secondhand figure. Test on your own task set before committing budget.
Q5: Does ollama run beam run locally?
A5: No. It pulls beam:cloud, Ollama's hosted cloud inference, and the limited-time free tier applies to the cloud route. A local run needs an explicit local GGUF variant, roughly 103GB of RAM to load, and VRAM on top.
Related reading
- 42B Active, 816B to Load: Why It Still Needs Two Macs: 42B Active, 816B to Load: Why It Still Needs Two Macs
- Says #1, Its Own Table Says #2: Picking a 24GB Model: Says #1, Its Own Table Says #2: Picking a 24GB Model
- 4GB VRAM Holds 2.8 Trillion Parameters: 4GB VRAM Holds 2.8 Trillion Parameters