Beam vs Beam 1.0: The Version Number That Is Not a Version

Search for two model names that look like a product and its predecessor — Beam and Beam 1.0 — and you will find a comparison that does not exist. There is no Beam 1.0 that superseded an earlier Beam, no Beam 1.1 waiting behind it, and no older checkpoint a reader could still be running. Reflection released one open-weight model in October 2026, calls it Beam in its own prose, and files the repositories and the hosted endpoint under the identifier Beam-1.0-501B-A23B. Both labels point at the same 501.3-billion-parameter sparse mixture of experts. The version number is a distribution tag, not a generation.

That sounds like a footnote. It is not, because the version suffix is the part that propagates. It goes into model IDs, into router configuration, into cost dashboards, into the spreadsheet where somebody is comparing vendor options and cannot tell whether the row labelled Beam and the row labelled Beam 1.0 are two options or one duplicated by a bad import. Getting the identity straight is the whole content of the comparison, and it turns out to be more useful than a spec sheet: it tells you how the thing will behave in a catalogue, and what to check before you wire it into anything.

Where each label actually comes from

The split is not arbitrary. Each form has a source, and knowing which is which is what lets you recognise the same model appearing under two names:

• "Beam" — the vendor's prose name. The launch post is titled "Introducing Beam: Reflection's 501B open-weight model", the 16 October availability post is titled "Beam is now available", and the Hugging Face collection is beam-10. This is also what the framework ecosystem adopted: the SGLang cookbook lists it under its vendor heading as "Beam 1.0 — New", and the project account that serves it in production says "Beam".

• "Beam-1.0-501B-A23B" — the machine identifier. It is the model ID on Reflection's own O​penAI-compatible endpoint, and it encodes the same three facts a builder needs: one model, first release, 501 billion total parameters, 23 billion active. The hyphens are load-bearing; this is a string to paste, not a name to search.

• "Beam 1.0" — the human-readable rendering of that identifier, and the form that shows up in catalogue listings, model-directory pages and third-party summaries. It is what you get when an identifier is prettified for a dropdown.

So the two search terms are not two models. They are the vendor's word and the catalogue's rendering of one repository name.

The consequence that actually bites: matching by name

Everything downstream of that — routing rules, allow-lists, billing exports, evaluation harnesses — matches on the string, and the string is not stable across the places you will paste it. Three practical traps follow, and none of them are hypothetical:

• A rule written for "Beam" will not match "beam-1.0-501b-a23b", and a rule written for the identifier will not match a catalogue that stored the display name. Case and punctuation vary by platform, and nothing reconciles them for you.

• A cost dashboard that groups by display name will show one model as two line items the moment a provider changes its rendering, and the totals will not add up to your invoice.

• A comparison spreadsheet built by searching both terms will double-count the model, which is precisely the failure this article exists to prevent. If you have a row for Beam and a row for Beam 1.0, you have one model and two rows.

The fix is unglamorous: pin the identifier, treat the display name as a label, and key any price or benchmark comparison on the identifier rather than on what the dropdown said. That is also true of the pricing question — Beam 1.0 has no published per-million-token rate at all, on the endpoint or in the announcement, so there is no number to put in either row yet.

The version that does carry real differences

There is a genuine set of distinctions in this release, and none of them live in the model name. They live in the artefact you pick up, and this is where a "Beam vs Beam 1.0" query is really pointing:

• BF16 vs FP8 vs NVFP4 — 933.81 GiB across 188 safetensors shards, 468.72 GiB in E4M3, or a packed 4-bit build at 273 GiB. Same 501.3B total and 23.4B active in all three; the difference is the hardware floor each one implies, from 16 GPUs down to four B300s in NVLink.

• Base versus drafter — DFlash2 is a separate 1.93-billion-parameter speculative decoding model published as its own repository, not a variant of Beam. A deployment without it is not "Beam 1.0 without the update", it is the same model decoded differently.

• Hosted versus downloadable — one identifier, two delivery paths: the checkpoint under Apache 2.0, and an O​penAI-compatible endpoint with mandatory reasoning, efforts from low to max with max as the default, and organisation-wide limits shared across every key.

If two teams disagree about "which Beam 1.0" they are running, the disagreement is almost always on one of those three axes rather than on a version number.

Reading the vendor's numbers on the right date

One more thing changes between labels, and it is a real source of confusion rather than a naming artefact. Reflection has published its benchmark table more than once, and the numbers moved between versions of the page. The 5 October announcement carried one set; a note on that same post records an update on 8 October; the model card as it stands reflects the current figures. The differences are small and mostly in the third significant figure — one configuration of SWE Bench Pro v2-Hard reads 77.2 in the earlier table and 78.6 on the current card — but they are large enough that two articles quoting "the vendor's number" can disagree while both being accurate to their date.

What has not moved is the shape of the result. All figures below are vendor-reported and unreproduced by us, measured at temperature 0.7 and top_p 0.99, and all three precisions are listed because the spread between them is part of the story:

• SWE Bench Verified — 81.6 BF16, 80.2 FP8, 80.7 NVFP4. The headline coding number, and the one precision barely touches.

• Terminal Bench v2.1 — 80.1 BF16, 78.9 FP8, 78.4 NVFP4. Agentic terminal work, where the FP8 build gives up about a point and a half.

• AIME 2026 — 97.7 BF16, 98.0 FP8, 97.5 NVFP4. Effectively saturated in every precision, which makes it a weak discriminator between them.

• GPQA Diamond — 90.6 BF16, 90.3 FP8, 89.3 NVFP4. The clearest example of the NVFP4 build losing ground, around 1.3 points.

The consistent pattern is that quantisation costs little on coding and reasoning benchmarks and slightly more on knowledge-heavy ones, with FP8 sometimes edging BF16 outright — which is a reason to pick a precision on hardware grounds rather than on leaderboard grounds. It is also a reason to write down which table you quoted. A row labelled "Beam" and a row labelled "Beam 1.0" can hold genuinely different numbers without either being wrong, and the version suffix is not what distinguishes them. The date is.

What this means if you are choosing between them

There is no decision to make between Beam and Beam 1.0, because there is one model. The decision that is actually in front of you has three parts, and each has an answer:

• If you need an open checkpoint on your own hardware — one option, three precisions, and the choice among them is a hardware question. Four B300s for NVFP4, eight H200s for FP8, sixteen devices for BF16, and the device count has to divide 256 experts.

• If you need a hosted endpoint — the first-party API is the only one with a documented contract, and it currently has no published price, which means a procurement comparison cannot be completed on cost yet.

• If you need it next to the models you already call — Beam 1.0 is not one of our routes, so we cannot serve it for you and nothing here should be read as an availability claim from us. What we can do is keep the surrounding decision cheap. OrcaRouter runs one OpenAI-compatible key across 200-plus models with the provider's list price passed through and nothing added, and automatic failover across providers, so a Beam 1.0 pilot sits alongside production traffic rather than replacing it, and the fallback path is a routing rule instead of a migration.

The models that fallback would most plausibly land on, off our own catalogue with their published rate cards:

• GLM-5.2 — $1.40 per million input tokens and $4.40 per million output with a 1,000,000-token window. The model Reflection's own efficiency claim is measured against.

• Kimi K3 — $3.00 per million input, $0.30 cached, $15.00 output with a 1,048,576-token window. Reflection's launch post concedes K3 remains ahead on raw capability.

• Qwen3.8-Max — $2.00 per million input and $6.00 output at a 1,000,000-token window, the proprietary flagship alternative to buying Blackwell capacity.

What to watch instead of a Beam 2.0

Three things would make this comparison a real one, and none of them involve a new version number.

The first is a rate card. Until Reflection publishes a per-million-token price on the endpoint, hosted versus self-hosted is a comparison of a capital number against nothing, and no amount of naming discipline fixes that.

The second is independent measurement. Artificial Analysis lists the model with an Intelligence Index of 30, no speed figure and no price, and records no publicly available API — the hosted surface is not yet visible to the organisations that measure these things. Its one independent efficiency datapoint, 79M output tokens generated across the Intelligence Index against a median of 130M, supports the vendor's "fewer reasoning tokens" claim without confirming the throughput behind it.

The third is whether the label ever diverges. A "Beam 2.0" that is a different checkpoint would finally make the version suffix mean something, and the day that lands, a query like this one stops being about naming hygiene and starts being about the difference between two models. Today it is the first kind of question. Anyone comparing Beam against Beam 1.0 is comparing a model against its own repository name — and the useful output of that comparison is a note to key your configuration on Beam-1.0-501B-A23B and stop searching for both spellings.

None of that is hypothetical: the documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive, where each entry carries its own sources, severity, confidence grade and disputed flag.