Best Open-Source Voice Agent Stacks for Small Call Centers: LiveKit, Pipecat, Vocode and the Cost Math That Decides It

A ten-seat call center burns two weeks comparing feature tables, picks the stack with the most GitHub stars, and only discovers during the pilot that the real problems were the SIP bridge, the endpointer cutting callers off, and a repository that has not shipped a commit since 2024.

💡 What You Will Learn

A ten-seat call center burns two weeks comparing feature tables, picks the stack with the most GitHub stars, and only discovers during the pilot that the real problems were the SIP bridge, the endpoin

📜 Table of Contents

• The three stacks, as of today
• Gate 1: how the call gets in
• Gate 2: interruption, which is where demos die
• Gate 3: the latency budget
• Gate 4: the cost math
• Gate 5: can you see why the call failed
• What a two-week pilot should actually measure
• So which one
• FAQ

The question a twelve-seat call center actually asks is not "which framework has the nicest API". It is: can this thing interrupt politely, can I see why it failed on call 41, and who is awake when the phone bridge dies at two in the morning. Three open-source stacks dominate the conversation right now, and they answer those questions differently.

Every number below was pulled from the GitHub API and PyPI on 2026-10-24. Where a vendor does not publish something, this article says so instead of inventing a figure.

The three stacks, as of today

• LiveKit Agents (repo livekit/agents): 14,907 stars, Apache-2.0, last push 2026-10-23, 814 open issues. PyPI livekit-agents 1.8.8. Telephony arrives through LiveKit own SIP stack (livekit/sip, 486 stars, a SIP to WebRTC bridge), and the framework ships dispatch APIs for scheduling agent jobs and a transformer-based semantic turn detector for deciding when a caller has finished speaking.
• Pipecat (pipecat-ai/pipecat): 16,751 stars, BSD-2-Clause, last push 2026-10-23, 432 open issues. PyPI pipecat-ai 1.13.0. Its transports include Daily WebRTC, a FastAPI websocket server, LiveKit, SmallWebRTC, Vonage, WhatsApp and local audio, and its serializers cover Twilio, Plivo, Telnyx, Exotel, Genesys and Vonage.
• Vocode (vocodedev/vocode-core): 3,806 stars, MIT, two open issues, and a last push of 2024-11-15. PyPI vocode 0.1.113. That date is the whole story for a production decision: twenty-three months without a commit means no fixes for whatever the speech and telephony SDKs broke underneath it.

Stars measure attention, not fitness. The useful split is different: LiveKit is a media infrastructure company that added agents; Pipecat is a pipeline library that connects to whoever you already pay for telephony; Vocode is a well-shaped architecture that stopped moving.

Gate 1: how the call gets in

This is the decision most teams get backwards. If your numbers already live on a SIP trunk or a carrier you cannot leave, you need a bridge from that trunk into the agent's audio loop. LiveKit solves it inside its own product: SIP calls land as participants in a room, and the agent joins the room. Pipecat solves it by speaking the serializers your carrier already offers, so a Twilio or Telnyx call becomes a websocket stream into the pipeline.

Neither is universally better. The LiveKit route assumes you are willing to run LiveKit (and usually its SIP service) yourself or pay for the hosted version. The Pipecat route assumes your carrier's media stream is reliable, which is true for the large ones and a coin flip for resellers. Write down which assumption you can actually satisfy before comparing features.

Gate 2: interruption, which is where demos die

Callers talk over bots constantly. Three things have to work together: voice activity detection that is not triggered by background noise, an endpointer that decides the caller finished rather than paused, and a barge-in path that stops the TTS stream mid-sentence instead of finishing the thought at a customer.

Both frameworks support all three, and both take tuning. The parameter that ruins more pilots than any other is the silence threshold for endpointing: too short and the bot interrupts anyone who thinks for 400 milliseconds, too long and every turn feels like a satellite call. Start at half a second of silence, then measure how often real callers get cut off in the first twenty recordings. LiveKit semantic turn detection exists specifically to soften this trade-off by using a model rather than a fixed timer, which helps on hesitant speakers and costs a little latency.

Gate 3: the latency budget

Perceived responsiveness is a budget you spend across four stages: endpointer wait, speech-to-text finalisation, model time to first token, and text-to-speech first audio. Add them and compare with the interval where callers start saying "hello?". In practice a total under about a second feels conversational, and anything past two seconds produces the double-hello that ruins the first impression.

Instrument it before you optimise. Stamp a timestamp when the caller stops speaking, when the transcript finalises, when the first token arrives, and when the first audio frame leaves. Without those four stamps, every latency argument becomes an opinion, and the usual fix applied blindly (streaming everything) trades a small win for a large bill.

Gate 4: the cost math

Four cost buckets, and only one of them is the framework: telephony minutes, speech recognition, speech synthesis, and model tokens. The framework itself is free in all three cases, so the stack choice changes cost only through how efficiently it lets you swap providers and whether you can self-host the speech layers.

Self-hosting speech on a GPU is a volume game. The break-even in call minutes per month is roughly:

break_even_minutes = (gpu_hour_cost * 730) / api_cost_per_minute

At a GPU that costs 0.50 per hour and API speech that costs 0.02 per minute, that is about 18,250 minutes a month. The table below is the same arithmetic across a few combinations, so you can find your own row instead of arguing about which provider is cheap:

GPU per hour    at 0.01/min    at 0.02/min    at 0.05/min
0.30               21,900         10,950          4,380
0.50               36,500         18,250          7,300
1.00               73,000         36,500         14,600

Two caveats keep this honest. First, those minutes are total talk time, not concurrent calls, and one GPU can serve several concurrent streams depending on model size, so the real capacity is higher than the table implies. Second, self-hosting adds an on-call rotation, which is a cost that never appears in the spreadsheet and always appears in the first outage. A ten-seat shop doing 6,000 minutes a month is nowhere near the break-even and should stay on APIs.

Gate 5: can you see why the call failed

Every failed call has a shape, and the recording alone rarely explains it. What you need per call: the transcript with timestamps, which tools the agent called and with what arguments, the latency stamps from gate three, and the handoff reason if a human took over. Both LiveKit and Pipecat let you attach tracing, and both expect you to decide what a trace contains. Decide before the pilot, not after the first complaint, because retrofitting tracing into a live phone system means reproducing the failure from memory.

The metric that matters in a pilot is containment: calls resolved without a human, out of calls that reached the bot at all. Transfers to a queue are not failures; transfers after ninety seconds of confused looping are. Record the transfer reason as a category, and the third or fourth category that appears is usually the business case for the next iteration.

What a two-week pilot should actually measure

• Fifty real calls on a secondary number, recorded with consent and announced.
• p50 and p95 end-to-end latency, from the four stamps in gate three.
• Interruption errors per call, counted by hand on the first twenty recordings.
• Containment rate split by call reason, not averaged into one number.
• Cost per call, computed from your own invoices rather than from a vendor calculator.

Two weeks is enough to see whether the endpointer is wrong. It is not enough to declare victory, and teams that skip the pilot usually discover the acoustic problems in production, at volume, with customers.

So which one

If you will run your own media infrastructure and want SIP handled as a first-class citizen, LiveKit is the safer base: active development, a dedicated SIP bridge, and a hosted path if self-hosting stops being fun. If your telephony already lives on Twilio, Telnyx, Plivo or Vonage and you want the agent to be a pipeline you can swap providers inside, Pipecat's serializer coverage is the shortest route and its transport list means you can start on websockets today and move to WebRTC later.

Vocode is worth reading for its abstraction of conversation state, and worth avoiding as a dependency for a system that must survive the next two years of SDK churn. That is not a criticism of its design; it is a statement about commit dates.

One more consideration that rarely makes it into comparison posts: both live stacks change fast. LiveKit Agents and Pipecat both shipped within the last day of writing, and both carry several hundred open issues. Pin versions, read release notes before upgrading, and keep the speech providers behind your own interface so a breaking change costs an afternoon rather than a rewrite.

FAQ

Can I run any of these without a GPU? Yes. All three are orchestration layers; the models run wherever you point them, including hosted APIs. A GPU only enters if you self-host speech or the language model.

Which handles multiple languages on one line? Both live frameworks can switch STT and TTS per turn. Whether the switch is graceful depends on your endpointer and on how quickly the language detector settles, so test it on real callers rather than on clean audio.

Is a framework even necessary? For a single scripted flow, a telephony provider's built-in bot builder is cheaper to operate. Frameworks earn their place when the conversation needs tools, retrieval, escalation logic and per-call traces.

What about compliance recording? Out of scope for the framework. Consent announcements, retention and redaction are your obligations, and the trace store you build for gate five is usually where they get handled.

If the calls need transcripts that stay on your own hardware, the self-hosted transcription comparison covers those stacks. If the language model behind the agent runs on your own server, the Linux serving guide covers the systemd, GPU and throughput side that this article assumes.