Reflection Beam: a 501B Apache-2.0 coding model that needs four Blackwells, not a datacenter
On 5 October 2026 Reflection, the Brooklyn startup founded by two ex-DeepMind researchers, announced Beam: a text-only sparse MoE with 501B total and 23B active parameters, and a 1M-token context. It's released under Apache 2.0. The Hugging Face repo reflection/Beam-1.0-501B-A23B was created on 7 October. FP8 and NVFP4 checkpoints followed on 10 October, and a DFlash2 speculative-decoding drafter on 13 October.
Why it matters if you ship software: it's a permissively licensed, US-built open model whose self-reported coding numbers are in the 80% range on SWE-bench Verified and Terminal Bench. The NVFP4 build fits on four Blackwell GPUs. The model card explicitly says Reflection "does not prohibit distillation, use of outputs to train other models, fine-tuning … quantization, merging". That clause matters if you've been reading the distillation due-diligence fine print on other open models.
What actually shipped
From the launch blog and model card:
| Item | Detail |
|---|---|
| Architecture | 501.3B total and 23.4B active parameters over 52 layers (3 dense, 49 MoE). There are 256 routed experts with top-8 routing and no shared expert (per vLLM). Vocabulary is 152k tokens, and the chat format is a modified Harmony. |
| Attention | Per vLLM's write-up, 43 layers use 512-token sliding-window attention and 9 are full-attention layers with no positional encoding (NoPE). GQA has 48 query heads and 8 KV heads. |
| Training | 23.8T pretraining tokens in under four weeks on 6,144 GB300 GPUs at 92.3% goodput. RL ran on about 10.5K GB300s for four weeks, with more than 100M rollouts across about a million environments. |
| Knowledge cutoff | 30 June 2026. The model is predominantly English. |
| Serving | Day-0 support in SGLang, vLLM (Docker image vllm/vllm-openai:reflection-beam, not yet in a numbered vLLM release at the time of writing) and TokenSpeed. There's also a hosted OpenAI-compatible API at api.reflection.ai/openai/v1. I found no published per-token price. |
Numbers that matter
Self-reported, from the model card (BF16 checkpoint, temp 0.7, top_p 0.99):
| Benchmark | BF16 | NVFP4 |
|---|---|---|
| SWE-bench Verified | 81.6% | 80.7% |
| Terminal Bench v2.1 | 80.1% | 78.4% |
| SWE-bench Pro v1 | 66.1% | 65.6% |
| DeepSWE v1.1 | 43.3% | 42.7% |
| MCP Atlas | 80.8% | 80.5% |
| GPQA Diamond | 90.6% | 89.3% |
Two things stand out. The quantization tax is small, about 1 point in most rows, but that's the vendor measuring its own quants. And the launch blog's table (updated 8 October) doesn't match the card exactly: 80.9 vs 81.6 on SWE-bench Verified, 44.4 vs 43.3 on DeepSWE. Treat every number here as ±1 point and unreplicated.
Deployment footprint, from the vLLM recipe:
| Precision | Weights on disk | Min. GPU memory (incl. 20% headroom) | Reference config |
|---|---|---|---|
| NVFP4 (routed experts only) | 294 GB | 353 GB | 4× B200/B300 or one GB200/GB300 tray (TP4); 8× H100 via Marlin |
| FP8 | 503 GB | 604 GB | 8× H200 (TP8) |
| BF16 | 1,003 GB | 1,204 GB | 8× B200/B300 (TP8) |
Illustrative sizing (my arithmetic, not a vendor number). BF16 weights are 501.3B × 2 bytes ≈ 1,003 GB, which matches the table. vLLM gives about 18 KiB of KV cache per token in FP8. Say you serve 32 concurrent coding-agent sessions at 128K tokens each: 32 × 131,072 = 4,194,304 tokens, and 4,194,304 × 18 KiB = 75,497,472 KiB ≈ 72 GiB of FP8 KV, before sharding.
On a TP4 NVFP4 deployment, where the recipe puts weights at about 73 GB per GPU, that KV is spread over four GPUs. The sliding-window layout is what keeps it this small: only 9 of 52 layers keep full-length KV. A single 1M-token context costs about 18 GiB of FP8 KV.
Throughput figures from the vLLM blog (16 October, GB200/GB300, vendor-run): batch-1 decode at 3.30 ms per step on TP8. DFlash2 speculative decoding reached 708 tok/s for a single request with acceptance length 3.7, but that was on low-entropy SPEED-Bench prompts, and the post itself warns acceptance will be lower on open-ended chat.
Treat every number here as ±1 point and unreplicated.
Technical meaning and trade-offs
It is CUDA-only and Blackwell-first. The recipe says the kernels are NVIDIA-only. Hopper works (FP8 on 8× H200, NVFP4 on 8× H100 via Marlin), but the tuned paths are Blackwell. AMD and Apple Silicon are not first-class today.
In theory it reaches Mac Studio territory. 294 GB of NVFP4 weights would fit in a 512 GB unified-memory Mac (what fits there). But NVFP4 is an NVIDIA format, and the only GGUF I found is a community conversion (DevQuasar/reflection.Beam-1.0-501B-A23B-GGUF, 16 October). I haven't verified that llama.cpp supports the architecture.
Output is grammar-constrained by default in vLLM. VLLM_BEAM_ALWAYS_CONSTRAIN_OUTPUT=0 turns it off. Know which mode you benchmarked in.
On positioning, Reflection itself says Kimi K3 is still ahead on raw capability. Beam's pitch is token efficiency: "3 to 4× less inference compute" than GLM-5.2 at similar reasoning scores, per Reflection. That's an output-token claim, not a latency claim. For the size class, see trillion-scale open MoE compared.
What I'd do
If you already run 8× H200 for another open MoE, try Beam FP8 TP8 first. It's the recipe's best measured config on H200, and it drops into an OpenAI-compatible endpoint with the beam tool and reasoning parsers.
Run your own agentic eval, not SWE-bench. Use 50 to 100 tasks from your own repos, through your own harness, and compare against what you use today. Record output tokens per solved task, since that's where the efficiency claim either holds or doesn't. Benchmark DFlash2 on your real traffic before you count on the 708 tok/s number; start with num_speculative_tokens: 7 and adaptive verification on.
Pin the image and the commit. Support is a branch image, not a release, so pin it in your deployment manifests and plan a re-validation when it lands upstream. And read the license file, not the tag: it's Apache 2.0 plus a separate usage policy, so confirm the policy doesn't conflict with your use case.
What I couldn't verify
All benchmarks are self-reported, and the blog and card disagree by up to about 1 point; the technical report is listed as "coming". No API pricing was published in the sources I read, so I can't do a $/task comparison. Hugging Face shows repo creation dates, and I didn't confirm the exact hour the weights went public. llama.cpp/GGUF and MLX support is unverified. The 3 to 4× compute-efficiency claim against GLM-5.2 is Reflection's alone.
I'll revisit when the technical report lands and someone outside Reflection posts SWE-bench Pro or Terminal Bench runs.
Sources
Primary: Reflection: Introducing Beam, Reflection's 501B open-weight model; Hugging Face model card: reflection/Beam-1.0-501B-A23B; Reflection developer docs: deployment overview. Serving: vLLM recipes: Beam-1.0-501B-A23B; vLLM blog: Serving Reflection Beam on vLLM from Day 0. Coverage: TechCrunch: Reflection debuts Beam.