Reflection Beam 1.0 is open, but not the cheapest coding API

FuturPulse analysis · 23 October 2026

Reflection Beam 1.0 has 501.3 billion parameters, 23.4 billion active per token and a 1-million-token context window, according to Reflection’s published model files and model information. OpenRouter lists the model at $0.25 per million input tokens and $1 per million output tokens. That makes Beam an open-weight option, not the lowest-cost managed API in this comparison.

What is Reflection Beam 1.0?

Reflection Beam 1.0 is a text-only mixture-of-experts model, or MoE. An MoE contains many specialist neural-network blocks but activates only some of them for each token. A token is a small piece of text that the model reads and that an API provider bills.

Reflection describes Beam as a sparse model with 501 billion total parameters and 23 billion active parameters. The company positions it for coding, reasoning and agentic work. Agentic work means a model completes several steps, often by reading files, calling tools or changing code.

The active count describes the parameters used for each token. The total count describes the complete weight set that a self-hosted service must store. Beam therefore has the arithmetic profile of a much smaller model but the storage burden of a much larger one.

That distinction matters when comparing model size. Beam does not become a 23-billion-parameter model simply because that many parameters are active at once. The complete weight set still has to be loaded before the model can answer.

Beam is open-weight rather than merely available through an API. Its published formats include BF16, FP8 and NVFP4, and the model is distributed under Apache 2.0 terms. That licence supports commercial use, modification and redistribution, but it does not remove the cost of storing or serving the weights.

Beam is also text-in and text-out. That makes it suitable for code, tool calls, logs, documents and structured outputs, but not for image or audio input. The model’s intended use is therefore closer to software engineering and document automation than to a general multimodal assistant.

Is Beam the budget coding choice?

No, if budget means the lowest listed API bill. Beam costs more than the MiniMax M3.1 Flash and DeepSeek V4.1 Flash options in the comparison below. Its different benefit is downloadable Apache-2.0 weights combined with a documented million-token context window.

Price is only one part of the decision. A cheaper token rate can lose its advantage when a model needs more retries, longer reasoning or additional human correction. A more expensive model can make sense when each successful repository change saves substantial engineering time.

The alternatives also carry different evidence. MiniMax appears in the comparison as an API option, but this article does not establish a released open-weight licence for it. DeepSeek appears with model weights in the marketplace comparison, but the table does not verify its licence against an original DeepSeek release page.

Beam’s Apache-2.0 terms are stated in its provider material. That makes it the only option in this table whose open-weight licence is directly established here. It does not make Beam the cheapest choice, or prove that it will perform best on a particular codebase.

How do API bills compare?

For the same request shapes, Beam costs $9.50 per 1,000 larger agent steps. That calculation uses OpenRouter’s published list prices: 30,000 input tokens and 2,000 output tokens per step. It excludes retries, cached-input discounts and fees charged by tool providers.

The table uses three practical request shapes. A chat turn is a short exchange. A retrieval-augmented generation, or RAG, answer includes source material in the prompt. An agent step represents a larger coding or automation action with repository context and a longer response.

FuturPulse calculation from the published OpenRouter list prices. A chat turn is 1,000 input plus 500 output tokens. A RAG answer is 8,000 input plus 500 output tokens. An agent step is 30,000 input plus 2,000 output tokens.

At the stated rates, MiniMax saves $3.80 per 1,000 agent steps compared with Beam. DeepSeek saves $3.23. Those savings matter for continuous code review, test repair or document-processing queues. They matter less for a small team making a few high-value repository changes each day.

The table is a rate comparison, not a quality comparison. It assumes every model receives the same input and produces the same output. Real bills change when one model needs more context, longer reasoning or more attempts to complete the job.

What does a 1-million-token window buy you?

Beam’s context limit can hold a large repository, logs, tool results and earlier messages in one request. Context is the text the model can consider while producing an answer. A larger window reduces the need to summarise long material, but it does not mean every request should contain a million tokens.

At Beam’s listed input rate, an uncached million-token prompt costs $0.25 before output begins. Output costs four times as much per token as input at the listed rate. That means a long reasoning trace can dominate an agent bill even when the initial prompt is unchanged.

Long context also consumes memory. The key-value cache stores attention state so later tokens can be generated without recomputing the entire request. A larger cache can support longer conversations, but it takes accelerator memory alongside the model weights.

vLLM reports that only nine of Beam’s 52 layers retain full-sequence key-value cache data. Its estimate is about 18 GiB of FP8 cache for a full million-token context before sharding. That is an implementation estimate, not a promise that every deployment will fit the same workload.

The architecture uses sliding-window attention in most layers and full-context attention in the remaining layers. For readers choosing an API, the practical point is simple: a large context limit does not remove memory costs. It changes where those costs appear.

Can you self-host Beam?

Yes, but Reflection’s documented starting point is four NVIDIA B300 SXM GPUs connected by NVLink on a Linux amd64 host. That is a data-centre deployment, not a normal workstation or a single consumer graphics card.

The serving guide requires Docker, the NVIDIA Container Toolkit and access to Beam’s NVFP4 model and DFlash2 drafter. DFlash2 is an additional model component used for speculative decoding, a method that drafts several possible tokens before the main model verifies them.

The smallest official Beam download is 273 GiB in NVFP4. Reflection lists the FP8 checkpoint at 468.72 GiB and the BF16 checkpoint at 933.81 GiB. These are download sizes, not a guarantee that exactly the same amount of GPU memory will run a production service.

Arithmetic from the published weights puts uncompressed 16-bit parameters at about 1,002.5 GB, 8-bit parameters at 501.3 GB and nominal 4-bit parameters at 250.6 GB. The published files total about 1,002.7 GB on disk. These figures describe weights only, not a complete serving system.

The official NVFP4 download is larger than simple 4-bit arithmetic because model packages include format-specific data and use GiB for file sizes. The difference is a reminder that a quantisation label does not predict the exact download size.

The storage number is only the floor. A service also needs memory for the key-value cache, runtime operations, batching and the operating system. Longer prompts increase the cache requirement, while concurrent users increase the active state that must be held at once.

A self-hosting decision therefore needs more than a checkpoint download. It needs a memory plan, a network layout, an inference runtime and a way to monitor throughput as users and context grow.

Do benchmarks prove Beam is better at coding?

No. Reflection’s own benchmark table reports Beam at 80.1 on Terminal-Bench 2.1 and 44.4 on DeepSWE v1.1. The same table reports DeepSeek V4.1 Flash at 90.6 and 74.2 on those tests, as shown in Reflection’s launch material.

Those results are useful launch evidence, but they are not an independent, like-for-like purchasing test. Vendors can use different prompts, harnesses, tool settings and retry policies. A public benchmark score also cannot show how a model handles a particular repository, build system or internal documentation set.

Reflection says Beam reaches results comparable to GLM-5.2 with three to four times less inference compute. That is a claim about estimated model work, not a cloud price and not a guarantee that a coding task will finish faster.

There is a separate infrastructure result. vLLM reports 708 tokens per second for one request on tensor-parallel eight-way hardware with Beam’s DFlash2 drafter. Adaptive verification added 10.8% throughput at concurrency 128 in the reported test.

That result used specialised NVIDIA hardware and low-entropy workloads. Low-entropy text is easier to predict than open-ended conversation. The result should therefore not be treated as an OpenRouter latency promise.

The useful test for a buyer is a fixed repository task. Record pass rate, retries, input tokens, output tokens and human clean-up time. Those measures connect the model’s benchmark behaviour to the cost of the work that a team actually wants to automate.

Which access route should you choose?

Choose an API first if your team wants to test Beam without operating a four-GPU deployment. Together AI lists Beam at $0.40 per million input tokens, $0.04 per million cached input tokens and $1.20 per million output tokens. It also lists a million-token context window and serverless or dedicated access.

Provider rates are not interchangeable. Each provider sets its own prices, caching policy and capacity terms for the same underlying model. If a workflow repeatedly sends the same repository context, cached-input pricing can matter more than the standard input rate.

A managed endpoint also shifts operational work to the provider. Self-hosting gives a team more control over versioning, network location and deployment behaviour. It also leaves the team responsible for hardware, runtime upgrades, capacity planning and incidents.

For a small trial, start with one repeatable workflow. Use the same repository, prompt, tool permissions and success criteria across candidates. Do not compare one model’s short chat answer with another model’s full coding-agent run.

What could not be verified?

No public independent evaluation was identified that reruns Beam, MiniMax M3.1 Flash and DeepSeek V4.1 Flash on the same coding-agent harness, prompts, tools and retry policy. A third-party benchmark operator, or a reproducible evaluation release from the vendors, could settle the quality-per-dollar question.

Reflection’s public material does not publish a simple hourly self-hosting price for the four-GPU starting configuration. A cloud provider or Reflection could settle that with region-specific on-demand and committed-use prices.

The public pages also do not establish a single universal API latency figure. Performance changes with provider, concurrency, prompt length, output length and reasoning settings.

MiniMax M3.1 Flash is not a verified open-weight substitute here because the comparison does not establish a released weight licence. DeepSeek V4.1 Flash’s downloadable-weight licence should be checked against DeepSeek’s own release terms before treating it as a commercial open-weight replacement for Apache-2.0 Beam.

The benchmark figures also remain vendor-reported. They can help define a trial, but they cannot replace measurements from the repository, toolchain and approval process that a team plans to use.

Sources

• Hugging Face — Reflection Beam-1.0-501B-A23B
• Reflection — Introducing Beam
• Reflection Developer Docs — Download the weights
• vLLM — Serving Reflection Beam on vLLM from Day 0
• OpenRouter — Models