Reflection Beam is an open-weight model for agentic coding: a 501-billion-parameter mixture-of-experts system that, according to AWS’s deployment guide, keeps 23 billion parameters active per token. It is being offered for private, multi-step software work under your own runtime and data boundary. It is not offered as the model that tops every chart.
A mixture-of-experts model is a specialist bench, not a bigger brain. A router sends each token to a few specialist subnetworks, so you store the whole roster and pay compute only for the ones that fire. Total parameters drive checkpoint storage, weight memory, and how you split the model across GPUs. Active parameters drive the compute on every token. Forget the weights, the cache, and the concurrency, and a sparse model that looks cheap in a formula gets expensive in a cluster.
Reflection frames the advantage as intelligence per token rather than a peak score. For a leader deciding where coding agents belong in the engineering org, that is a more useful sentence than most launch copy. It is also a sentence you should not buy on faith.
What you are actually being offered
Beam is built for long-horizon software work: maintain a codebase, change it, call tools, read the intermediate result, and keep going. That is a different job from one prompt and one reply. The model has to hold a plan across steps, notice when a test failed, and decide what to try next.
Open weights are the other half of the offer. A closed API rents you the behavior. Weights, once you actually have them, let your team pick the runtime, the region, the data boundary, and how far you are willing to quantize.
The AWS guide says those weights are on Hugging Face under Apache 2.0, in three checkpoints: BF16, FP8, and NVFP4. The repository names it gives are reflection/Beam-1.0-501B-A23B, plus FP8 and NVFP4 variants of that name. DataCamp, covering the announcement, described an Apache 2.0 drop of weights, a technical report, a model card, and tooling for later in October 2026. Read the license file on the checkpoint card before you treat “open” as settled. A deployment guide and an announcement writeup are not the same document.
Three context numbers, not one slogan
Reflection reports an effective context of 1 million tokens. Effective, here, is Reflection’s claim about usable context. The AWS post did not measure that figure, and it does not define the word. DataCamp attributes the extension to midtraining (the stage between initial pretraining and later reinforcement learning) on code repositories, long-horizon tasks, and long-form documents.
The reinforcement-learning rollouts that taught agentic behavior topped out at 256, 000 tokens. That is a quarter of the headline. DataCamp is explicit: the agent skills were learned well short of the million-token figure.
A third number belongs only to the hosted product. DataCamp puts the beta API cap at 262, 144 tokens for input plus output, with output itself capped at 131, 072. Do not paste that cap onto the open weights. Self-hosted context on SageMaker is a fourth number nobody in this material has published. It will depend on the checkpoint, the KV cache (the memory that holds attention state while the model generates), and how much GPU memory you actually reserved.
A long window is not the same as class-leading long-context quality. On LongBench v2, DataCamp’s Reflection-reported scores sit in a tight band: Beam 65.5, the model it calls Qwen 3.8-Max at 66.3, and GLM 5.2 at 64.0. That margin is too small to rank. On AA-LCR the gap is real: Beam 79.3 against Kimi K3 at 88.7. A long window is a feature. You still cannot skip a retrieval design.
Where the scores help, and where they do not
Every comparison below is vendor-reported. DataCamp says Reflection sourced rival scores from Artificial Analysis and DataCurve. Names below follow DataCamp’s spelling (Qwen 3.8-Max, GLM 5.2, GLM 5.3, Kimi K3, Inkling, DeepSeek V4.1 Flash) and should be checked against a model card before anyone puts them in a board slide. Read the chart as a company’s chart until a technical report or an independent eval is in hand.
On the coding tests Reflection chose to feature, the result is mixed, and close to GLM 5.2 rather than a clean win.
- SWE-bench Verified: Beam 80.9, Inkling 77.6, Nemotron 3 Ultra 70.7. GLM 5.2 is not in this readout.
- SWE-bench Pro v1: Beam 65.5, GLM 5.2 62.1, Qwen 3.8-Max 67.7. Close to GLM on the upside, behind Qwen on the same test.
The harder agentic work is less kind. DataCamp places Beam behind Kimi K3, GLM 5.3, and DeepSeek V4.1 Flash on the toughest agentic coding tasks. On DeepSWE, that writeup did not publish Beam’s score, so a gap versus the leader is not interpretable and does not belong in a decision memo.
Search is the weak spot. With context management, BrowseComp is 77.4 and DeepSearchQA is 80.1, against Kimi K3 at 91.2 and 95.0.
Reasoning without tools follows the same pattern. On HLE, Beam’s 36.2 trails GLM 5.2 at 40.5 and sits further back from Kimi K3 at 46.9. That 36.2 is the comparison-table score. It is not the efficiency-chart figure below.
Tool use splits, which matters if the job is finishing a workflow rather than chatting.
- AutomationBench, public set: Beam 37.0, ahead of GLM 5.2 at 26.2, behind Kimi K3 at 46.7 and DeepSeek V4.1 Flash at 54.8.
- MCP Atlas: Beam 78.7 against GLM 5.2 at 77.8 is a near-tie, not a ranking. The gap that matters is Qwen 3.8-Max at 84.5.
- τ³-bench, banking: Beam 38.0 against 37.1 for both GLM 5.2 and Kimi K3 is noise. Qwen 3.8-Max at 55.2 is not.
The pattern is consistent enough to plan around. Beam looks like a serious coding model in the GLM 5.2 neighborhood on the software tests Reflection featured, and like a mid-pack agent once the task gets harder, more open-ended, or dependent on search. Reflection writes GLM-5.2. DataCamp writes GLM 5.2. Same comparison set, not two models.
The efficiency claim is an estimate, not an invoice
“Comparable to GLM 5.2” means efficiency-adjusted, not raw parity. On HLE without tools the table is 36.2 against 40.5. Say that in the architecture review, or someone will approve the wrong sentence.
Reflection’s headline is scores comparable to GLM-5.2 at 3-4× less inference compute, with a wider gap against models above 2 trillion parameters, including the one DataCamp calls Qwen 3.8-Max. The chart numbers DataCamp actually prints are not that GLM comparison. They show Beam at 35.3 percent, at an estimated 0.82 PFLOP per attempt, against Inkling at about 4.1 PFLOP for roughly 26 percent and Nemotron 3 Ultra at about 1.9 PFLOP for about 21 percent.
Do not merge the two HLE figures. 36.2 is the no-tools comparison score. 35.3 percent is the efficiency-chart result. The materials do not say whether the difference is tools, a subset, or a different attempt budget.
DataCamp says the compute estimate is twice the active-parameter count, times the average tokens generated per attempt. It does not publish that token count, so an outsider cannot recompute 0.82 from the formula alone. The estimate also leaves out prompt processing, the extra attention cost of long context, and serving overhead. It favors sparse models, because most of the roster never clocks in.
That is not a SageMaker price. It is not tokens per second.
There is a controllable reasoning-effort setting that trades completion length for performance. Reflection says early reinforcement learning shortened completions while scores rose, and that longer completions returned as agentic skill improved. Length is a cost lever. Treat it that way when you budget an agent that retries.
Text only, even when the demo looks clever
Beam does not see. Reflection says it is text-only. Screenshots, design files, and PDFs get in only after something converts them to text, OCR included. If a coding workflow assumes vision (a UI diff, a whiteboard photo, a design export), you are adding a preprocessor, not flipping a switch.
One training result shows how a text model papers over that limit. Reflection reports that during reinforcement learning on reasoning, software engineering, and terminal tasks, browsing scores rose even though browsing tasks were not in the mix. Given web access, Beam searched for other models, queried them, and used OCR APIs. That is a dependency. Your agent’s eyes may be someone else’s API, with someone else’s latency, price, and data policy.
Three ways to run it, and the bill that follows
AWS’s guide is a deployment document, not a bake-off. The choice is how much infrastructure you want to own.
SageMaker JumpStart real-time endpoints are the managed door. The model and container are packaged, you invoke over HTTPS, and nobody on your team has to operate Kubernetes. At launch, that listing is in US East (N. Virginia) and US East (Ohio). The launch note is about JumpStart. It does not establish catalog availability anywhere else, and it does not settle whether a self-managed pull is limited the same way.
SageMaker HyperPod is the control door: an EKS cluster you operate when you need the data boundary and distributed GPU control. For a smoke test, a pinned Hugging Face revision is enough. For production, the guide says copy the checkpoint to S3 or FSx. The third path is a custom SGLang or vLLM runtime on that same cluster, if you need a specific image, parser, quantization setting, or parallel layout. The sample README in AWS’s hosting-examples repository is the source of truth for the command, the request schema, and supported instances. A blog recap is not.
Precision is a budget decision disguised as a file format. BF16 is the fullest of the three and the largest in weight memory. FP8 is an 8-bit floating-point checkpoint. NVFP4 is a 4-bit NVIDIA format with the smallest footprint of the set. The guide does not give BF16 an instance recommendation as tidy as the others, so plan a multi-node layout with room for weights, KV cache, batching, and runtime overhead. For FP8 it points to ml.p5.48xlarge on NVIDIA H100s, or ml.p5e.48xlarge and ml.p5en.48xlarge on H200s. NVFP4 is aimed at ml.p6-b200.48xlarge with B200s. Those IDs come from the guide, not from an independent capacity check. Confirm that the released checkpoint, the runtime, and the parallel layout support the box you reserve. Lower precision cuts memory. It can also nick quality. The guide tells you to recheck outputs after you change it, and no quality deltas are published.
Capacity is the unglamorous gate. You need GPU quota, time for image transfer and shard loading, and a plan for when on-demand capacity is gone. The guide mentions a SageMaker training plan as a short-term reservation for scheduled work. When the experiment ends, delete the endpoint, the cluster, the caches, the mirrors, the load balancers, the logs, the temporary roles, and any captured prompts. A forgotten endpoint is a very patient invoice.
Then measure the thing the formula skipped. Record request success rate, p50 and p95 time to first token, time per output token, end-to-end latency, and aggregate output tokens per second. Stamp each run with model version, image digest, instance type, precision, context length, parallelism, serving arguments, cache state, and how many times you repeated the test. A smoke prompt is a pulse check. It is not evidence of coding quality.
Training color, and a safety gap
Reflection’s training account is single-source. Company figures, unaudited: high-compute reinforcement learning on 10, 500 NVIDIA GB300 GPUs for four weeks, more than 100 million rollouts, and sandbox use on the order of a billion launches. The same post wobbles between “one million” and “nearly one million” environments. Launches are not distinct environments, and the company’s belief that this was among the largest open-lab RL runs is its characterization, not an independent ranking.
Those GB300s are not the H100s, H200s, and B200s in the serving guide. Do not merge the fleets in a capacity plan, and do not assume a training cluster’s incident history predicts your inference latency. What you can test is narrower. A lot of the claimed spend went into multi-step environments, not only into a bigger pretraining run. Training-data detail beyond “mostly synthetic, plus vendor and open-source data” is not here.
Safety detail is thinner. DataCamp says Reflection trained a separate safety model from the same pretrained checkpoint and blended it into the reinforcement-learning model. The jargon is multi-teacher on-policy distillation. The plain version is that a second model’s behavior was distilled in, under principles grouped into tiers. The tier contents are not public in this material, and the safety evaluations are described as planned for release, not published. For a risk review, “planned” is not a control.
Questions worth asking before you provision the GPUs
- Can we actually run this ourselves, or is “open” a brochure word?
The AWS guide says the weights are released under Apache 2.0, in three precisions, and listed in JumpStart in Northern Virginia and Ohio only. Confirm the license file on the checkpoint. An announcement writeup still had that drop in the future tense for later October 2026. Once you have the weights, you choose the runtime and the data boundary, and quota, capacity, upgrades, and the bill are yours.
- Does a million-token context mean the agent was trained to work at that length?
No. Reflection’s 1 million figure is an effective context after midtraining, and the AWS post neither measures it nor defines “effective.” Agentic behavior was learned at a 256, 000-token rollout cap, the hosted beta API is a separate smaller limit, and self-hosted context on your GPUs was not measured in the deployment guide.
- Is Beam as strong as GLM 5.2?
On some vendor-reported coding tests, it is close: SWE-bench Pro has Beam at 65.5 and GLM 5.2 at 62.1, while Qwen 3.8-Max, as DataCamp styles it, is ahead at 67.7. On HLE without tools Beam trails, 36.2 to 40.5, and on the hardest agentic coding and search tests it sits behind the leaders in that writeup. “Comparable” is an efficiency claim, not raw parity.
- Will 3-4× less compute show up as a smaller SageMaker bill?
Not automatically. The 3-4× figure is Reflection’s claim against GLM 5.2. The printed chart compares Beam with Inkling and Nemotron, and the estimate skips prompt processing, long-context attention, and serving overhead. The bill you can defend is the one you measure: time to first token, time per output token, and tokens per second on your instance and precision.
- Can a coding agent on Beam read screenshots and design files?
Not natively. Reflection says the model is text-only, so images and documents get in only after conversion to text, including OCR. If the workflow assumes vision, budget for that step and for the data it sends elsewhere.
- What should we trust it with first?
A bounded coding workflow you already know how to score: multi-step patches, tool calls, intermediate results a human can check. Not open-web research, not multimodal review, and not a company-wide rollout on a vendor chart. No public safety-eval results are in hand yet.
The practical read for a CIO is narrower than the launch language. Beam is a candidate for private, tool-using software work where you want the weights and the data boundary under your control. It is a weaker candidate if the job is browsing the public internet, reading a screen, or beating the current agent leaders on the hardest tickets. The useful version of this product is a pull-request queue with a known failure rate, not an agent with a million-token imagination and an unmeasured cache.
Pick one class of tickets you already measure. Serve one precision on one instance family. Score it against the assistant your engineers use today, and keep the latency and retry numbers beside the quality numbers. Vendor PFLOPs will not survive contact with your KV cache. Your tickets might.
Same catalog, different model
If you are already weighing JumpStart as the managed door for open weights, this is the neighboring listing worth a look before you lock a runtime.