Cost of Running a Voice AI Platform: A Full-Stack Cost Breakdown

Running a voice AI platform in production means paying for five things every call touches: the WebRTC/SFU transport layer that carries the audio, speech-to-text (STT), the LLM that decides what to say, text-to-speech (TTS), and the hosting, bandwidth, and observability underneath all of it. Most public cost breakdowns only price the AI components and quietly drop the infrastructure carrying them. A vendor’s “voice AI pricing” page tells you what it costs to buy a finished platform; this breakdown prices what it costs to run your own, component by component, at a stated volume — and it names a source and a confidence level for every number, because in a cost piece an unsourced figure is worse than no figure.

The short version, in plain English: TTS — not the LLM — is usually your biggest per-minute AI cost, and your infrastructure bill scales with peak concurrency, not total call-minutes. Everything below is the line-item detail behind those two facts.

What does it actually cost to run a voice AI platform, component by component?

A voice AI call is a stack of separately-billed services. Price them individually and you get an honest model you can adapt; blend them into one “$X per minute all-in” figure and you get a number that breaks the moment your call length or vendor mix differs from whoever published it.

Here is the component reference, with a named source and confidence tier on every figure. All prices are as of July 2026 and this category moves quarter to quarter — re-verify against each vendor’s live pricing page before you commit a budget line.

Two things to read off this table before moving on. First, TTS, not the LLM, is usually the largest per-minute AI cost in a cascaded pipeline once you pick a budget LLM — a fact that surprises teams who assume “the AI” means the language model. Second, the transport row is the one that scales differently from everything above it, which is why it gets its own treatment in the next section rather than a per-minute number here.

For the architecture-level view of the SFU choice sitting behind that transport row — self-hosted control versus managed convenience — see our SFU comparison for telemedicine platforms. Here we’re pricing it, not designing it.

How does voice AI infrastructure cost scale with call volume and concurrency?

The components on that table split into two cost behaviors, and confusing them is the single most common budgeting mistake teams make. In plain terms: if your call volume spikes at certain hours, your infrastructure bill spikes faster than your API bill — so size capacity for your peak, not your monthly average. Here’s why.

API-metered components — STT, LLM, TTS, and S2S — scale roughly linearly with total call-minutes. Double your minutes, roughly double those bills. They cost nothing at zero volume and they don’t care whether your calls happen all at once or spread evenly across the day. This is the easy part of the model, and it’s the part most teams get right because it matches how they already think about API spend.

Infrastructure components — self-hosted SFU compute and GPU instances — scale in steps, not linearly. A self-hosted SFU node or a GPU instance has a fixed capacity ceiling. You pay for that node whether it’s carrying one call or its maximum, and cost jumps when you add the next node — not smoothly per call. A team used to per-minute API math will model this wrong every time, because the cost curve is a staircase, not a slope.

Here’s the corollary that trips people up: concurrency — calls happening simultaneously — drives the infrastructure cost curve, while total monthly minutes drive the API bills. A platform doing 40,000 minutes a month all clustered into a two-hour daily peak needs far more SFU/GPU capacity than one spreading the same 40,000 minutes evenly across 24 hours, even though their STT/LLM/TTS bills are nearly identical. If you model everything off “calls per month,” you will under-provision the transport layer and over-trust the total. For how SFU topology itself behaves at scale — where the transport layer stops being a rounding error and becomes the dominant operational variable — see Voice AI Agents on WebRTC: Latency, Barge-In, and Turn-Taking. That’s a cost aside here, not a topology tutorial.

Does cost scale differently for a cascaded pipeline vs. a speech-to-speech model?

Yes — mostly in how optimizable the bill is, not in the raw total. A cascaded pipeline (STT + LLM + TTS) gives you three separately-billed, independently-swappable line items: you can move to a cheaper STT vendor without touching the LLM bill, or drop from a flagship model to a budget one on the turns that don’t need reasoning. A speech-to-speech model collapses those three into one audio-token bill — simpler to reason about, but harder to partially optimize, since there’s no “just the TTS” to make cheaper. The one lever that matters most on the S2S side is prompt caching, which in measured sessions cuts per-minute cost by roughly 3–5×. The architectural trade-offs behind that choice — latency, observability, swappability — are covered in our WebRTC voice agent guide; this section is about the bill, not the pipeline.

What does it cost to run a voice AI platform at 10,000 calls a month? (worked example)

This is a directional model to adapt, not a quote. Every input below is a range, so the output is a range too. Here are the assumptions, stated plainly so you can swap in your own numbers:

• Volume: 10,000 calls/month
• Average call length: 4 minutes — a reasonable figure for a customer-support voice agent (state-your-own; a booking or triage flow may be shorter, a sales call longer). That’s 40,000 call-minutes/month.
• Architecture (base case): cascaded pipeline — Deepgram-class STT + a budget-tier LLM (GPT-4o-mini class) + ElevenLabs/Cartesia-class TTS. We price an S2S alternative separately below.
• LLM token assumption (shown, because it’s the one non-obvious conversion): a budget model at ~4 turns/minute of active talk, ~1,500–3,000 input tokens/turn (system prompt + running conversation context) and ~100–200 output tokens/turn — roughly 6,000–12,000 input + 400–800 output tokens/minute. On GPT-4o-mini pricing ($0.15 / $0.60 per 1M) that’s about $0.001–$0.003/min uncached. We round the modeled range up to $0.002–$0.03/min to cover heavier RAG context, per-turn tool calls, and uncached long-context resend; a flagship model multiplies it 25–40×. [Estimate — derived from the stated token assumptions, not a vendor figure]
• Concurrency: if those 40,000 minutes land mostly in ~176 business hours a month (22 working days × 8 hours), average demand is ~40 concurrent calls, with a realistic peak of ~80–120 concurrent at a 2–3× duty-cycle factor. This is what sizes the transport layer — not the monthly total. [Estimate — derived, not measured]
• Transport: managed SFU-as-a-service (so egress is a clean $/GB line, no self-hosted node math); voice-only audio, no video.

Now the running math. Each row is the per-minute range from the reference table, multiplied by 40,000 minutes.

Read that total as a real range, not a headline. The base cascaded stack lands roughly $2,320–$6,220/month at 10,000 four-minute calls — and inside that range, TTS is the dominant driver, the LLM line swings widest depending on model tier, and STT and transport are almost noise by comparison. Swap the budget LLM for a flagship reasoning model on every turn and the LLM line alone can exceed the entire rest of the stack.

The same 10,000 calls via a speech-to-speech model looks different because the whole AI stack becomes one audio-token bill:

Add the same ~$80–$700/month of transport and observability to either row. The takeaway isn’t “S2S is more expensive” — it’s that S2S has a wider, caching-dependent cost range: neglect prompt caching and you can pay 3–5× more than a well-tuned cascaded pipeline; use it well and you land in the same neighborhood, with fewer moving parts to bill and debug. [Likely — measured per-minute figures are third-party, 2026]

Real production cost will diverge from this model for reasons you should budget for: your call-length distribution (not just the average), retry and error rates that consume partial minutes, concurrency peaks that force extra capacity, and volume discounts most vendors offer on contract tiers above pay-as-you-go. Treat the range as a starting frame, then tighten each input with your own traffic data.

What infrastructure costs do voice AI cost breakdowns usually miss?

Product-pricing pages (the “buy a platform” comparisons) skip these because they’re pricing a finished product, not the infrastructure under it. When you build, every one of these becomes your line item.

• TURN relay bandwidth. Why it’s missed: it’s assumed included in a managed platform’s flat rate. As flagged in the component table, calls that can’t connect peer-to-peer get relayed through your TURN server and billed as bandwidth — a real cost when you self-host, not an edge case. (No reliable public figure exists for what share of calls need TURN; it varies too much by your users’ network mix to quote one honestly — model it against your own traffic.)
• Egress bandwidth generally. Why it’s missed: a single audio stream is tiny, so it’s easy to forget when you’re modeling off per-minute API costs. It adds up with concurrency — many simultaneous streams, each carrying two directions of audio, plus any recording or transcription fan-out.
• GPU idle cost. Why it’s missed: teams model it like an API — cost when used, zero when idle. It isn’t. If you self-host any model component, the GPU is billed on time or allocation whether or not a call is happening. That fixed floor — real money per hour even at 3 a.m. with zero traffic — is exactly what changes the build-vs-buy math at low volume.
• Observability / monitoring. Why it’s missed: it’s a cost category most teams don’t discover until they’re already in production and something breaks. Voice/LLM observability tooling bills on trace volume, and one agentic turn can emit 20–50 traces, not one — so cost scales with pipeline complexity, not just call count.
• Retry and error-rate overhead. Why it’s missed: first-pass models assume every call is a clean, complete call. In production, a share of calls fail or drop after consuming partial STT/LLM/TTS minutes — you paid for the work up to the failure. Model a realistic failure rate or your per-call cost will run under actual.
• Engineering and ops time. Why it’s missed: it’s not on any vendor’s invoice, so it doesn’t show up in a bill-only estimate. The honest total cost of ownership includes the team keeping this stack running — on-call, upgrades, tuning, incident response. This is where build-vs-buy is actually decided, not on the per-minute rate.

If you’re already trying to size these hidden line items for your own traffic, that’s the kind of modeling our WebRTC consulting team does with clients before a build commitment — no need to read to the end for it.

Should you build your own voice AI infrastructure or buy a platform?

Neutrally: for many teams, buying is the right call — and hedging around that would be dishonest.

Buying a platform (Vapi, Synthflow-class, and similar) trades a higher per-minute rate for zero infrastructure ops burden. Below a certain volume and complexity threshold, that’s simply the faster, cheaper, saner path — you get to production without staffing an SFU, a TURN fleet, GPU capacity, or an observability stack, and the marginal per-minute premium is cheap next to the engineering time you’d spend replacing it.

Building trades a lower marginal per-minute cost — once you’re past the fixed-cost floor from the hidden-costs section above — for real, ongoing engineering and ops investment. The crossover point depends on three things: your volume (does marginal savings ever repay the fixed floor?), your compliance requirements (data residency, HIPAA, on-prem, or custom-model needs a platform can’t meet), and how much your product’s differentiation actually lives in the voice layer itself.

The honest heuristic: if voice AI is the product, building buys you control and margin at scale. If voice AI is a feature bolted onto a different core product, buying is usually faster and cheaper until volume or compliance forces a change. Whichever way you go, the real-time foundation underneath — WebRTC transport, SFU media routing, TURN — has to be built and operated by someone. That’s the layer Trembit builds and operates for teams who choose to build it themselves: 15+ years of protocol-level WebRTC work across 50+ real-time video and voice implementations, including HIPAA/GDPR-compliant telemedicine and live e-learning platforms. It’s also the layer we’re most often called in to inherit and fix when a self-hosted build stalls partway. We’re not neutral about whether that layer should be done well — we are neutral about whether you should build it, because for plenty of teams the right answer is “not yet.”