Introducing Reflection Beam: an open-weight model for agentic coding on AWS

16 October 2026 7 min read هدهد تك | Hudhud Tech

Reflection AI has launched Beam, an open-weight model designed for agentic coding and long-horizon tasks, which include code maintenance, tool utilization, result interpretation, and multi-step workflow completion. The open-weight release empowers developers and researchers with control over runtime, deployment environments, and customization processes.

This article outlines Reflection’s vision and provides guidance on deploying Beam on AWS. You can begin with an Amazon SageMaker JumpStart real-time endpoint for a fully managed experience. For those requiring Kubernetes-native control over distributed GPU infrastructure, Amazon SageMaker HyperPod Inference can be utilized alongside JumpStart, SGLang, or vLLM. Additionally, we discuss how Beam’s 501 billion total parameters influence checkpoint storage, weight memory, sharding, and parallelism, while its 23 billion active parameters affect per-token computation.

At its launch, Beam is accessible via Amazon SageMaker JumpStart in the US East (N. Virginia) and US East (Ohio) regions.

Reflection’s vision for open intelligence

Reflection aims to make intelligence open and accessible to all through open model weights, published research, and open-source software. Its full AI stack encompasses models, core software, production infrastructure, and applications. Beam exemplifies this approach for developers engaged in software engineering and agentic systems.

About Reflection Beam

Beam is a sparse mixture-of-experts model designed to address software issues, modify code, call tools, and act on intermediate results. It features 501 billion total parameters and 23 billion active parameters, with Reflection reporting an effective context length of 1 million tokens.

Beam’s weights are available through Hugging Face under the Apache 2.0 license. The model is offered in BF16, FP8, and NVFP4 checkpoint variants, each providing distinct memory footprints and hardware compatibility. Users can deploy the model using the AWS managed JumpStart container configuration or customize it with SGLang or vLLM in their AWS environment.

Understand the deployment architecture

Select the serving path that aligns with your control and scaling requirements.

Begin with a SageMaker JumpStart real-time endpoint for an AWS-managed model package, endpoint, and invocation API without the need for Kubernetes operations.
Opt for JumpStart on HyperPod Inference when you require AWS-managed container and model configuration on a HyperPod cluster orchestrated by Amazon Elastic Kubernetes Service (Amazon EKS).
Utilize SGLang or vLLM on HyperPod Inference when you need to manage the serving image, runtime arguments, quantization, or distributed execution.
Size the deployment based on checkpoint storage, weight memory, KV cache, context length, batching, runtime overhead, and supported parallelism.
Define expected concurrency and latency targets, then configure replicas, caching, routing, and autoscaling based on measured workload behavior.

The JumpStart real-time path integrates the model, container, and endpoint within a managed deployment workflow. The HyperPod path allows for control over distributed execution, caching, routing, and scaling.

The following diagram illustrates the components utilized in the HyperPod path. Beam can be sourced via SageMaker JumpStart, Hugging Face Hub, or an optional Amazon Simple Storage Service (Amazon S3) mirror. Distributed workers utilize the AWS managed JumpStart container or a custom SGLang or vLLM runtime.

Architecture diagram showing Beam sourced from SageMaker JumpStart, Hugging Face Hub, or an optional Amazon S3 mirror into Amazon SageMaker HyperPod Inference, with the Inference Operator managing local model and image caching and the Inference Gateway and Endpoint Picker routing requests to distributed JumpStart, SGLang, or vLLM workers monitored by Amazon CloudWatch.

Figure 1: Distributed Beam deployment with Amazon SageMaker HyperPod Inference

Prerequisites

To get started, you will need:

An AWS account with permissions for your chosen SageMaker deployment path and its supporting AWS Identity and Access Management (IAM), networking, and storage resources.
Access to Beam via SageMaker JumpStart or one of the Beam 1.0 checkpoint repositories on Hugging Face.
Acceptance of the model terms, the AWS Command Line Interface (AWS CLI), and Python 3.11 or later.
GPU quota and capacity for a supported Beam configuration.

Plan and obtain GPU capacity

Given Beam’s 501 billion total parameters, a multi-GPU deployment is necessary. The BF16 variant has the highest weight-memory requirement, so plan for a multi-node configuration with sufficient aggregate GPU memory for weights and runtime overhead. For FP8, use ml.p5.48xlarge with NVIDIA H100 GPUs or ml.p5e.48xlarge and ml.p5en.48xlarge with H200 GPUs. For NVFP4, use ml.p6-b200.48xlarge with NVIDIA B200 GPUs. Ensure that the released checkpoint, runtime, and parallel layout are compatible with the selected instance type.

Calculate memory requirements for weights, KV cache, and runtime overhead for one replica, then validate the estimate with a load test.
Select an AWS Region that supports the necessary accelerated instance.
Check service quotas and available capacity for the chosen instance type. Utilize on-demand capacity when available, or consider a SageMaker training plan for short-term reservations.
Account for time needed for image transfer, weight download, shard loading, and runtime initialization.

Path 1: Get started with a SageMaker JumpStart real-time endpoint

Begin with a JumpStart real-time endpoint for the quickest route from the model catalog to a managed HTTPS endpoint. The sample supports BF16, FP8, and NVFP4 model IDs through a single variant-aware command. Its README and Python file provide details on supported instance types, request schema, deployment command, and cleanup command.

Clone the sample repository.

git clone https://github.com/aws-samples/sagemaker-genai-hosting-examples.git

Navigate to the SageMaker JumpStart deployment sample directory.

cd sagemaker-genai-hosting-examples/01-models/ReflectionAI/Beam-1.0-501B-A23B-NVFP4/

Create and activate a Python virtual environment.
```
python3 -m venv .venv
source .venv/bin/activate
```

Install the sample dependencies.

python -m pip install -r requirements.txt

Execute the bounded deployment, invocation, and cleanup lifecycle for FP8.
```
python jumpstart_real_time.py \
--variant fp8 \
--endpoint-name reflection-beam-fp8-smoke
```
This command deploys the FP8 endpoint, sends a brief request, prints the response, and cleans up the endpoint. You can use bf16 or nvfp4 to select a different checkpoint variant; NVFP4 is the default if --variant is omitted. Refer to the Python functions in the README for keeping an endpoint running.

Path 2: Deploy with SageMaker HyperPod Inference

Utilize HyperPod Inference when you require Kubernetes-native control over distributed GPU infrastructure. You can either use the AWS managed JumpStart container configuration or deploy Beam with SGLang or vLLM. The HyperPod Inference deployment sample README and its configuration files serve as the authoritative source for released manifests, model and image identifiers, supported runtime versions, and commands.

Before starting, configure kubectl access to an EKS-orchestrated HyperPod cluster with the HyperPod Inference Operator and necessary add-ons. Additionally, ensure you have the cluster’s virtual private cloud (VPC), subnets, security groups, access to the selected Beam and runtime artifacts, and local NVMe capacity if model caching is enabled. Use an isolated Hugging Face access token if authentication is required for the selected repository.

For development and experimentation, deploy a pinned Beam revision from Hugging Face Hub. For production deployments and model caching, copy the checkpoint to Amazon S3 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 offers an OpenAI-compatible interface and routes requests across replicas. HyperPod Inference also supports managed tiered KV caching and intelligent routing. These features are part of the Amazon SageMaker Inference capabilities introduced in 2026.

The next diagram illustrates the model preparation and runtime request flow. When model caching is enabled, the Inference Operator warms eligible nodes with the selected weights and serving image. During runtime, the Inference Gateway and Endpoint Picker can direct each request to an appropriate JumpStart-managed, SGLang, or vLLM replica.

Detailed HyperPod flow showing the Inference Gateway, Endpoint Picker, routing signals, Inference Operator, host-local model cache, and JumpStart-managed, SGLang, or vLLM replicas.

Figure 2: HyperPod model caching and request routing

Prepare deployment artifacts

Utilize immutable inputs to ensure reproducibility of deployment and performance results.

Use the JumpStart model release documented in the deployment sample.
Select the BF16, FP8, or NVFP4 checkpoint for a custom runtime.
For a custom runtime, retain the public Beam commit SHA and image digest in the sample release configuration.
Mirror the released image into a private Amazon Elastic Container Registry (Amazon ECR) repository only if your cluster cannot pull the upstream image or if your organization mandates an approved registry.
Keep tokens, generated secrets, private model IDs, registry credentials, and unpublished results out of the repository.

Choose a serving path

Begin with SageMaker JumpStart unless your workload necessitates a specific inference runtime or configuration.

Serving path	Use it when	What you manage
SageMaker JumpStart	You prefer an AWS-managed container and model configuration with reduced runtime maintenance.	Select the Beam model version, supported instance type, endpoint configuration, and scaling policy.
SGLang or vLLM	You require a specific inference runtime or configuration, such as custom runtime arguments, parsers, quantization, or parallelism.	Pin the supported runtime image, model revision, parser configuration, and distributed execution settings.

Deploy with SageMaker JumpStart

SageMaker JumpStart minimizes container integration efforts, while HyperPod retains control over cluster capacity, scaling, and observability.

In SageMaker Studio, open the JumpStart model catalog.
Under All public models, select Beam.
Choose SageMaker HyperPod as the deployment target.
Select the cluster and Kubernetes namespace.
Enter an endpoint name, then click Deploy.
Verify the deployment status before invoking the endpoint using the released JumpStart request schema.

For an infrastructure-as-code workflow, utilize the released JumpStart configuration in the HyperPod sample. You can review the reflection-beam-jumpstart.yaml manifest template prior to configuring the deployment.

Clone the sample repository and navigate to the HyperPod Beam directory.