Bland AI Pricing in 2026: The Caller Runs Your Meter

Bland AI pricing in 2026 is $0.14 per connected minute on the free Start plan, $0.12 on Build at $299/month, $0.11 on Scale at $499/month, and custom on Enterprise, with transfers billed separately on top at $0.05, $0.04 and $0.03 per minute. Those rates were fetched from Bland's pricing page on July 31, 2026.

Our position is that the rate is the least interesting number on that page. Voice billing runs on wall-clock time, and wall-clock time on a phone call is set by the person on the other end. How long they take to answer, how slowly they talk, how far they wander off script, whether they ask for a human, and whether they hang up and call back again are all decisions made by someone who has never seen your budget. One Hacker News commenter described exactly that loop from the caller's side after their mobile provider replaced its phone support with a voice bot. Cut off by the system, they called back, got stuck in a comprehension loop, hung up and called back again — three connections in one sitting, summarised as: "I've just spent 10 minutes talking to a wall and punching in numbers" (data-ottawa, Hacker News, March 2026). On a per-minute voice platform, every one of those minutes and every one of those redials is a line on the operator's invoice.

The short answer: Forecast Bland as Attempts x Answer rate x Talk minutes at your plan rate, add transfer minutes at the transfer rate on top of the connected minutes they already cost, and add $0.015 per attempt on Bland telephony. The only inputs you control are the attempts and the per-call max_duration ceiling.

Last updated: July 31, 2026.

The five stretches of a phone call whose length is decided by the person you called.

We have not run a Bland invoice through a finance system ourselves, and nothing below is a measurement of our own usage. Every rate is quoted from Bland's published pricing page or its billing documentation, fetched July 31, 2026 and linked at the point of use. Every scenario is arithmetic applied to those rates with its assumptions written out, so you can substitute your own numbers rather than take ours.

Bland AI pricing in 2026: every number Bland publishes

There are three self-serve Bland plans and one quoted tier. According to Bland's pricing page, fetched July 31, 2026, Start is free with a $0.14/min talk rate, Build is $299/month at $0.12/min, Scale is $499/month at $0.11/min, and Enterprise is "contracted to your volume". The platform fee buys rate limits and a lower rate; it does not buy any minutes.

Start also comes with two credits and an inbound number Bland values at $15/month, and needs no card. Three things about that table are worth pausing on before anyone builds a model from it.

The platform fee is pure overhead against usage. Unlike most seat-based automation tools, where the subscription includes an allowance, $299 on Build buys zero minutes. Every minute is billed on top. What the fee buys is a lower rate, higher limits and more voice clones and knowledge bases — never a single included minute.

Scale's hourly cap is the same as Build's. Both sit at 1,000 calls per hour while the daily cap rises from 2,000 to 5,000. If your peak is a burst of short calls rather than a sustained day of long ones, the hourly cap is what binds you and the Scale upgrade does not move it. Scale does double concurrency from 50 to 100, so it buys peak capacity in minutes-in-flight; it just does not buy any more calls started per hour.

And there is no annual discount published, no free-minute allowance on any tier, and no volume band between Scale and Enterprise. Above 5,000 calls a day, the documentation directs you to sales rather than to a fourth published rung.

What a connected minute is, and what else meters

A connected minute is the full duration of the AI conversation, prorated to the exact second, with only active call time counted. That is the primary meter, but it is not the only one. Bland's billing documentation lists at least eight separate charges that can appear against one deployment, and five of them are denominated in something other than minutes.

Two entries there deserve more attention than they usually get. Voicemail is billed as standard call time, which means an answering-machine greeting your agent sits through, plus whatever message it leaves, is charged at exactly the same rate as a live conversation with a qualified buyer. And failed calls carry a $0.015 minimum on Bland's telephony, so a list with bad numbers on it bills you for discovering that.

There is also a floor nobody models. Bland's documentation describes SIP traffic terminating on its infrastructure as costing Bland $0.004/min to Twilio, "currently absorbed by Bland and not passed through". That is a stated present-tense choice, not a contractual commitment, and it is the kind of absorbed cost that reappears as a line item when a vendor's margin gets squeezed. Worth a question at contract time rather than an assumption in a model.

The five counterparty meters

Once you accept that a connected minute is wall-clock time, Bland AI pricing stops being a rate-card question and becomes a behavioural forecast. You are not estimating what your agent will do. You are estimating what several thousand strangers will do while your agent is connected to them. There are five distinct stretches of a call where that person, not you, decides the number of billed seconds. We will call them the five counterparty meters, and every voice cost model should carry a line for each.

The Answer meter is the one that most surprises people, because it charges you for the outcomes you least wanted. The Bland API returns an answered_by field on each call with values of human, voicemail, unknown, no-answer or null, per the call detail API reference. Three of those five outcomes are not the outcome you paid for, and two of them still bill.

The Handoff meter is the most expensive per second, and we will cost it separately below. The Redial meter is the one the Hacker News account illustrates best: that caller made three separate phone connections to the same company in one sitting, before giving up and switching to the web chat. Under a per-attempt minimum plus per-minute billing, a frustrating first call does not merely fail. It multiplies.

The Pace meter deserves one clarification, because Bland does expose settings that touch it. interruptibility, resumption_speed and interruption_threshold control how readily the agent yields and how quickly it resumes after the caller stops talking, per the call API reference. Those settings change your agent's contribution to the wall clock. They do not change the caller's. Setting resumption_speed to 1, the fastest of its three integer settings, shaves the gaps your agent leaves; it does nothing about the gaps the caller leaves.

Why an average call length is the wrong forecasting input

Almost every voice AI cost estimate you will see starts with an average call length. That input is weaker than it looks, and there is good published evidence for why. In a well-known empirical study of a real call centre, Brown, Gans, Mandelbaum and colleagues reported, in the Journal of the American Statistical Association (2005), a distribution of service times at an Israeli bank with a mean of 185 seconds and a standard deviation of 238 seconds over January to October, and a mean of 200 seconds against a standard deviation of 249 seconds over November and December. A separate log-service-time model in the same paper covers 57,152 calls.

Read either of those pairs again. In both periods the standard deviation was larger than the mean. The paper goes on to show that service times fit a lognormal distribution closely, which is the formal way of saying the distribution is skewed right with a long tail: a large mass of short calls and a thin band of very long ones that carries a disproportionate share of the total minutes.

For a per-minute invoice, that has three consequences.

Your mean is not your median. A lognormal distribution's mean sits above its median, so budgeting at "the average call" already overstates the typical call and understates the tail. Both errors are in the same forecast.

Your forecast error on any single call exceeds the forecast itself. With a standard deviation above the mean, a per-call estimate is close to uninformative. Only the aggregate is forecastable, and only once you have enough calls for the tail to show up.

And the tail is where the money is. Translated to Bland's Build rate, a 185-second mean is about $0.37 of talk time per call and a 238-second standard deviation is about $0.48. A pilot of 200 calls will not reliably contain a representative tail, so a pilot's cost per call is systematically the wrong number to extrapolate from.

That study is twenty years old and it is a bank call centre, not an AI voice agent, so treat it as evidence about how human callers distribute rather than about Bland specifically. The distributional shape is the transferable part. Nothing about routing the call to a model instead of a person changes how long the human on the other end takes to explain their problem.

Bland's own worked example: connected time covers the whole call, and transfer time is charged on top of it.

A transfer minute costs about a third more than a talk minute

Bland's billing documentation carries a worked example, and it is the most useful thing on the page. A 10-minute call where the agent talks for 8 minutes then transfers to a human for 2 minutes bills as 10 minutes of connected time plus 2 minutes of transfer time. On Start that is 10 x $0.14 plus 2 x $0.05, or $1.50 for a 10-minute call.

The arithmetic worth extracting is that the transferred window is billed twice. It is inside connected time, and it is also transfer time. So the true cost of a minute during which the caller is with a human is the talk rate plus the transfer rate.

That premium is triggered entirely by the caller. Nobody in your company decides that this particular customer will refuse to deal with a bot; the customer decides it, and the decision reprices every remaining minute of their call by roughly a third.

Warm transfers stack further. Per the same documentation, when a warm transfer starts, the agent creates a second proxy agent call in the background, and that proxy leg is billed at your plan's per-minute rate from the moment it is created. Whether the customer hears hold music or keeps talking to the AI while they wait changes which rate applies to the waiting window. Either way, two legs are metering simultaneously while a human colleague decides whether to pick up. The hold time you are billed for is set by your own staff's responsiveness, which is at least a variable you own, but the decision to enter the hold at all was the caller's.

There is a clean way to price this. Take your expected escalation rate, multiply by expected post-transfer duration, and cost those minutes at talk-plus-transfer rather than at the headline rate. An inbound support deployment running 1,000 calls a month on Build with a 20% escalation rate and a 3-minute average handoff carries 600 transferred minutes, which cost $96 rather than the $72 a naive model at $0.12 would predict. That is a third of your escalation budget invisible unless you separate the meters. If you have not yet decided what counts as a successful containment, our earlier analysis on why deflection is not resolution is the argument to settle before you set an escalation target.

Four bills on one identical campaign

Here is the demonstration that makes the thesis concrete. Below are four monthly bills for an outbound qualification campaign on the Build plan. The script is identical in all four. The list size is identical. The plan is identical. The rate is identical. The only things that change are how many people picked up and how long they talked once they did.

Assumptions, stated so you can replace them: 500 dial attempts per business day over 22 days, 11,000 attempts a month; Bland telephony, so the $0.015 outbound minimum applies to every attempt; Build rates of $0.12/min talk and a $299 platform fee; no transfers; no SMS. The answer rates and durations below are illustrative inputs chosen to span a plausible range, not measurements. Substitute your own the moment you have 2,000 calls of real data.

The spread from A to D is 2.6x, and every input that moved is a behaviour of the people you called. Scenario C is the awkward one: it costs nearly twice scenario A precisely because the campaign is working better. More people are engaging and engaging for longer, which is the outcome the campaign was funded to produce and also the outcome that doubles its cost.

That is the structural difference between per-minute voice billing and the metered models that already have coverage. In a per-task automation tool, the multiplier is set inside your own workflow editor by whoever builds the automation, which is the mechanism we mapped in our analysis of who sets your Zapier task multiplier. In a per-run agent platform, the meter starts when your own system calls it. Here the multiplier walks in off the street.

One practical consequence: any voice business case that expresses savings as cost per successful outcome needs both terms modelled against the same behavioural inputs, because success and cost move together. A campaign that beats its cost forecast may simply be failing to engage anyone.

The five-minute line: when the $299 fee starts paying for itself

The plan ladder has a clean crossover, and it is decided by the same variable. Moving from Start to Build saves $0.02 on every connected minute and costs $299 a month. The rate saving repays the fee at 14,950 connected minutes a month, which is just under 250 hours of talk time.

Now put that against Start's ceiling. Start allows 100 calls a day, so about 3,000 calls a month. Those 3,000 calls reach 14,950 minutes when the average call runs 4.98 minutes.

Call it the five-minute line. Below it, the $299 is a tax you pay for capacity, concurrency and voice clones, and the rate discount does not repay it. Above it, the rate discount alone justifies the fee before you count any of the limit increases.

Which side of the line you sit on is mostly not your decision. Script design moves average call length a little; the counterparty meter in aggregate moves it far more. A support line whose callers have complicated billing problems crosses the line without trying. An appointment-reminder agent that says nine words and hangs up never gets close, and should stay on Start until the daily cap, not the rate, is what forces the upgrade.

That distinction matters at renewal. If you upgraded because you ran out of calls per day, the platform fee is a capacity purchase and should be justified as one. If you upgraded because your callers talk for six minutes, the fee genuinely pays for itself and the finance conversation is different. The two have opposite implications if volume falls, so a renewal memo that does not say which one applied is a memo nobody can argue with next year.

The rate discount on Build repays its $299 fee only once the average call passes roughly five minutes.

Your caps are in calls; your bill is in minutes

This is the governance gap, and it is the sentence to take into a procurement review. Bland publishes daily caps, hourly caps and concurrency limits. All three are denominated in calls. The invoice is denominated in minutes. A cap in calls does not cap minutes, and therefore does not cap spend.

The billing documentation is explicit that hitting a cap causes calls to be rejected "rather than incurring unexpected charges", which is true and useful as far as it goes. What it bounds is the count of conversations, not their length. Combine the published caps with the API's default per-call duration limit and you can compute the actual ceiling.

The max_duration parameter on the calls endpoint defaults to 30 minutes, per the API reference: a timer is set when the call starts and the call ends automatically when it expires. The documented maximum is 12 hours.

A free plan with a theoretical daily ceiling of $420 is not a scandal, but it is not what "free" implies either, and it is the number a first-time buyer should see before they hand an API key to a contractor. On Scale, the binding constraint is not the published call cap at all; it is concurrency. The 5,000-call daily cap would allow 150,000 minutes, but 100 concurrent lines can only produce 144,000 minutes in a day. Two published limits, and the one that actually bounds you is the one nobody quotes.

The credit balance is the closest thing to a spend control, and Bland's own documentation is candid about its limits: a negative balance "means your account usage exceeded the available credits before the system could stop additional usage". That is an honest description of an asynchronous stop, and it is the right thing for a vendor to document. It also means the credit balance is a soft ceiling, not a hard one.

So the honest summary is that Bland ships five controls that touch spend, and only one of them is denominated in money. The daily cap, the hourly cap and the concurrency limit are all counted in calls. The max_duration timer is counted in minutes. The credit balance is the money one, and Bland's own documentation says it can be overshot before the system stops usage — which makes it a balance, not a ceiling.

The three dials you actually own

Against five meters the counterparty controls, you have three real dials. Set all three deliberately before the first production call, because two of them default to values chosen for convenience rather than for cost.

max_duration, set per call. This is the single most important cost control on the platform and it is a request parameter, which means it is set by whoever writes the integration code. The default is 30 minutes. For an appointment reminder, 3 minutes is generous; for an intake that legitimately runs long, 15 might be right. The gap between a deliberate 3 and a defaulted 30 is a factor of ten on your worst-case call. Treat it the way you would treat a query timeout: never inherited, always argued for, and reviewed when the use case changes.

Daily and hourly caps, set per plan. These bound the count and therefore bound blast radius on a runaway loop. They are the reason a misconfigured batch cannot dial your entire list twice in an afternoon. They will not stop a small number of very long calls.

Telephony ownership, set once. Bringing your own Twilio account removes the transfer fee entirely and moves carrier cost onto an invoice you already have controls for. That is the subject of the next section.

Everything else that looks like a control is mostly a quality lever. interruptibility and resumption_speed shape the conversation. Guard rails and evals catch bad behaviour, and a pathway can be built to end a call itself — the call record's call_ended_by field distinguishes an agent-ended call from a caller-ended one. But those are behaviours you author and the model executes. Only max_duration is a hard timer the platform enforces regardless of what the conversation is doing, and it is set per call.

For anyone standing up a voice deployment inside a governed environment, the sequencing question of who owns the phone number, and therefore who can shut the whole thing off, is worth settling first; our earlier piece on who owns the number works through that decision.

The costed both-option: bring your own telephony

The hybrid worth costing here is not "some calls on Bland, some elsewhere". It is splitting the AI meter from the carrier meter. Bland supports BYOT through your existing Twilio account or a SIP trunk from any provider, and the documentation is clear that BYOT customers do not pay transfer fees and that Bland charges only its per-minute AI rate while carrier costs go to your own account.

Take the same 10-minute call with a 2-minute transfer, on Start:

BYOT is not cheaper by arithmetic alone. You are removing $0.10 of transfer charge and taking on ten minutes of carrier cost you were previously buying wholesale through Bland. Whether that nets out depends entirely on your carrier rate, and a mid-size US voice rate can easily exceed a cent a minute. Anyone claiming BYOT saves money without naming their carrier rate has not finished the sum.

What BYOT does buy, reliably, is separation. Carrier minutes land on an invoice your telecoms team already reconciles, with call detail records you already know how to read, under a contract you already have. The AI meter and the telephony meter stop being one opaque line item. On the same argument, the $0.015 outbound minimum and the failed-call minimum are both documented as applying to Bland's telephony, so BYOT moves those to your carrier's own connection-fee structure rather than eliminating them.

The decision rule: if you already run Twilio at any scale, BYOT for the auditability and accept that the arithmetic may be near-neutral. If you have no telecoms function, stay on Bland's numbers and buy the simplicity, but write the transfer premium into your model.

What you can prove after the fact: the answered_by join

Forecasting a wall-clock bill in advance is genuinely hard. Reconstructing one afterwards is not, and Bland makes it unusually easy. The call detail endpoint returns price (the cost of the call in USD), call_length (minutes), corrected_duration (the actual length in seconds, as distinct from max_duration) and answered_by, per the documented response fields.

Those four fields are enough to build a per-call unit-cost ledger without waiting for an invoice. The single most useful thing to do with them is to group spend by answered_by. Call it the answered_by join. It answers a question no dashboard asks by default: what share of this month's voice spend bought a conversation with a human being?

Two secondary cuts are worth building at the same time. Sort calls by price descending and read the top 1% of transcripts: on a lognormal duration distribution, that tail is where a meaningful slice of the month sits, and reading it is the only way to learn whether those calls were genuinely complicated or the same conversational loop repeating. Then compare corrected_duration against your max_duration: calls terminating at exactly the ceiling are calls that were cut off, and a rising count of them is either a cost control working or a customer experience failing, depending on what those callers wanted.

We have not run this ledger against a live Bland account ourselves, so treat it as a method derived from documented API fields rather than a reported result. The fields are documented; the join is arithmetic; the interpretation is yours.

The alert asymmetry: the metrics that explain your bill

Bland does ship alerting, and this is where the tier structure gets pointed. Per the alerts documentation, two built-in metrics are available on every plan: call length and API errors. Enterprise plans unlock latency, transcription score, silence count, sentiment score, low engagement ratio and user interruption count.

Look at that second list against the five counterparty meters. Silence count is the Pace meter. User interruption count is the Pace meter. Low engagement ratio is the Detour meter. The three signals that would tell you why your callers are running your clock are on the tier where you have already stopped paying list price and started negotiating.

That is not a criticism of the packaging, which is a normal way to differentiate an enterprise tier. It is a procurement observation: on the self-serve plans, you can see that calls got longer, and you cannot see which counterparty behaviour made them longer. You get the symptom without the diagnosis.

There is a second limitation that applies on every tier. Alerts are evaluated against completed calls, over a lookback window, with a percentage trigger. The documentation states plainly that "a single long call won't fire a CRITICAL alert" — the platform waits until enough calls in the window are violating. That is correct design for noise suppression and it is the wrong shape for a circuit breaker. An alert on this model is a trailing indicator. The only thing that stops an individual call is max_duration, which is why that parameter carries so much weight.

One inconsistency we could not resolve: Bland's pricing comparison table marks the "Alarm & Monitoring" row as available on Enterprise only, while the alerts documentation describes two built-in metrics as available on every plan. Both pages were fetched July 31, 2026. We do not know which is current, and this is exactly the kind of thing to get confirmed in writing rather than inferred from a marketing table.

What the currently ranking pricing pages get wrong

If you have already read a Bland pricing breakdown elsewhere, check its date, because the central number changed. Bland's billing documentation records that plan-based per-minute pricing took effect on December 5, 2025, replacing a flat $0.09/min standard rate, and that every organisation received a one-time transition credit covering the difference between the old rate and the new one on its prior 30 days of usage.

The old rate is still what several high-ranking pricing articles publish. At the time of writing, one widely linked Bland AI pricing breakdown states in its FAQ that a call "costs $0.09 per connected minute" and that "the base per-minute rate is generally $0.09 across most plans". Against the vendor's own documentation, the real rate is 22% higher than that on Scale and 56% higher on Start. It is not a dishonest article; it is an accurate 2025 article that nobody re-fetched.

The same page also states that Bland "doesn't provide built-in analytics" and that you will need to build your own logging. Bland's current documentation describes call logs, alerts, evals, outcomes and citation schemas, and its API returns a per-call price. Whether those amount to enough analytics for your team is a fair judgement call. Whether they exist is not.

This is the practical reason a Bland AI pricing article should carry a fetch date in the body rather than only a published date in the byline, and it is why every rate on this page names July 31, 2026. Voice pricing is not stable. A vendor that repriced its core meter by 22 to 56 percent inside eight months may do so again, and your model should have a place to record when you last checked.

Where a governance layer fits, and where it does not

Everything above is arithmetic on one vendor's rate card. The reason it lands on a governance blog is that voice is the first widely deployed AI workload where the meter is started by a person outside the company, and that breaks the assumption most AI budgeting rests on: that spend is a function of internal activity.

The layer LeapForce builds sits above the vendor, not inside it. Once work is handed to an agent rather than a person, the questions stop being which platform and become who owns this agent, what it is allowed to touch, what it actually did, and what it cost. LeapForce's Model Routing sets budgets in dollars rather than tokens, hierarchically and with chargeback, which is the shape a voice deployment needs and does not get from a call-count cap. Observability and Audit keeps the tamper-evident record of what an agent did, including what it was refused. And the AI Gateway rollout model — observe first, enforce second, optimize third — is the sequencing we would apply to any new voice deployment: run it instrumented before you set limits you cannot justify.

The honest limit: LeapForce does not place phone calls, does not resell voice minutes, and does not sit between Bland and the PSTN, so a dollar budget in our platform does not stop a Bland minute from being billed. What it can govern is the model spend and the agent actions that flow through the gateway, and the ownership record for the agent itself. For the voice meter specifically, the controls are the ones in Bland's own API, and this article is about setting them deliberately.

Eleven questions before you sign

Take these into the call. Every one of them is answerable from public Bland AI pricing documentation or a straight answer from sales, and every one of them is a number we could not derive for you.

1. What is our contracted per-minute rate, and does it change with committed volume or only with plan tier?
2. Is transfer time billed in addition to connected time on our contract, at what rate, and is it waived on BYOT?
3. What max_duration is set in every production integration today, and who reviews it?
4. What is our theoretical maximum daily spend given our caps, concurrency and max_duration, and has anyone written it down?
5. Is there any dollar-denominated spend limit available to us, or only credits, call caps and concurrency?
6. What happens operationally when the credit balance goes negative, and who is paged?
7. Which alert metrics are available on our tier, specifically silence count, interruption count and low engagement ratio?
8. Is the SIP termination fee Bland currently absorbs contractually absorbed, or absorbed at the vendor's discretion?
9. What is our escalation rate, and have we priced escalated minutes at talk-plus-transfer rather than at the headline rate?
10. Does our forecast use a median call length and a tail estimate, or a single average?
11. If the vendor reprices the core meter again, what notice do we get and what is our exit?

Question four is the one worth computing before the call rather than during it. It takes three multiplications, it is not published anywhere, and it is the only figure on this list that tells you what a bad week could actually cost.

Honest limits on this analysis

This piece is arithmetic on published Bland AI pricing, and there are several things it is not.

It is not a measurement of our own usage. We have not run a Bland deployment or reconciled a Bland invoice. Route (d): no first-hand operating data on this platform sits behind any number here.

The scenario tables use illustrative behavioural inputs. The answer rates, talk lengths and escalation rate in the worked bills are stated assumptions chosen to span a plausible range. They are not industry benchmarks and should not be quoted as such. The arithmetic is what we are standing behind; the inputs are yours to replace.

The call-centre distribution evidence is old and adjacent. The Brown et al. study is from 2005 and covers human agents at one Israeli bank. We cite it for the shape of the duration distribution, which is a claim about how callers behave, not about AI agents. A current, published, AI-voice-specific duration distribution would be better evidence and we could not find one.

Enterprise pricing is unpublished, so every comparison here stops at Scale. Any organisation past 5,000 calls a day is negotiating, and a negotiated rate can break the published ladder's logic in ways this article cannot anticipate.

Two vendor pages disagree on alert availability by tier, as noted above, and we did not resolve it.

And on the recognisable-source floor: G2's Bland reviews and the FinOps Foundation's published framework pages both returned 403 to every fetch route available to us, so no aggregated review sentiment and no FinOps unit-economics citation appear here. Reddit threads on voice AI costs were reachable but we found none where a named person described a Bland invoice in enough concrete detail to cite responsibly.

Ready to Govern Your AI?

Talk to LeapForce — one controlled layer for every AI tool, connector, model, and agent.