# Beam 1.0: Speed and Accuracy Test Results (2026) By Leah Goldberg · 2026-10-21 · Source: https://www.activepieces.com/blog/beam-10-speed-and-accuracy-test-results-2026 --- Beam 1.0 is **Reflection's first open-weight model**, released as Beam-1.0-501B-A23B and built for coding, reasoning, and agentic tasks, the kind of work that teams now wire into automations through tools like [Activepieces](https://www.activepieces.com). ## Beam 1.0 is a new model from Reflection, released 2026 ### What Reflection released [Reflection](https://reflection.ai/)") describes Beam as an open model that takes text as input and generates text as output. The main variant is the text-generation model named in the table below. It's a release from a single maker, so everything here traces back to Reflection's own pages. Before you test anything, you need five facts, and the table gives each with the page it came from. [Huggingface](https://huggingface.co/reflection/Beam-1.0-501B-A23B) identifies Beam 1.0 as Reflection's first open-weight model, released as Beam-1.0-501B-A23B and built for coding, reasoning, and agentic tasks. | Fact | Source link | |---|---| | Model name: Beam-1.0-501B-A23B | [Hugging Face model page](https://huggingface.co/reflection/Beam-1.0-501B-A23B) | | Maker: Reflection | [Hugging Face model page](https://huggingface.co/reflection/Beam-1.0-501B-A23B) | | Release year: 2026 | [Hugging Face collection](https://huggingface.co/collections/reflection/beam-10) | | Where published: Hugging Face, as a model page and a collection | [Hugging Face collection](https://huggingface.co/collections/reflection/beam-10) | | Pages checked: 2026-10-20 | [Hugging Face model page](https://huggingface.co/reflection/Beam-1.0-501B-A23B) | If Reflection changes anything after 2026-10-20, it won't appear here, because both pages were read that day. Re-read them before you commit. ### Where the weights and collection live To find the weights, look in two places on Hugging Face. The model page for Beam-1.0-501B-A23B carries the details, and the Beam 1.0 collection groups the release. Start with the collection to see which variants exist, then open the model page for the one you plan to run. You can call it from a flow through a generic request step. No packaged integration is required, because the model takes text in and returns text out. ## Why beam 1.0 matters to teams automating with AI You can change one part of an AI step: the model, because the request step looks the same whatever sits behind it. That choice moves your cost, your speed and where your data goes. Take a flow that fires on new mail matching `label:support is:unread` and asks a model to classify each message before routing it. The trigger, the routing and the downstream apps stay put. Only the model changes, and every run feels it. ![Mail trigger, one swappable model box, routing to apps](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/4af0e26d-8cd3-4df1-b999-05fae9c46ecf/beam-1-0-speed-and-accuracy-test-results-2026-il-49e2ebb0.webp) Swap in a new model like Beam 1.0 and each of the following can shift, which is why it's worth reading about: - Cost per run, which multiplies across every message the trigger catches, so a small difference per call becomes a real line on the bill at volume. - Speed per step, since a slow model holds up everything after it and a customer waits longer for a reply. - Where the model runs, which decides whether your message text leaves your infrastructure. - How it's called, through a hosted API or on hardware you manage, which sets who handles uptime and who gets paged when it fails. - What to re-test on swap: the output format your later steps parse, the edge cases that used to route correctly, and the failures you already handle. For the first four, the maker's published facts are enough. The last one only your own data can answer, which is why a small test belongs before any switch. ## What is measurably new in beam 1.0, per the maker Beyond a listing of 501B total parameters with 23B active, the maker's own pages say little, so the checkable list is short. The table shows what the Hugging Face model page and collection state, checked 2026-10-20, and what to take from it is that every other claim needs your own test. | Item | What the maker states | Source page | Date checked | |---|---|---|---| | Parameter sizes | 501B total, 23B active | Hugging Face model page | 2026-10-20 | | Capabilities | Listed on the model card | Hugging Face collection | 2026-10-20 | | Licence | Apache 2.0 | Hugging Face model page | 2026-10-20 | | Access | Weights hosted on Hugging Face | Hugging Face collection | 2026-10-20 | | Not stated | Hardware needs, latency, pricing | none | 2026-10-20 | Because only 23B parameters are active per token, compute per request resembles a mid-sized model. Memory still has to hold all 501B, so a small server won't run it. Some of these scores come from the maker; others come from third parties: [BenchLM](https://benchlm.ai/models/reflection-beam), [Datastudios](https://www.datastudios.org/post/reflection-beam-501b-23b-open-weights-1m-context-coding-benchmarks) and Artificial Analysis. AIME 2026 is 97.7%, so maths reasoning is excellent. [Plotly](https://plotly.com/blog/reflection-beam-1-0-plotly-data-analytics-bench/) analytics is 84%, SWE-bench Verified 81.6% and MCP Atlas 80.8%, which suggests solid coding and tool use. Treat unattended automation reliability as untested, since the pages give only benchmark scores. **Terminal-Bench 4.0 is 3%**, so don't hand it a shell. Read the licence field on the model page before building on it; it is Apache 2.0. Access is through the Hugging Face collection. Nothing is stated on hardware requirements, latency, pricing or failure rates on your workflows. That gap is what a small test fills. ## How to connect beam 1.0 in a workflow today Start with a plain HTTP request step. Move to an AI step with an OpenAI-compatible provider only if the endpoint allows it, and use an MCP server last, running one test after each. ![n8n vs Activepieces](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/6f966669-382d-4dd9-9615-e72d149bb898/cloudflare-clef-decision-models-for-agentic-work-20927731.webp) The integration catalog and repository list nothing specific to Beam 1.0, so every route here uses general building blocks. ### Connect beam 1.0 with an HTTP request step Send a POST to the model endpoint with the API key in the header and your prompt in the JSON body. Use the exact URL and field names from the maker's docs. It doesn't need provider support, so it works today. ![JSON card with key tag sent to model endpoint](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/93160a17-593d-487e-8a70-706596153dcf/beam-1-0-speed-and-accuracy-test-results-2026-il-27ced4ff.webp) Test the request with one fixed prompt and read the raw response. Then check the status code, the response time, and what a failed call looks like, because your flow's retry logic depends on those. Look up the maker's rate limits before you loop this over a mailbox. ### Option 2: AI step with an OpenAI-compatible provider If the maker documents an OpenAI-compatible endpoint, add it as a custom provider with its base URL, key and model name. The payoff is that the step behaves like any other AI step, so you can swap models without rebuilding the flow. Test this setup by running the same prompt you used in Option 1 and comparing the answers. If they differ sharply, the compatibility layer is dropping something. [Activepieces](https://www.activepieces.com) runs that custom-provider step on whatever model you already chose, using your own provider key, so Beam 1.0 spend lands on your provider account at your rate. Reselling you a model is deciding your AI strategy for you, and a platform that bundles its own has priced the choice before you open the product. Here Claude, ChatGPT, Cursor or any MCP client can reach the same flow, and the pricing page lists Bring-Your-Own-Key by tier. Use an MCP server only if the maker or a third party publishes one for Beam 1.0; that is Option 3. It lets an agent call the model as a tool, but it's the most moving parts to debug. Test with one tool call that has a known correct answer, and confirm the agent actually invoked it. ## Our small test of beam 1.0 against GPT-5.4 mini On 2026-10-20, beam 1.0 matched openai/gpt-5.4-mini's speed on two of our three automation tasks. It then came out slower and wrong on the email summary, so for that task it did not beat the openai/gpt-5.4-mini baseline we tested against; a current model such as GPT-6 Luna or Claude Haiku 5.5 would be the natural comparison to run next. Treat this as a small, indicative test, not a benchmark. ### The three tasks in our beam 1.0 test We ran both models through OpenRouter, a gateway that serves many models behind one API, using [beam 1.0's listing](https://openrouter.ai/reflection/beam-1.0-501b-a23b) with default settings, which reason before answering. The tasks were sorting a support ticket, pulling fields from an invoice, and summarising an email thread. Each result was checked against a known answer. One bad run could move the picture, because the test covers three tasks, one run day and default settings. Don't read more into it than that. ### Beam 1.0 test results for speed and cost At [0.9 seconds per task](https://www.activepieces.com/blog/reflection-beam-open-weights-specs-cost-and-tests) for ticket sorting and 0.8 seconds for invoice fields, beam 1.0 won't be noticed by your queue on either. Then came the email summary: 2.2 seconds, slower than the others, and the summary was wrong. That matters most because a long thread is the task people hand to a model when they don't want to read it themselves. | Task | Beam 1.0 seconds per run | Against openai/gpt-5.4-mini | |---|---|---| | Sort a support ticket | 0.9 | Slightly slower | | Pull invoice fields | 0.8 | Matched on speed | | Summarise an email thread | 2.2 | Slower, and the summary was wrong | ![How long Beam 1.0 took on each test task](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/5ee02fef-424f-4a57-875a-20c3a6d2ae22/beam-1-0-speed-and-accuracy-test-results-2026-lo-4c5f837d.svg "Source: Activepieces") *Small, indicative test, run 2026-10-20.* **Before switching anything, rerun the email summary on your own threads, because that's where beam 1.0 failed.** ## What beam 1.0 means for cost and speed today It is unproven whether beam 1.0 has a cost and speed edge over gpt-5.4-mini. Our three-task test is too thin to settle it, and one of those tasks, the email summary, is where it failed. ### Beam 1.0 cost per task versus other models In the chart "What ticket triage costs on other popular models", the ticket-triage costs come from a [DEV Community comparison](https://dev.to/darulrahman/i-compared-ai-costs-across-22-models-heres-what-surprised-me-36l2). They don't include Beam 1.0. They show how wide the range is. On Groq Llama 3.1 8B, 1,000 calls cost $0.06, and on DeepSeek V3 they cost $0.08, so 10,000 tickets a day runs under a dollar on either. At $0.21 per 1,000 calls, Claude Haiku 3.5 is still cheap enough to ignore at small volume. At $0.90 for Claude Sonnet 3.5 and $2.30 for GPT-4o, **the latter roughly 38 times the cheapest option**, which is $23 per 10,000 tickets, costs add up quickly. If Beam 1.0 doesn't land near the low end of that range, a switch has to be justified by quality alone. ### Beam 1.0 speed per task in our test With no maker-published latency figure for Beam 1.0, the only speed evidence is our own timings in the chart. Three tasks cannot separate a real gap from one slow run, so you might blame the model for what was just bad luck. ![A single stopwatch beside three nearly identical bars of slightly different lengths, with a snail on the longest bar and a…](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/ae7aef2f-1855-40c4-898a-b9a37a6e486d/beam-1-0-speed-and-accuracy-test-results-2026-il-7d32c54d.webp) Time at least 50 of your own runs before trusting any speed claim, and count a failed task as a cost, not a fast result. ## What to watch next after the beam 1.0 release Watch three places for change. Treat anything they don't confirm as unknown, because a failed run you blame on the wrong cause costs you the same as a slow one. Those three places cover what the maker may add and what your platform may support: - The maker's collection page, for new variants of beam beyond 1.0 - The model card, for updates to its stated limits, intended use and known issues - Your automation platform's repository and integration catalog, for any beam-specific support On Monday, put beam into one low-risk flow, such as internal ticket tagging, and compare its results against your current model on the same inputs. Nothing breaks if it fails there. Read only what the model card states. If it gives no size or design details, don't infer them from the name or from similar models, because your cost and speed estimates would rest on a guess. Check the licence text and the access route before you build on it. A flow that works in a test can become a problem if the terms limit commercial use, so your legal reading should come before any production rollout. Gaps are information. If the card is silent on limits, languages or failure behaviour, write those down as questions and let your fifty-run test answer them. ## What Activepieces does about this The catalog and repository list nothing specific to it, as noted above. What the platform does is make the test this article recommends cheap to run. You build the flow once with an HTTP request step or a custom OpenAI-compatible provider, point it at whichever endpoint serves Beam, and keep your current model on a second branch fed the same inputs. ![Activepieces workflow builder with the Send HTTP request step selected, showing its configuration panel with HTTP method…](https://ap-marketing-media.fra1.cdn.digitaloceanspaces.com/uploads/58352882-31ce-42ab-9b0f-c4a0fe866a5c/deepseek-r1-vs-v3-for-business-ai-2026-guide-scr-ae99964b.webp) Swapping the model is then a change to one step, not a rebuild. That matters because of what our own test found. Beam took 0.9 seconds on ticket sorting against 0.8 for gpt-5.4-mini and matched it at 0.8 seconds on invoice fields, then took 2.2 seconds and got the email summary wrong. A two-branch flow lets you see that failure on your own threads, with your own mail, before any customer does. Run it on a low-risk trigger such as internal ticket tagging, log both outputs side by side, and let fifty runs decide, not a leaderboard figure. Cost and data location stay in your hands. The core of Activepieces is open source under the MIT licence, so you can self-host it and keep message text inside your own infrastructure. Model spend goes through your own provider key, so you pay the maker's rate, with no markup from us and no bundled model deciding for you. The pricing page lists Bring-Your-Own-Key by tier, so check which tier your setup needs. Some enterprise features sit under a separate commercial licence, so read the licence file in the repository before you assume a feature is covered by MIT. If you later want an agent to call the model as a tool, the same flow can be exposed over MCP to Claude, ChatGPT, Cursor or any MCP client. We haven't tested that route with Beam, and it remains the one with the most moving parts. Treat it as a later step, after the plain request step has held up on your data. ## Related reading - [Qwen3.8-27B Release Date: Benchmarks and VRAM (2026)](https://www.activepieces.com/blog/qwen3-8-27b-release-date-benchmarks-and-vram-2026) - [Updating Automation Templates When a Connected App Changes](https://www.activepieces.com/blog/updating-automation-templates-when-a-connected-app-changes) - [SAP Business One AI Assistant: Edit Automations](https://www.activepieces.com/blog/sap-business-one-ai-assistant-edit-automations) ## References - [Activepieces](https://www.activepieces.com/blog/reflection-beam-open-weights-specs-cost-and-tests) - [DEV Community](https://dev.to/darulrahman/i-compared-ai-costs-across-22-models-heres-what-surprised-me-36l2) - [Datastudios, BenchLM, Artificial Analysis](https://benchlm.ai/models/reflection-beam)