Reflection Beam is an open-weight model designed for agentic coding on AWS.

Reflection AI has introduced Beam, an open-weight model for agentic coding and long-horizon tasks such as maintaining code, using tools, interpreting results, and completing multi-step workflows. At launch, Beam is available in Amazon SageMaker JumpStart in US East (N. Virginia) and US East (Ohio).

The release is aimed at developers and researchers who want more than a hosted model. Because Beam is distributed as open model weights, they can control the runtime, the deployment environment, and the customization process. Reflection has published deployment guidance for Amazon Web Services, showing two main paths: a managed Amazon SageMaker JumpStart real-time endpoint for the shortest route to a secure endpoint, and Amazon SageMaker HyperPod Inference for Kubernetes-native control over distributed GPU infrastructure.

What Reflection is releasing

Beam is a sparse mixture-of-experts model designed to resolve software issues, modify code, call tools, and act on intermediate results. In that architecture, the full model contains 501 billion parameters, while 23 billion parameters are active during a request. Reflection reports an effective context length of 1 million tokens. The 501 billion total parameters shape checkpoint storage, weight memory, sharding, and parallelism, while the 23 billion active parameters influence per-token compute.

Reflection releases Beam’s weights through Hugging Face under the Apache 2.0 license. Beam 1.0 is available in BF16, FP8, and NVFP4 checkpoint variants. These formats provide different memory footprints and hardware compatibility. Teams can deploy the model with the AWS managed JumpStart container configuration, or inspect and customize it with SGLang or vLLM inside their AWS environment.

This release fits Reflection’s stated mission to make intelligence open and accessible to all through open model weights, published research, and open source software. The company describes a full AI stack that spans models, core software, production infrastructure, and applications. Beam applies that approach to developers building software engineering and agentic systems.

Two deployment paths on AWS

The first path is a SageMaker JumpStart real-time endpoint. It packages the model, container, and endpoint behind a managed deployment workflow. This option is useful when a team wants an AWS managed model package, endpoint, and invocation API without operating Kubernetes.

The second path is SageMaker HyperPod Inference. It exposes the cluster and serving runtime so teams can control distributed execution, caching, routing, and scaling. Beam can be sourced through SageMaker JumpStart, Hugging Face Hub, or an optional Amazon Simple Storage Service mirror. Distributed workers can use the AWS managed JumpStart container or a custom SGLang or vLLM runtime.

The HyperPod path has three variants. JumpStart on HyperPod Inference keeps the AWS managed container and model configuration while running on a HyperPod cluster orchestrated by Amazon Elastic Kubernetes Service. SGLang on HyperPod Inference is for teams that need to control the serving image, runtime arguments, quantization, or distributed execution. vLLM on HyperPod Inference serves the same purpose with a different runtime.

The architecture requires sizing for checkpoint storage, weight memory, key-value cache, context length, batching, runtime overhead, and supported parallelism. The key-value cache stores attention state for generated tokens, so longer contexts and higher batching can increase memory use. Teams should define expected concurrency and latency targets, then configure replicas, caching, routing, and autoscaling from measured workload behavior.

Planning GPU capacity and prerequisites

Beam’s 501 billion total parameters require a multi-GPU deployment. BF16 has the largest weight-memory requirement, so plan a multi-node configuration with enough aggregate GPU memory for the weights and runtime overhead. For FP8 checkpoints, the guidance lists ml.p5.48xlarge with NVIDIA H100 GPUs, or ml.p5e.48xlarge and ml.p5en.48xlarge with H200 GPUs. For NVFP4 checkpoints, it lists ml.p6-b200.48xlarge with NVIDIA B200 GPUs. Teams must confirm that the released checkpoint, runtime, and parallel layout support the selected instance type.

Before deployment, an AWS account needs permissions for the chosen SageMaker deployment path and supporting AWS Identity and Access Management, networking, and storage resources. Users also need access to Beam through SageMaker JumpStart or one of the Beam 1.0 checkpoint repositories on Hugging Face, acceptance of the model terms, the AWS Command Line Interface, and Python 3.11 or later. GPU quota and capacity for a supported Beam configuration are required.

The planning checklist is practical: choose an AWS Region that supports the required accelerated instance; check service quota and available capacity; use on-demand capacity when available, or use a SageMaker training plan as a short-term reservation for scheduled work. Then calculate memory for weights, key-value cache, and runtime overhead for one replica, and confirm the estimate with a load test. Allow time for image transfer, weight download, shard loading, and runtime initialization.

Managed endpoint and HyperPod workflow

The SageMaker JumpStart real-time path is the fastest smoke test. The sample is located in the directory 01-models/ReflectionAI/Beam-1.0-501B-A23B-NVFP4 within the repository aws-samples/sagemaker-genai-hosting-examples. The script jumpstart_real_time.py supports BF16, FP8, and NVFP4 model IDs through one variant-aware command. The sample README and Python file are the source of truth for supported instance types, request schema, deployment command, and cleanup command. Setup creates a Python virtual environment and installs the sample dependency from requirements.txt.

A bounded lifecycle command can deploy an FP8 endpoint, send a short request, print the response, and clean up the endpoint, using an endpoint name such as reflection-beam-fp8-smoke. The same command supports bf16 or nvfp4; NVFP4 is the default when the variant flag is omitted. Teams that need an endpoint to remain running can use the Python functions described in the README.

For HyperPod Inference, the deployment sample README and configuration files are the source of truth for released manifests, model and image identifiers, supported runtime versions, and commands. The HyperPod sample directory is SageMakerHyperpod/reflection-beam. Before starting, configure kubectl access to an Amazon Elastic Kubernetes Service-orchestrated HyperPod cluster with the HyperPod Inference Operator and required add-ons. The cluster needs a virtual private cloud, subnets, security groups, access to the selected Beam and runtime artifacts, and local NVMe capacity if model caching is enabled. If the selected Hugging Face repository requires authentication, use an isolated access token.

For development and experimentation, teams can deploy a pinned Beam revision from Hugging Face Hub. For production deployments and model caching, the guidance says to copy the checkpoint to Amazon Simple Storage Service or Amazon FSx. HyperPod model and image caching can preload weights onto node-local NVMe storage and pre-pull the serving image.

The HyperPod Inference Gateway provides an OpenAI-compatible interface and routes requests across replicas. HyperPod Inference also supports managed tiered key-value caching and intelligent routing. These are among the Amazon SageMaker Inference capabilities introduced in 2026. When model caching is enabled, the Inference Operator warms eligible nodes with the selected weights and serving image. At runtime, the Inference Gateway and Endpoint Picker can direct each request to a suitable JumpStart-managed, SGLang, or vLLM replica.

How to choose a serving path

SageMaker JumpStart reduces container integration work while HyperPod retains control over cluster capacity, scaling, and observability. Start with SageMaker JumpStart unless the workload requires a specific inference runtime or configuration.

In SageMaker Studio, users open the JumpStart model catalog, choose Beam under All public models, select SageMaker HyperPod as the deployment target, choose the cluster and Kubernetes namespace, enter an endpoint name, and deploy. They should confirm deployment status before invoking the endpoint with the released JumpStart request schema.

SageMaker JumpStart is useful when a team wants an AWS managed container and model configuration with less runtime maintenance. The team still selects the Beam model version, supported instance type, endpoint configuration, and scaling policy.

SGLang or vLLM is useful when a team needs a specific inference runtime or configuration, such as custom runtime arguments, parsers, quantization, or parallelism. In that case, the team pins the supported runtime image, model revision, parser configuration, and distributed execution settings.

For infrastructure-as-code, the released JumpStart configuration in the HyperPod sample includes a reflection-beam-jumpstart.yaml manifest template. Teams can clone the sample repository, create local deployment.env and release.env files from examples, and use the helper hyperpod_tool.py to validate the configuration before changing the cluster. The same tool can deploy the JumpStart configuration with a timeout of 1800 seconds. The helper renders and applies the released JumpStartModel resource without writing populated release values to disk. For SGLang, teams should inspect reflection-beam-sglang.yaml before configuring the deployment.

Artifact preparation should use immutable inputs so deployment and performance results can be reproduced. Use the JumpStart model release recorded in the deployment sample. For a custom runtime, choose the BF16, FP8, or NVFP4 checkpoint, and keep the public Beam commit hash and image digest in the sample release configuration. Mirror the released image into a private Amazon Elastic Container Registry repository only when the cluster cannot pull the upstream image or the organization requires an approved registry. Keep tokens, generated secrets, private model IDs, registry credentials, and unpublished results out of the repository.

What it means next

For developers, the Apache 2.0 open-weight release means model customization happens in their own environment, subject to the infrastructure they choose. The practical trade-off is operational: a managed endpoint reduces setup, while HyperPod, SGLang, and vLLM provide more control over distributed GPU execution and serving behavior. The 501 billion total parameters and 23 billion active parameters make capacity planning the first real constraint, especially for BF16 deployments. For teams evaluating agentic coding models on AWS, the deployment guidance provides a path from a short managed test to a production Kubernetes cluster with caching, routing, and runtime customization.