Reflection released the weights for Beam on October 16, 2026, under Apache 2.0. The release follows its October 5 introduction, moving the model from a preview announcement to downloadable artifacts and deployment integrations. Reflection's release announcement confirms the change.
For teams evaluating coding agents, our reading is that the practical opportunity is control over deployment and customization. That is different from proof that a new model will make an existing workflow cheaper.
What the released model includes
The release model card describes a text-only mixture-of-experts model with roughly 501 billion total parameters and 23 billion active parameters per token. It lists a one-million-token context window and BF16, FP8 and NVFP4 formats. Use the release card for checkpoint-specific results rather than treating preview scores as final.
Reflection also describes Mirror CLI, a terminal agent harness with tool-call approvals and resumable conversations. These features provide useful evaluation surfaces, but their presence alone does not establish safe operation in your repositories. The release details explain the harness and deployment paths.
Why compute efficiency is not a cost guarantee
Reflection's earlier technical explanation estimates generation compute using active parameters and generated tokens. It explicitly excludes prompt prefill, context-dependent attention and serving overhead. Its efficiency comparison is therefore not a measured invoice for completing your tasks. The methodology and exclusions are important context for the headline claims.
Google Cloud's launch support illustrates the other half of the problem: serving long agent sessions. Its recipes use cache-aware routing and other infrastructure optimizations. The advertised gains come from customer benchmarking; the post also warns that its two hardware configurations are not directly comparable. Google Cloud's deployment analysis should be read with those qualifications intact.
A bounded evaluation before a migration
We recommend starting with a fixed set of repository tasks and a hosted endpoint before committing to infrastructure. Hold the task set, tool permissions and acceptance criteria constant across candidates.
- Count accepted changes, not just generated tokens.
- Include failed attempts, retries, elapsed time and human review in the comparison.
- Test the exact precision format and serving configuration you intend to use.
- Keep credentials scoped and require approval before consequential actions.
Only expand the pilot if it meets a predeclared quality threshold and improves the full workflow. Treat self-hosting as a separate operating decision, with its own staffing and capacity assessment, rather than an automatic consequence of downloadable weights.
The business decision
Beam warrants evaluation, not an assumed migration. Choose a narrow job, identify its acceptance test, and measure the work required to get a trustworthy result. If the workflow itself is still unclear, scope that decision before selecting a model or buying infrastructure.