Reflection AI has introduced Beam, an open-weight model for agentic coding and long-horizon tasks. An AWS article describes its focus as maintaining and modifying code, resolving software issues, calling tools, interpreting intermediate results, and completing multi-step workflows. At launch, Beam is available through Amazon SageMaker JumpStart in US East (N. Virginia) and US East (Ohio).

Model scale and access

Beam uses a sparse mixture-of-experts architecture with 501 billion total parameters and 23 billion active parameters. Reflection reports an effective context length of one million tokens; the supplied evidence provides no independent validation. Total parameters determine checkpoint storage and affect weight memory, sharding, and parallelism, while active parameters influence per-token compute. The smaller active count therefore does not remove the need to plan for the full model's weights.

Reflection releases Beam 1.0 weights on Hugging Face under Apache 2.0, with BF16, FP8, and NVFP4 checkpoints offering different memory footprints and hardware compatibility. The company describes open weights, published research, and open source software as part of its mission to make intelligence open and accessible. Access to the weights gives developers control over runtime, deployment environment, and customization.

Three serving options

• JumpStart real-time endpoint: managed serving without operating Kubernetes.
• JumpStart on HyperPod Inference: an Amazon EKS-orchestrated cluster with AWS-managed container and model configuration.
• SGLang or vLLM on HyperPod Inference: control over serving images, runtime arguments, quantization, and distributed execution.

The JumpStart endpoint sample supports all three checkpoint variants and defaults to NVFP4. Its demonstrated FP8 command deploys an endpoint, sends a short request, prints the response, and deletes the endpoint. The sample README also supplies Python functions for keeping an endpoint running, distinguishing the demonstration's cleanup behavior from a persistent deployment.

Capacity and prerequisites

The article lists an AWS account with suitable SageMaker, IAM, networking, and storage permissions; model access and acceptance of its terms; AWS CLI; Python 3.11 or later; and supported GPU quota and capacity. HyperPod additionally requires kubectl access to an EKS cluster, the HyperPod Inference Operator and add-ons, network configuration, and artifact access. Model caching also requires local NVMe capacity.

Beam requires multiple GPUs, and the article recommends planning a multi-node BF16 configuration. For FP8, it lists ml.p5.48xlarge with H100 GPUs or ml.p5e.48xlarge and ml.p5en.48xlarge with H200 GPUs. For NVFP4, it lists ml.p6-b200.48xlarge with B200 GPUs. Suitability depends on checkpoint, runtime, and parallel-layout compatibility. Planning must account for weights, KV cache, runtime overhead, regional instance support, quotas, and load testing. Capacity can come from on-demand resources or a SageMaker training plan.

Artifacts, deployment checks, and measurement

HyperPod can obtain Beam through JumpStart, Hugging Face Hub, or an optional S3 mirror. AWS recommends pinned revisions for development and copying checkpoints to S3 or FSx for production and caching. HyperPod can preload weights onto node-local NVMe and pre-pull serving images. Its Inference Gateway offers an OpenAI-compatible interface and routes requests across replicas; managed tiered KV caching and intelligent routing are also supported.

Deployment uses the SageMaker Studio JumpStart catalog or sample configurations and manifests. The article recommends immutable model releases, checkpoint revisions, and image digests. Helpers validate configurations and apply manifests without writing populated release values to disk. The custom-runtime helper has a fixed timeout and failure diagnostics. A SGLang/vLLM smoke test selects a ready worker, temporarily forwards a port, checks health, sends a request, and closes the forwarding connection.

AWS recommends repeated representative coding and tool-use tests at expected concurrency, recording model and runtime configuration. Measures include request success rate, p50/p95 time to first token, time per output token, end-to-end latency, and aggregate output tokens per second. Measurements should guide batching, KV cache, replicas, autoscaling, and caching; precision or quantization changes should trigger another output-quality check. The supplied evidence contains no measured benchmarks, costs, or model comparisons. Test resources and unused artifacts should be deleted to avoid continuing charges.