Voice AI Agent Cost and Performance Optimization

Cekura defines voice AI agent cost and performance optimization as tuning price per minute and response time together, because cutting one usually damages the other. Cekura measures both on live calls, tracking per-turn latency percentiles, pass rates, and the recovery cost of failed model calls on production traffic.

Last updated: August 2026 By Dileep Chagam, Founding Engineer, Cekura · IIT Bombay · Ex-Apple

TL;DR

• Cekura finds the platform with the fastest median turn is not the most reliable: ElevenLabs posts the lowest P50 at 1,730 ms across 1,125 tested turns and the lowest three-run pass rate at 76.3%.
• Cekura measures P95 spread rather than the median alone, because the median says nothing about the calls you lose. Vapi runs tightest at 610 ms above its median and Pipecat runs widest at 2,269 ms.
• Cekura records, on production data carrying no pre-rollout baseline, roughly one turn in fifteen hitting a provider stall large enough to need recovery, so a cheaper model is not cheaper if it stalls.
• Cekura races a request across several providers instead of retrying one, which costs extra only on the turns that stall.
• Cekura splits voice agent cost into five layers that do not share a billing unit. Only telephony and transcription bill per minute, which is why per-minute calculators disagree.
• Cekura recommends measuring liveness, not completion. Time to first token tells you an agent is alive; a full-response timer only tells you it already failed.

Every figure in this article sourced to Cekura's pipecat-cekura-bot instrumentation describes current production behavior. That instrumentation began after the fix it measures, so there is no queryable pre-rollout baseline and none of these figures is a measured before-and-after.

What drives the cost of a voice AI agent?

Cekura tracks voice AI agent cost across five layers that bill independently: telephony on the call itself, speech-to-text on the inbound audio, the language model on the reasoning turn, text-to-speech on the reply, and the orchestration platform on top. Cekura sees teams optimize the model layer first because it carries the widest relative price and latency spread of the five.

That spread is wide. Per Artificial Analysis, Llama 3.1 Instruct 8B runs at $0.02 per million blended tokens, while frontier models cost orders of magnitude more for the same turn. Latency spreads the same way, with Gemini 2.5 Flash-Lite recorded at 0.31 seconds to first token. Deepgram documents transcripts returning in under 300 milliseconds, so a slow model turn dominates the budget the other two layers share.

Cekura tracks the cost decision and its latency consequence on the same call record. A model chosen on price per token changes every turn's shape, and the calls you lose are not the average ones.

What does a minute of voice AI agent actually cost?

Cekura splits voice agent cost into five layers that do not share a billing unit, which is why per-minute calculators disagree. Telephony and transcription bill per minute, the model bills per token, the voice bills per character, and the orchestration platform adds a fee on top.

Only two layers bill in minutes, so only two are knowable before a call runs. Telephony and transcription together fix about $0.0133 per inbound minute. The model and voice layers bill in tokens and characters, which is where a per-minute estimate becomes an assumption about speaking rate and response length.

The model layer moves most in relative terms and least in absolute terms. At Vapi's published estimate of 150 output tokens per minute, a model at $0.02 per million blended tokens contributes a fraction of a cent per minute.

Cekura measures the layer no calculator prices: the recovery cost of a stalled turn. A stall that loses the call forfeits the whole minute, dwarfing any per-token saving the model layer produces.

What actually determines voice AI agent performance?

Cekura measures voice AI agent performance by the worst turns on a call, not the typical ones. A caller experiences the single slowest reply in a conversation, not the median across a thousand of them.

A caller runs a stopwatch in their head. Answer in about three seconds and the exchange feels natural. Take six and they say "hello?", talk over the agent, or hang up, before they have judged the answer at all. The average was fine. The tail ended the call.

Cekura reports percentiles rather than means on every latency metric. A P50 of two seconds with a P95 of six is a worse agent than a P50 of two and a half with a P95 of three, even though the second looks slower on a dashboard. The first loses one call in twenty. Percentile behavior is covered in depth in what P99 latency means for voice AI agents.

Why does the fastest platform not always give the best experience?

Cekura measures latency and reliability as separate axes, because the fastest median platform is frequently not the most reliable one. Cekura's voice orchestration benchmarks cover six platforms on more than 1,000 turns each, and the ranking inverts between the two axes.

Per Cekura's benchmarks, ElevenLabs holds the fastest median turn at 1,730 ms across 1,125 tested turns and the lowest three-run pass rate at 76.3%. Vapi sits 610 ms above its own median at P95 across 1,205 turns, the tightest spread measured, while Pipecat spreads 2,269 ms across 1,218. These platforms are orchestration partners Cekura tests against, and the numbers describe behavior on a specific suite rather than a verdict on any vendor.

Cekura recommends planning against the spread column. A platform whose P95 sits close to its median delivers a predictable call, which lets you size timeouts tightly. Pipecat instruments turn-level timing directly with a UserBotLatencyObserver and a TurnTrackingObserver. LiveKit's observability tooling covers transcripts, traces and logs rather than turn-level latency.

How do you detect a stalled LLM response before the caller hangs up?

Cekura detects a stalled model response by timing the first token, not the whole reply. The clock starts when the agent needs to speak and stops when the first token lands, proof the model is alive.

The dangerous case is the silent stall: the request is accepted, the connection stays open, everything reports healthy, and not one word comes back. A rate limit or a 500 is caught and routed elsewhere; a stall leaves nothing to catch.

A full-response timer misses this twice. It fires too late, only after the whole budget has burned and the caller is gone. It also cannot tell slow from dead: a model that started fast and finished slow looks identical to one that never spoke.

Cekura's pipecat-cekura-bot instrumentation records healthy first tokens arriving in about one second, with 99.8% landing under two seconds, on instrumentation that postdates the fix it measures and carries no pre-rollout baseline.

"Averages don't hang up on you. Tails do."

Dileep Chagam, Founding Engineer, Cekura · IIT Bombay · Ex-Apple

How long should the first-token timeout be?

Cekura sets the first-token timeout at two seconds and treats anything past it as a stalled turn worth acting on. Two seconds is deliberate: healthy turns clear it almost every time, so the alarm rarely fires on a good call, yet the caller barely feels the pause before recovery starts.

Two guards keep that threshold honest. A slow finish never trips it, because the first token already stopped the clock, so a reply that starts fast and ends slow is left alone. Chosen silence is exempt as well: a pre-recorded message or a hang-up already in progress is not a stall, so the agent never talks over its own goodbye.

Cekura removed the retry loop that used to sit behind that timeout. An empty reply now routes onward rather than re-asking the provider that produced it.

Should you retry the same model or race a different provider?

Cekura does not retry the same model after an empty reply, because production data shows it rarely recovers the turn. Re-running a silent provider stacks more silence onto a path that already failed.

Cekura races instead of switching. The instant the first-token clock fires, the same request goes to several providers at once, the first to start talking wins the turn, and the rest are discarded. Recovery is bounded by the fastest available backup instead of a chain of sequential retries.

Racing creates one hard requirement: if two providers answer, the caller must hear exactly one reply. The real engineering is the referee, a gate that admits one winner, blocks every straggler, and reopens only at a clean turn boundary.

Across roughly 220,000 spoken turns in two weeks, Cekura's pipecat-cekura-bot telemetry records about one turn in fifteen hitting a stall large enough to trigger a race, with recovery above 99% in about 1.2 seconds, on instrumentation that began after the fix shipped and carries no pre-rollout baseline.

What does racing providers actually cost?

Cekura pays for racing only on the turns that stall, which is what makes a bounded worst case affordable. Cekura records the stall rate at roughly 7% of turns, with no pre-rollout baseline, so the duplicate requests apply to that 7% and not to the other 93%.

The arithmetic matters more than the headline. If a race fans one request to three providers, the two losing requests are billed on 7% of turns. That is 0.07 multiplied by 2 extra calls, or about 0.14 additional model calls per turn on average. This illustrates the cost shape derived from Cekura's measured stall rate rather than a billing figure.

A serial failover pays the full detection window plus a second request on every stalled turn, in caller time rather than tokens. Every retry and every fallback spends something real, and a mechanism that does not earn its spend back should be cut. Racing earns it back because the spend scales with the failure rate, not with traffic.

Why does your fallback need testing before you trust it?

Cekura treats every fallback as a new failure surface, because it only fails in production, under load, at the moment the primary is already down. Cekura load-tests every backup provider under concurrency before routing live traffic to it, because that is the one condition the fallback will actually meet.

Two failure modes surfaced only on live traffic. A backup can return output in a subtly different format from what the pipeline expects, which is as useless to a caller as silence. And every model on a call reads and writes a shared record of the conversation, so one provider's output can break the next model that has to read it.

Neither appeared in pre-production testing. Cekura treats every backup as unproven until it has carried live traffic. The methodology for driving concurrent load at a voice agent is set out in voice load testing.

When do voice agent stalls actually happen?

Cekura observes stalls clustering at the provider's peak hours, not at yours. Cekura records the stall rate roughly doubling during the busiest hours, when the whole internet is hitting the same inference API, on telemetry that carries no pre-rollout baseline.

This is the part teams underestimate when they model cost. On a hosted model, reliability is partly hostage to traffic that has nothing to do with your product. Capacity planning that assumes a flat failure rate will under-provision recovery at exactly the hours that generate the most calls.

Cekura recommends measuring stall rate by hour before choosing a recovery policy. Retrying the same provider during its own congestion peak pours more requests into the jam that caused the stall. Routing to a different provider turns "everyone is slow right now" into a hiccup.

How does Cekura measure cost and performance together?

Cekura measures cost and performance on the same call record, so a model change shows its price effect and its tail effect at once. Cekura runs simulated calls against a voice agent, scores each turn on latency percentiles and task outcome, and monitors the same metrics on live production traffic.

Cekura's voice AI evaluation metrics define the performance side of that equation, and Cekura's voice agent performance testing guide covers the five methods for generating the measurements. A per-minute estimate tells you what an agent costs and nothing about what it delivers for the money.

Cekura also tracks the metrics that only appear under stress: barge-in handling when a caller interrupts, endpointing accuracy at turn boundaries, and recovery behavior when a provider stalls. If you are setting a rate for customers rather than measuring your own stack, how to price AI voice agents covers the commercial side.

FAQ

What is a good latency target for a voice AI agent?

Cekura recommends targeting the P95 rather than the median, because the tail is what ends calls. Per Cekura's benchmarks, each measured on more than 1,000 turns, platform medians run between 1,730 ms and 3,160 ms per turn, with P95 values reaching 5,419 ms. A caller treats a reply within about three seconds as natural and six seconds as a dropped line.

Does choosing a cheaper LLM save money on a voice agent?

Cekura answers no, not reliably. A cheaper model reduces per-token cost while changing the latency shape of every turn. Cekura records roughly one turn in fifteen stalling on a hosted provider, with no pre-rollout baseline, and a stalled turn that loses the call costs more than the token savings.

How much does a voice AI agent cost per minute?

Cekura prices the two layers that bill per minute directly: Twilio US local telephony at $0.0085 per inbound minute and Deepgram Nova-3 streaming transcription, pay-as-you-go monolingual, at $0.0048 per minute, about $0.0133 combined. The model and voice layers bill per token and per character, so any total beyond those two is an assumption about speaking rate and response length.

Is it better to retry the same model or fall back to another provider?

Cekura recommends falling back, and racing rather than switching. Cekura finds same-model retries rarely recover an empty reply, and serial failover makes the caller wait for two requests instead of one. Racing several providers and taking the first to respond bounds recovery by the fastest backup, which Cekura measures at above 99% recovery in about 1.2 seconds, on instrumentation carrying no pre-rollout baseline.

What does it cost to race requests across multiple providers?

Cekura pays for duplicate requests only on turns that stall. At Cekura's measured stall rate of roughly 7%, which carries no pre-rollout baseline, fanning to three providers adds about 0.14 extra model calls per turn on average, derived from that rate rather than measured from billing.

Which voice platform has the best cost and performance balance?

Cekura finds no single platform leads on every dimension, each measured on more than 1,000 turns. ElevenLabs records the fastest median at 1,730 ms with a 76.3% three-run pass rate. Vapi records a 2,340 ms median, the tightest P95 spread at 610 ms, and a 94.9% pass rate. Cekura recommends choosing on the metric matching your failure mode.

Cekura tests, monitors, and self-improves voice and chat agents on live traffic. Book a demo to see cost and tail latency measured on the same call.