Beam 1.0 vs Ember-1: Two Ways to Trim a Reasoning Bill, and Only One Has Weights

Beam 1.0 and Ember-1 are chasing the same line item from opposite directions, which is what makes the comparison worth making. Ember-1 is Fireworks Research's Kimi K3 derivative, published on 23 September 2026 as a research preview, which attacks reasoning cost by retraining an existing frontier model to think more concisely — the vendor's headline is roughly 40% fewer tokens at comparable quality. Beam 1.0 is Reflection's own architecture, released with Apache 2.0 weights on 16 October 2026, which attacks the same cost by waking only 23.4 billion of 501.3 billion parameters per token and claiming comparable quality at about three times fewer inference-time reasoning tokens. One team changed a model's habits; the other built a model whose habits are cheaper. The sourcing situation differs just as sharply: Reflection's weights exist and can be downloaded today, and Fireworks Research has published neither weights nor a price.

Both claims are vendor-reported and unreproduced, and both are measured against models with published rate cards — which is the only reason the arithmetic is checkable at all.

Two mechanisms, and why they are not interchangeable

Fireworks Research ran more than fifty training experiments and over two hundred evaluations to remove reasoning that does not change the answer, and says reasoning length fell 35–50% across seven benchmarks and two customer production traffic sets. On a Terminal Bench 2.1 run of 89 tasks it reports 82.0% against K3 Max's 80.9% with 51.9% fewer tokens and $23.10 less per task; on τ-2 Bench Airline the saving collapses to 5.9%. The "about 40%" is an average across a spread running from roughly 6% to roughly 52%, which matters enormously if your workload looks like the bottom of that range.

Reflection's approach is structural rather than behavioural. Beam 1.0's saving comes from the activation ratio — 4.7 per cent of the model is awake on any token, so the compute per token is lower by construction — plus a claim about verbosity. The strongest support for the verbosity half is independent: Artificial Analysis measured Beam at 79M output tokens across its Intelligence Index against a median of 130M, ranking tenth of forty-six. That is a third party counting tokens and finding Beam more frugal than most of the field, which is not a per-GPU throughput claim but is a real one.

Put plainly: if Ember-1 works as advertised, any deployment of it gets cheaper. If Beam 1.0 works as advertised, any deployment of it gets cheaper. Neither claim tells you what happens when you swap one for the other, because the two models are not the same size, were not trained the same way, and do not produce the same tokens.

The dimension-by-dimension comparison

• Parameters — Beam 1.0: 501.3B total, 23.4B active per token, a 4.7% activation ratio; 52 layers, 3 dense and 49 MoE, 256 experts. Ember-1: derived from Kimi K3, and Fireworks Research has not published a parameter count for its derivative.

• Licence — Beam 1.0: Apache 2.0, with the licence file in the repository and no restriction on distillation, fine-tuning, quantisation or merging. Ember-1: no weights published at all; it is a served research preview.

• Access — Beam 1.0: three precisions on Hugging Face plus a first-party O​penAI-compatible API at api.reflection.ai, model ID Beam-1.0-501B-A23B. Ember-1: the vendor's own serverless platform, with a two-week access window whose permanence the lab ties to demand.

• Price — Beam 1.0: not published anywhere; the docs carry a detailed rate-limit page and no rate card. Ember-1: not published either; the dollar columns in its benchmark table are computed from Kimi K3's public rates applied to token counts, not from an Ember-1 rate.

• Context — Beam 1.0: 1M-token window on the model card, 131,072 tokens of maximum output on the API. Ember-1: not published for the preview; its base model carries 1,048,576 tokens.

• Reasoning control — Beam 1.0: five effort levels, mandatory reasoning, max as the default. Ember-1: inherits K3's effort dial, and the release's premise is that the dial is too coarse and retraining is the finer instrument.

• Independent evaluation — Beam 1.0: Artificial Analysis Intelligence Index 30, rank 19 of 120 on v4.3.2, with no price and no speed recorded. Ember-1: none published; no third party has run it.

• Self-hosting floor — Beam 1.0: four N​VIDIA B300 SXM GPUs on NVLink for the 273 GiB NVFP4 build, eight H200s for FP8, and eight B200s or B300s for the 933.81 GiB BF16 build. Ember-1: no weights, so no floor to quote.

What an operator can actually do this week

This is where the two diverge, and it is not a close call. Beam 1.0's gap is a price. Ember-1's gap is the artefact itself.

With Beam you can download 273 GiB, run the SGLang recipe against a pinned image, and have the beam-verifier CLI grade your deployment against Reflection's reference scores on the main benchmarks. You cannot price it per token, because nobody has published a rate, but you can compute a capital number and a watts number and compare them against whatever you are paying now. That is an unusual position to be in: a vendor that shipped the verification harness before the price list.

With Ember-1 you can send traffic to a preview endpoint that Fireworks Research has said may not exist next month, and you can read a benchmark sheet whose cost columns are somebody else's rate card. The saving it describes is real if it holds, but the thing generating the saving is not something you can hold.

Both models are measured against Kimi K3, and K3 is the one of the three whose economics are knowable. It sits on our catalogue at $3.00 per million input tokens, $0.30 per million cached input, and $15.00 per million output, with a 1,048,576-token context window. That is the same rate card the Fireworks Research comparison uses, so the token-reduction percentages in Ember-1's table translate into dollars you can verify rather than dollars you have to take on faith.

Which suggests the practical sequencing. Price the workload at K3's route today, treat Ember-1's percentages as the upper bound of what a switch might buy, and wait for a published Ember-1 rate before modelling the saving as money. If the arithmetic is interesting enough to act on, the hedge is to put the preview behind the same endpoint as production — OrcaRouter runs one OpenAI-compatible key across 200-plus models, passes the provider's list price through with nothing added, and fails over automatically, so a preview that vanishes is a routing change rather than a migration. Nothing about a two-week window requires that. Nothing about it argues against it either.

The question that decides it

If your constraint is that the model must be yours — that you need to own the artefact, quantise it, merge it, or run it inside a perimeter — then Beam 1.0 is the only one of these two that is even a candidate, and the missing price is an inconvenience rather than a blocker. Four GPUs and a downloaded checkpoint is a plan.

If your constraint is that you run Kimi K3 in a long agent loop and the bill is dominated by reasoning tokens you cannot see, both are interesting and neither is answerable yet. Beam's efficiency advantage is structural and would apply to any workload; Ember-1's is behavioural and, on its own numbers, applies unevenly — half the tokens on Terminal Bench, a twentieth on an airline-benchmark-shaped task. Run both in shadow against your own traffic before either becomes a line in a budget. The benchmark tables, whichever way they point, were built by the parties selling the models.

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.