Beam 1.0 API Pricing: Plans, Limits and Overages (2026)
Oct 25, 202614 min read
You can't read Beam 1.0's cost off a per-token list price, much as you can't judge the cost of a workflow built in Activepieces from a single step's rate.
Current Beam 1.0 API pricing
The bill comes from which kind of token Beam meters, what the plan includes, and what happens past the limit, and each of those can be missing from the headline rate.
Beam 1.0 API pricing is the full set of terms that determine what a team actually pays to use Beam 1.0: the unit Beam meters, the usage each plan includes, and the overage rules that apply once those limits are passed, alongside the published per-token list rate.
Beam 1.0 API plan pricing table
Compare Beam 1.0 on the seven columns a buyer needs: plan, input per 1M tokens, cached input, output, included allowance, usage limits and overage rate. For this check, every figure reads "not stated", because I couldn't confirm a published figure for any of them.
Put every blank to the vendor in writing before launch. An unanswered question tends to come back as a line on an invoice.
What Beam 1.0 metering units count
Before any price makes sense, you need to know what Beam counts and charges for: the metering unit. For language models it's usually the token, a small chunk of text, and the categories differ in price.
An unanswered question tends to come back as a line on an invoice.
As an illustration of why that matters, SyFI TraceLab broke down a typical coding-agent session. This isn't Beam's own bill.
- Cached reads made up 58.6% of session cost. Re-reading earlier context is the largest charge, so a cheap cached rate matters more than a cheap headline rate. Fresh input plus cache writes made up 30.5%, and that's where cost optimization begins. This is the cost of sending new material, and it's the line most people think of as "the price."
- Output made up 11%. It often costs the most per token and still makes up the smallest share of the bill.
Watch only the output rate and you are watching the smallest line.
For Beam 1.0, the check above is the honest answer today: I couldn't confirm any of the six figures. You need a stated cached-input rate, allowance and overage rate before you can estimate a month.
If you are running this arithmetic for your own team, see what the same workload costs on Activepieces.
First invoice costs at three usage levels
Stay inside the included limits and the cheap plan is cheapest; past them, the overage rules set the bill. The steps below show how one invoice gets built, and the example team repeats them at each usage level.
- Count the month's requests.
- Convert those requests into input tokens, cached tokens and output tokens. A token is a small chunk of text, and Beam bills by that chunk, not by the request.
- Multiply each token count by its per-million-token rate from Beam's published price list.
- Subtract what the plan already includes, then price the remainder at the overage rate.
- Add the plan fee and the overage together for the total in dollars.
Treat the team below as illustrative, a worked example and not a real customer. Plug in Beam's published rates and your own counts, and you'll have an estimate before launch instead of a surprise after it.
Light usage: a prototype week
In a prototype week, the request count is small and the first four steps barely matter. Everything fits inside the included limits, so step four returns nothing and the invoice is just the plan fee.
Steady usage: a production month
Once real customers arrive, step two does the damage. Each request carries a long instruction block plus the customer's message, so input tokens grow faster than the request count suggests.
Because cached tokens, which are repeated text Beam has already seen, usually cost less, a team that structures its requests to reuse that text pays noticeably less than one that doesn't.
The team should expect to sit near its included limit here, and that's where reading the overage rule pays for itself.
Spike usage: the day traffic tripled
On a spike day, the team blows through its included amount in hours, and every token after that's priced at the overage rate. If that rate is higher than the rate inside the plan, one busy day can cost more than the plan fee itself.
By then a bigger plan with a higher limit may be cheaper than the cheap one, and the questions that follow are how a team decides.
Hidden costs and limits that surface after launch
Nothing in the list price mentions the charges Beam's invoice carries. The public documentation I found confirms none of them, so each line below is either unverified or a question to put to Beam before launch.
Here's what I looked for, in the order I looked, and what turned up:
- Rate limits (requests or tokens per minute): no figures found, cost unverified.
- Concurrency caps: no published ceiling found, cost unverified.
- Cold-start or idle charges: nothing found, cost unverified.
- Storage and egress: no rates found, cost unverified.
- Overage behaviour: no documented rule found, cost unverified.
- Support gaps: no tier comparison found, cost unverified.
Hit a limit in production and you get a failed job, not a line item. Without a published ceiling, ask Beam in writing how many requests can run at once and how many per minute, and test at twice your expected peak.
Beam 1.0 charges beyond the headline unit
To see why the headline unit misleads, look at agent work.
In SyFI TraceLab's session data, cached reads cost $6.90 per session, fresh input and writes cost $3.59, and output costs $1.29, for a total of $11.80, which explains why output-only pricing is deceptive.
Quote a price on output alone and it covers roughly a tenth of what you pay, since reads are about 58% of the bill, and the true cost becomes apparent only once customers are locked in.
Check whether Beam bills reads, storage and egress as separate lines.
Three things can happen at a limit, and Beam's documentation doesn't say which applies. Throttling slows you down, blocking stops you, and billing keeps you running at a price you didn't plan for.
Beam 1.0 costs and limits versus alternatives
Compare Beam 1.0 and any alternative on five lines of the bill, not the headline price. Take each line from the vendor's own pricing page, because that's where the unanswered overage question gets settled.
Side-by-side price and limit table
Fill in five lines for Beam 1.0 and for each rival you shortlist; the table below says what each one does to your invoice.
Copy every figure from the vendor's own page, and write the date you checked next to it. Pricing pages change, and a figure with no date is a guess.
| Line to compare | What it decides | Where to find it |
|---|---|---|
| Entry price | What you pay before any use | Pricing page, plan card |
| Metering unit | What gets counted, so how fast the bill grows | Pricing page footnotes, billing docs |
| Free allowance | How far you get before charges start | Plan card, usage docs |
| Overage rule | Whether you are billed more, slowed down or cut off | Terms, billing docs |
| Published limits | The hard ceiling no payment lifts | Limits or quotas page |
I haven't filled in competitor figures here. I couldn't confirm them against each vendor's page with a check date, and a wrong number in a budget is worse than a blank you fill in yourself.
Where Beam 1.0 alternatives cost less or more
Once the rows are filled, look for mismatches in the metering unit before you look at price. A cheaper rate per unit loses to a dearer one if its unit is counted more often for the same work.
Then check the overage rule: a tool that stops at its limit costs you an outage, and one that keeps billing costs you money.
How to read Beam 1.0 benchmark claims
Beside their prices, vendors publish speed and reliability claims. Treat them as the vendor's own statement until someone reproduces the result with their own workload. A claim you can't rerun tells you what the vendor wants you to expect, not what you'll get.
Test with a small slice of your real traffic before you commit, and compare the invoice that test produces against the plan card.
Worth checking against a plan that does not meter every step: one credit covers a whole run on Activepieces.
Spend alerts for Beam 1.0 usage with Activepieces
Catch overages before the invoice
It won't make Beam 1.0 cheaper, but Activepieces can tell you the week your usage starts heading past budget instead of leaving you to find out on the invoice.
Set the dashboard caps and billing alerts first, and keep the monthly review on the calendar.
Those are Beam's own tools and they sit closest to the meter. What they often lack is a check you control, run on your schedule and sent to the person who can act.
How the workflow runs
Picture a canvas where you chain small steps together and the tool runs them for you without anyone writing a program: that is Activepieces, a workflow automation tool.
The job here is narrow. A scheduled workflow asks Beam how much you have used so far, compares that to the budget you set, and sends a message to Slack or email when you are over your line.
Activepieces bills the run, not the steps in it: a flow run is 1 credit, so the watcher costs the same as a two-step shortcut or a ten-step build.
That matters here because the reliable design is the one with more integrations, a lookup, a comparison and a branch, and per-task billing on Zapier's pricing page and per-module billing on Make's both charge you more for building it properly.
MoneyGram, Moneypenny, Alan and FundingSocieties run Activepieces in production.
Checking that Beam exposes usage
If Beam exposes usage through an API, which is a way for one program to ask another for data, the approach works. Check that before you plan around it.
If Beam shows usage only on a dashboard page, this approach has nothing to read, and you're back to the manual review.
An example workflow
Take the example flow below as a test workflow, not a Beam-specific one.
It starts with a schedule trigger, passes through a spreadsheet, a loop, a date helper, a web request, two AI steps and a router that sends the result down one of two paths, meaning each execution pays for work across all those steps.
It ends in a Gmail message.
Ignore how much the example chains together and keep the pattern: a timer, a lookup, a comparison, a branch and a message. Your alert needs fewer steps than this one.
Once it's built, run it against a day you already know the answer for. That way you can see the alert fire when it should and stay quiet when it should.
Monday checklist before the next Beam 1.0 bill
Do five steps in this order and most of the surprise goes out of the next invoice.
- Re-check the date on Beam's pricing page.
- Set a spend cap and an alert threshold.
- Estimate monthly units from last month's traffic.
- Test the limits in staging.
- Put a quarterly changelog check in the calendar.
Start with the cheapest step, the first. If the page shows an old date, the numbers you budgeted against may no longer be the numbers Beam charges, and you'd be arguing with an invoice using out-of-date paperwork.
Set a Beam 1.0 spend cap and alert
Think of a cap as the ceiling Beam will let your spend reach, and an alert as the message you get on the way up. You want both, and you want the alert lower than the cap.
If you set only a cap, the first you hear of a problem is a service that stops. If you set only an alert, nothing stops the spend while the person who received it is asleep or on leave.
Name one person who gets the alert, and a second who covers for them.
Estimate Beam 1.0 usage from real traffic
Take last month's actual traffic and convert it into Beam's metering unit, using the vendor's own definition rather than your guess at it. Then compare the result with what your plan includes.
If you're already close to the included limit, overage rules, not the list price, will set your bill. Built from real usage, a forecast is rough, but it's far more reliable than one built from hope.
Test what happens at the limit in staging, your practice environment, before real customers meet it. Find out whether requests are slowed, refused or billed at a higher rate, because each of those costs you differently.
Put a quarterly reminder in the calendar to compare the pricing page and Beam's changelog against your notes.
Prices and limits change quietly, and a change you miss for a quarter is charged to you for a quarter. Each time the check turns something up, rerun the estimate in step three.
Frequently asked questions
Once the estimate is rerun, four questions usually remain, and Beam's own pages answer each of them better than any third party can.
Does Beam 1.0 have a free tier?
To confirm one, go to Beam's pricing page, which also shows what any free allowance covers. If there's one, treat it as a trial and not a plan: a free allowance that runs out mid-launch turns into overage charges the moment real users arrive.
Check what happens at the limit, whether work stops or keeps running and bills.
Assume pricing can change without notice until the terms say otherwise. The terms of service state how Beam handles changes and how much warning you get.
Doing nothing means budgeting against a price that may not hold. Read that clause before launch, and if the notice period is short, ask for the price in writing as part of a contract.
Is Beam 1.0 cheaper than running my own GPUs?
It depends on how busy your hardware would be. Your own GPUs cost money whether they work or sit idle, while a metered service charges only for use.
If your load is steady and heavy, owning can win. If it comes in bursts, metering usually does.
Count the engineer's time to run and repair the machines, since that cost is easy to leave out. Then compare both against the estimate you built from Beam's metering unit and limits, not against the list price.
How do I get an enterprise or volume quote from Beam?
Start from the contact or sales route on Beam's pricing page. Bring your estimate: what you expect to be metered, how much you expect to use, and which included limits you expect to cross.
Send a vague request and you tend to get a vague price, because a sales team can only quote against numbers you give it.
Ask at the same time whether the overage rules and the notice period for price changes can be set in the agreement.
Related reading
References
Running the numbers
See what the same workload costs here.
Free forever plan, and every paid plan self-hosts at no extra cost.
See pricing Talk to sales
