We've evaluated and worked with several voice AI platforms while building Betula, and our requirements have evolved along with the product. This guide shares what we learned from that process and the factors that ended up mattering most to us.
Our choices were driven primarily by the level of flexibility and control we needed, the underlying real-time infrastructure and its impact on latency, pricing, and how quickly the platform was evolving.
This isn't an exhaustive comparison of every voice AI platform. It's a practical guide shaped by the product we were building.
This is a deeper look at the first point in our earlier post, *Ten things we've learned building voice agents*: choose the right platform for what you're building. Here, we'll go into how we made that decision, why our choice changed as Betula evolved, and what we'd consider if we were making it again today.
Table of contents
- The first decision: how much of the stack do you want to own?
- Why we started with Vapi
- Why we moved to LiveKit
- Latency and infrastructure
- Pricing: model the whole call
- Other platforms worth considering
- What we'd look at if choosing today
- Closing thoughts
The first decision: how much of the stack do you want to own?
Deepgram's *The Definitive Guide to Voice AI Agents* has a useful way of looking at the landscape. It broadly groups approaches into four categories: DIY frameworks and custom stacks, unified APIs or end-to-end runtimes, managed voice agent platforms, and enterprise conversational suites.
For our purposes, we found ourselves thinking about a simpler spectrum.
At one end are managed voice agent platforms such as Vapi and Retell. They handle much of the orchestration and infrastructure needed to get a voice agent running.
Further down the stack are frameworks and real-time infrastructure such as LiveKit Agents and Pipecat, which give developers more direct control over how the real-time application works.
The categories aren't rigid. In fact, they're getting less rigid as these platforms add capabilities.
But the underlying question was useful for us:
How much do we want the platform to handle, and how much do we need to control ourselves?
Why we started with Vapi
We originally built Betula on Vapi.
It was a good place to start. We could choose the speech recognition, LLM and voice providers we wanted while Vapi handled much of the real-time orchestration required to put them together.
That let us spend our time building the product rather than the infrastructure underneath it.
And for many voice agents, that may be exactly the right abstraction.
Our requirements changed as the product evolved.
Why we moved to LiveKit
One example explains the change fairly well.
Betula can handle a phone call for its owner. While the AI is talking with the caller, the owner can send the assistant a text. The agent can incorporate that information into the live conversation and speak on the owner's behalf without the owner having to join the call.
From the user's perspective, that's just a feature.
From an engineering perspective, we need fairly deep control over the live session, its state and the data moving through it.
As we added capabilities like this, the question we were asking changed from:
How quickly can we build a voice agent?
to:
How much control do we have over the live interaction?
That was a major reason we moved to LiveKit.
LiveKit Agents gives us a framework for building the agent while the underlying LiveKit platform gives us direct access to the real-time environment it participates in.
We increasingly wanted the conversation itself to become part of our application's programmable surface.
Latency and infrastructure
The second major consideration was latency.
For a typical cascaded voice agent, a conversational turn looks roughly like this:
Caller → telephony → media transport → STT → LLM → TTS → media transport → caller
Each stage takes time. Some also introduce another network hop.
This made us look beyond model benchmarks and think about where the audio and inference were actually going.
According to LiveKit's Cloud architecture documentation, LiveKit Cloud operates a globally distributed mesh of real-time servers. Its architecture uses a global mesh SFU, with participants connecting to the nearest edge.
That was attractive to us because real-time media infrastructure is fundamental to LiveKit's architecture rather than something hidden behind a voice-agent API.
LiveKit Telephony also brings SIP and PSTN calls into that same real-time environment.
There is a second part of the latency problem: inference.
LiveKit Inference provides a common interface to STT, LLM and TTS models from multiple providers. Not all of those models physically run on LiveKit infrastructure — many are still provided by the underlying model provider.
But LiveKit also hosts some inference itself. Its current recommended default LLM for voice agents, Gemma 4 31B, is an open-weight model that LiveKit describes as latency-optimized and served on its own infrastructure.
That can remove an external LLM hop from the critical path.
For us, the broader lesson was:
Don't just look at which models a voice platform supports. Look at the path through the entire system.
Where does the audio go? Where does STT run? Where does the LLM run? Where does TTS run? How many network boundaries does a conversational turn cross?
In voice, the user experiences the cumulative answer to all of those questions as latency.
Pricing: model the whole call
Pricing was another major factor, and this gets complicated quickly.
For a cascaded voice agent, we think about the cost roughly as:
Platform + telephony + media/infrastructure + STT + LLM + TTS
Some platforms bundle parts of this. Others expose them separately.
Platform
First is whatever the voice platform or runtime charges.
A managed platform fee isn't simply overhead. You're paying for infrastructure and orchestration your engineering team would otherwise have to build and operate.
Moving lower in the stack changes that cost structure, but it doesn't make the underlying infrastructure free.
The useful number isn't simply the advertised platform cost per minute.
It's the cost of an actual production minute for your particular agent.
STT, LLM and TTS
Then there is the cascaded model pipeline:
STT → LLM → TTS
STT and TTS costs generally track audio or generated speech. LLM cost behaves differently because it is largely token-driven.
And this means the product itself can materially affect the cost.
Take memory.
A relatively stateless agent might send a system prompt and the most recent conversation turns to the LLM.
An assistant with persistent memory might retrieve previous conversations, user preferences, outstanding commitments or other relevant memories and inject them into the context.
That means more input tokens.
The same applies to long prompts, retrieved documents, tool results and conversation history.
So two voice agents using the same LLM for the same number of minutes can have very different LLM costs.
The architecture and behavior of the agent partly determine its inference economics.
Telephony
Then there is the telephone network itself.
If you're using an external provider such as Twilio for phone numbers and PSTN/SIP connectivity, that cost has to be included too.
A simplified path might therefore be:
Twilio/PSTN → media transport → STT → LLM → TTS → media transport → Twilio/PSTN
Some platforms also provide integrated telephony. LiveKit Telephony brings SIP-based calls into LiveKit's real-time infrastructure.
Again, the goal isn't to argue that one approach is inherently cheaper. It's to make sure all of the same layers are being counted when comparing them.
Cost and latency can interact
Cost and latency aren't entirely independent decisions.
LiveKit Inference exposes STT, LLM and TTS models through a common interface, while LiveKit also directly hosts its latency-optimized open-weight Gemma model.
That creates another architectural decision.
You might choose a model because it is cheaper per token. Or because it performs better for your use case. Or because it produces a faster time-to-first-token. Or because its deployment location reduces another network hop.
For a real-time agent, we'd therefore look at:
Model quality + inference cost + network latency + time-to-first-token
rather than optimizing any one of those variables in isolation.
How we'd compare costs
We'd build the model around representative production calls rather than a nominal one-minute benchmark:
Telephony
- Platform / agent runtime
- Media transport
- STT
- LLM input tokens
- LLM output tokens
- TTS
- Additional infrastructure
Then we'd run different call profiles.
A simple call with little context.
A longer conversation.
A call where the agent retrieves memories or previous interactions.
A call involving multiple tool calls.
And we'd run those numbers again at the volume we hope to reach.
That gives us a much more useful comparison than two headline per-minute prices.
Other platforms worth considering
Our direct experience was primarily with Vapi and LiveKit, so we don't want to turn this into a ranking of platforms we haven't used extensively.
But there are several alternatives we'd include in an evaluation.
Retell
Retell AI is an obvious alternative if you're considering a managed voice agent platform. It provides telephony, model selection, testing, monitoring and APIs, and its pricing page is useful for seeing how the different components of a voice call contribute to cost.
If Vapi represents the level of abstraction you want, we'd evaluate Retell alongside it.
Pipecat
Pipecat is interesting for a different reason.
It's an open-source Python framework for real-time voice and multimodal agents, but its transport layer is modular. According to its transport documentation, Pipecat can work with LiveKit, Daily, WebRTC, WebSockets and other transports.
So LiveKit and Pipecat aren't exact equivalents.
With LiveKit, the agent framework and LiveKit's own real-time media infrastructure can be part of the same ecosystem.
With Pipecat, you can choose the agent framework and real-time transport separately — including using LiveKit itself as the transport.
Depending on what you're building, that separation may be useful.
Unified APIs
There's also a middle ground between a managed agent platform and assembling more of the stack yourself.
Deepgram's Voice Agent API integrates speech recognition, LLM interaction and speech generation through a unified real-time interface.
The OpenAI Realtime API takes another approach, including direct speech-to-speech interaction.
These are good examples of why Deepgram's four-level taxonomy is useful even though we found the simpler managed-versus-more-control spectrum useful for our own decision.
What we'd look at if choosing today
If we were evaluating voice AI platforms from scratch today, these are the things we'd look at first.
Control. What might we eventually want to do during a live conversation that the platform wasn't explicitly designed to do?
Infrastructure and latency. How does audio move through the system? Where are the media servers? Where does inference happen? How many network hops are in the conversational path?
Total cost. Not just the platform fee. Telephony, media, STT, LLM input and output tokens, TTS and supporting infrastructure all matter.
Model flexibility. STT, LLM and TTS models are improving too quickly for us to want unnecessary dependence on any single provider.
How much infrastructure we want to own. More control also means more engineering responsibility. That's part of the trade-off, not an argument for or against either approach.
How quickly the platform is evolving. Voice AI is moving fast enough that release cadence, infrastructure investment, model integrations and developer tooling matter alongside today's feature set.
Closing thoughts
Starting with Vapi was the right decision for us. It let us build quickly without first building much of the real-time machinery underneath the agent.
Moving to LiveKit was also the right decision for us.
Our product had changed.
As Betula evolved, we increasingly needed the live conversation itself to become part of our application's programmable surface. LiveKit's agent framework, real-time infrastructure, inference layer and economics were a better fit for where the product was going.
The principle we'd carry into our next platform decision is simple:
Choose the highest level of abstraction that still gives you the control your product needs.
A managed platform can help you move remarkably quickly. Moving lower in the stack becomes worthwhile when the abstraction starts constraining what you want to build.
And the right choice can change as the product evolves.
Thanks to ChatGPT for editorial support on this post.