Pipecat vs LiveKit vs OpenAI: Voice Agent Frameworks

Here's the mistake we watch teams make. They read that Pipecat, LiveKit Agents, and the OpenAI Agents SDK all “build voice agents,” pick one on a coin-flip, and discover three weeks in that it fights the thing they actually needed: phone calls, a multi-party room, or a model they're not allowed to swap. The rewrite costs a sprint. We've shipped voice agents on this stack for clients in healthcare and consumer apps, and the framework you regret is almost always the one chosen before anyone wrote down where the audio comes from.

This is a straight comparison of the three most-asked-about voice agent frameworks, current to July 2026, with the reasoning attached. We'll show what each one is under the hood, where each wins and breaks, what the code looks like, what it really costs, and a five-question test to pick one in an afternoon. No framework is “best.” One is best for your call flow, and by the end you'll know which.

Why Fora Soft wrote this comparison

We're a software team that has built real-time and AI products since 2005: 625+ projects, about 50 engineers, and a specialty in the messy seam where voice, video, and models meet. Voice agents are a big part of what clients ask us to build now, and the first real decision on every one of them is which framework carries the conversation. We've made that call enough times to have opinions with reasons behind them.

Some of what we know comes from products, not slides. BlaBlaPlay, an anonymous voice social app we built, runs OpenAI models and Whisper across thousands of users, so we've watched real-time voice behave at scale rather than in a demo. And we've shipped an AI appointment-booking voice agent (client under NDA) that answers the phone and books slots end to end. Different products, different frameworks, and that's the point of this piece.

Every version number and price below is dated and sourced. Framework facts come from the projects' own repositories and docs, captured on 2026-07-13; vendor prices come from vendor pricing pages with the date we pulled them. Where we compare, we compare on architecture and cost, not on which logo we like. For the engineering fundamentals under all of it, our AI-for-video-engineering hub goes deeper; if you'd rather we just pick and build the right one for your case, that's what our AI integration team does.

The short answer: which framework to pick

If you want the verdict before the evidence: pick Pipecat when you want to own every stage of the pipeline and bring your own transport, especially telephony. Pick LiveKit Agents when your agent lives inside a WebRTC room with real users, video, or more than two participants. Pick the OpenAI Agents SDK when you're standardized on OpenAI, you already have an audio pipe, and you want handoffs, tools, and guardrails to feel native.

The reason it's not closer: these tools sit at different layers. LiveKit Agents comes with a battle-tested media server, so rooms and multi-party turn-taking are free. Pipecat stays transport-agnostic, so it plugs into Daily, LiveKit, a raw WebSocket, or a Twilio phone leg without caring which. The OpenAI Agents SDK doesn't ship a media layer at all. It hands you agent logic and a voice wrapper and expects you to feed it audio.

So the honest first question isn't “which framework is best,” it's “where does the audio come from, and who's allowed to change the model later.” Answer those two and the choice mostly makes itself. The rest of this article is the evidence, the cost math, and the edge cases.

What Pipecat, LiveKit Agents, and the OpenAI Agents SDK actually are

Pipecat is an open-source Python framework for real-time voice and multimodal agents, created by Daily and licensed BSD-2. Its one big idea is a pipeline of frame processors: audio frames flow in, pass through speech-to-text, an LLM, and text-to-speech, and audio flows back out. Every stage is a swappable block. Latest release v1.1.0 (2026-04-27), around 12.2k GitHub stars as of 2026-07-13.

LiveKit Agents is an open-source framework (Apache-2.0) for server-side “programmable participants” that join a LiveKit room and talk to whoever else is in it. It's built on the LiveKit WebRTC media server, one of the most widely used open-source SFUs, so the hard real-time media problems are already solved beneath your agent. Latest release livekit-agents 1.5.9 (2026-05-13), about 10.5k stars.

The OpenAI Agents SDK is an agent-orchestration toolkit (handoffs, function tools, guardrails, sessions, tracing) with two ways to add voice: a chained VoicePipeline (STT → your code → TTS) and a speech-to-speech RealtimeAgent on gpt-realtime. It ships in Python and TypeScript (openai-agents). The catch worth stating up front: it has no media transport of its own, with no room, no SIP, and no WebRTC server. You bring the audio.

Three architectures: a pipeline, a room, and an agent wrapper

The clearest way to tell these apart is to draw them. Pipecat is a linear pipeline: frames march through processors you wired together, and you can tap, log, or replace any stage. LiveKit Agents is a room: your agent is a participant, the media server sits in the middle, and users, phones, and video avatars are other participants. The OpenAI Agents SDK is a wrapper around agent logic: it turns text into speech and back, but the connection to the outside world is yours to supply.

That shape decides what's easy. In a pipeline, swapping ElevenLabs for Cartesia is one line and touches nothing else. In a room, adding a second human or a screen share is native because the media server already handles it. In the agent wrapper, handoffs between specialized agents and tool calls are first-class because that's what the SDK was built for. But plugging in a phone line is on you.

Figure 1. The same voice agent, three shapes: Pipecat routes frames through a pipeline you assemble, LiveKit Agents joins a WebRTC room served by a media server, and the OpenAI Agents SDK wraps agent logic while you supply the transport.

Pipecat: where it wins, where it breaks

Pipecat wins on control and reach. Because the pipeline is yours, you can inspect every frame, insert a custom processor between STT and the LLM, and swap providers without ripping anything else out. It carries 70+ integrations across speech-to-text, LLMs, and text-to-speech, plus speech-to-speech models like OpenAI Realtime, Gemini Multimodal Live, and AWS Nova Sonic. And it's transport-agnostic: Daily WebRTC, LiveKit, a plain WebSocket, or a phone leg through Twilio, Telnyx, Plivo, Exotel, Genesys, or Vonage serializers.

That reach is exactly why teams building phone agents reach for it. Telephony is a first-class transport, not an afterthought, so an inbound call over SIP and a browser session over WebRTC run the same pipeline with a different front door. Pipecat Flows adds state-machine conversations on top, and the open-source Smart Turn model handles end-of-turn detection.

Where it breaks: you assemble more yourself. Compared with LiveKit's room model, multi-participant scenarios and video are more work, and the code is more verbose because you're wiring stages the other frameworks hide. If you don't already have a media server and you need real WebRTC rooms with many users, you'll end up bolting one on, often LiveKit, and at that point you're running both.

LiveKit Agents: where it wins, where it breaks

LiveKit Agents wins on production media. It sits on the LiveKit WebRTC media server, so session state, reconnection, barge-in, and low-latency transport come from the RTC layer instead of being retrofitted. Your agent joins a room as a participant, which makes multi-user calls, push-to-talk, video, and AI avatars native rather than bolt-on. LiveKit runs voice AI in production for OpenAI, xAI, Nvidia, and Salesforce, per its pricing page (2026-07-13).

It also ships the parts you'd otherwise hand-roll: semantic turn detection from a transformer model, integrated job scheduling to connect callers to agents, native SIP telephony, MCP support in one line, and a built-in test framework where an LLM judges whether the agent behaved. LiveKit Inference gives you one API key for popular STT, LLM, and TTS models, or you can bring your own provider keys.

Where it breaks: the room model is an opinion. If you're building a plain outbound phone bot with one caller, you're carrying a media server you don't strictly need. The abstraction that makes rooms easy also hides plumbing, so when you need to do something the framework didn't anticipate, you're reading the media server's internals. And while everything is open source and self-hostable, running the media server yourself at scale is real operational work, and many teams end up on LiveKit Cloud for exactly that reason.

OpenAI Agents SDK: where it wins, where it breaks

The OpenAI Agents SDK wins on agent logic. If your app is really a set of specialized agents that hand off to each other, call tools, and run under guardrails, this SDK makes that the easy path and treats voice as one more surface. The RealtimeAgent keeps the Realtime API's speech-to-speech feel (interruptions, mixed text and voice, tool calls) while wrapping the raw event stream so sessions, history, and handoffs are manageable. For a text agent you already have, the chained VoicePipeline adds voice in a few lines.

It's also the lightest lift if you're already an OpenAI shop. One vendor, one billing relationship, one mental model, and tracing that shows you every step of a run. Guardrails and handoffs are genuinely nicer here than what you'd wire by hand in a pipeline.

Where it breaks: there's no media layer. The quickstart plays audio through a local speaker because the SDK doesn't do transport: no room, no SIP, no WebRTC server. To put this on a phone or a website at scale, you pair it with a transport (often LiveKit) or run it inside Pipecat, which supports OpenAI Realtime as a service. And the voice models are OpenAI-centric; you can route text LLMs through LiteLLM, but you're not casually swapping the speech model the way you would in Pipecat. This is the framework you grow out of at the transport layer, not the reasoning layer.

The three frameworks, side by side

Here's the whole comparison in one table, then the same picture as a diagram. Read the “media layer” and “model lock-in” rows first — they decide more than the rest combined.

Sources: project repositories and docs, captured 2026-07-13.

Figure 2. A traffic-light read of the same seven dimensions — green where a framework is strong out of the box, amber where it's extra work.

Latency: the model stack matters more than the framework

Which framework is fastest? Wrong question. End-to-end voice latency is set by your model stack, not your orchestration layer. A speech-to-speech model like OpenAI Realtime answers in roughly 300 ms end to end; a STT + LLM + TTS cascade stacks three serial hops and adds about 300–800 ms on top. Frame routing, room joins, and pipeline overhead are tens of milliseconds: real, but small next to the model.

Why does that matter for the choice? Because people compare framework “benchmarks” that are really benchmarks of whatever STT, LLM, and TTS the author happened to wire up. Put the same Deepgram Nova-3, GPT-4.1-mini, and Cartesia Sonic stack behind Pipecat and LiveKit Agents and you'll land within a coin-flip of each other. The target to beat is human turn-taking: people leave about a 200 ms gap between turns (Stivers et al., PNAS 2009), which is why sub-second response feels natural and a two-second pause feels broken.

Figure 3. Where the milliseconds go. The model path (cascade vs speech-to-speech) dominates the budget; the framework’s own overhead is the thin sliver on the right.

The practical takeaway: choose the framework for fit, then hit your latency target by choosing models — a speech-to-speech model for the most natural turns, or a fast cascade (streaming STT, a small LLM, a low-latency TTS like Cartesia or a Flash-tier voice) when you want cheaper minutes and can tolerate a beat more delay. All three frameworks let you do either.

Transports and telephony: getting audio in and out

This is where the frameworks diverge most, so it's worth being concrete. A voice agent needs audio to arrive from somewhere (a browser over WebRTC, a phone call over SIP/PSTN, or a raw socket) and to leave the same way.

Pipecat treats transport as a pluggable stage. Daily WebRTC and a small built-in WebRTC transport cover browsers; LiveKit is available as a transport too; and telephony arrives through serializers for Twilio, Telnyx, Plivo, Exotel, Genesys, and Vonage. The same pipeline serves a web widget and an inbound phone number by changing the front door, which is why phone-first teams like it.

LiveKit Agents gets transport from the platform beneath it. Browsers connect over WebRTC to the media server; phones connect through LiveKit SIP; and because it's a room, an agent, a human, and a phone caller can share one session. If you're already using LiveKit for real-time media, the agent slots in with no new plumbing.

The OpenAI Agents SDK supplies none of this. It expects audio buffers and hands you audio back. In production that means pairing it with a transport — LiveKit, a CPaaS phone leg, or Pipecat wrapping OpenAI Realtime as a service. If you want the build details for the OpenAI side, our guide to wiring the Realtime API across WebRTC, SIP, and WebSockets covers the transport question end to end.

Turn detection, interruptions, and feeling natural

The difference between a demo and a shippable agent is turn-taking: knowing when the human is done talking, and stopping mid-sentence when they interrupt. Get it wrong and the agent talks over people or sits in awkward silence. All three frameworks address it; they just draw the line in different places.

LiveKit Agents ships a semantic turn detector, a transformer model that predicts whether a speaker is actually finished rather than just pausing, plus interruption handling in the room layer. Pipecat pairs Silero voice-activity detection with its open-source Smart Turn model for the same job, and interruptibility is built into the pipeline: when the user speaks, the assistant's audio stops. The OpenAI Agents SDK leans on the Realtime API's server-side voice-activity detection and automatic interruption for the speech-to-speech path.

In practice this is closer than the marketing suggests. Semantic turn detection is a genuine edge for messy, real-world speech, and LiveKit and Pipecat both invest in it heavily. If natural turn-taking on hard audio is central to your product, it's worth prototyping the exact model each uses rather than trusting a spec sheet.

What the code actually looks like

Reading the setup for each tells you more than any feature list. LiveKit Agents reads as “configure a session, hand it a room”: the media details are hidden.

session = AgentSession(
    vad=silero.VAD.load(),
    stt="deepgram/nova-3",
    llm="openai/gpt-4.1-mini",
    tts="cartesia/sonic-3",
)
agent = Agent(instructions="You are a friendly assistant.")
await session.start(agent=agent, room=ctx.room)

Pipecat reads as “list the processors, then run them”: the pipeline is explicit, which is the point.

pipeline = Pipeline([
    transport.input(),      # audio in (Daily, WebSocket, SIP...)
    stt,                    # e.g. Deepgram
    llm,                    # e.g. OpenAI
    tts,                    # e.g. Cartesia
    transport.output(),     # audio out
])
task = PipelineTask(pipeline)

The OpenAI Agents SDK reads as “define agents and tools, wrap in a voice pipeline” — note there's no transport in sight, so you feed it audio yourself.

agent = Agent(name="Assistant", instructions="Be concise.",
              tools=[get_weather], handoffs=[spanish_agent])
pipeline = VoicePipeline(workflow=SingleAgentVoiceWorkflow(agent))
result = await pipeline.run(audio_input)   # you provide audio_input

Three philosophies in three snippets: LiveKit hides the media, Pipecat exposes the pipeline, OpenAI centers the agents and leaves the audio to you. None is wrong; they match the three architectures from Figure 1.

What each really costs to run

Here's the part vendors bury: the frameworks are free. Pipecat and LiveKit Agents are open source; the OpenAI Agents SDK is a free library. What you pay for is (1) hosting, (2) the models, and (3) telephony if you're on the phone. The models are the same price whichever framework wraps them, so the framework choice barely moves the bill.

Managed hosting lands in the same place across the board. LiveKit Cloud charges $0.01 per agent-session minute after plan allotments (Build $0, Ship $50/mo with 5,000 minutes, Scale $500/mo with 50,000; livekit.com/pricing, 2026-07-13). Pipecat Cloud charges $0.01 per active minute on its agent-1x profile, $0.0005/min reserved (daily.co, 2026-07-13). Self-hosting either open-source framework trades that per-minute fee for a fixed VM you operate — a Hetzner-class box runs roughly $50–$80/month and handles many concurrent sessions, because the heavy compute is the model API, not the orchestration.

Let's do the arithmetic on a phone agent at 10,000 minutes a month, cascade stack, prices dated 2026-07-13:

Look at the shares. Hosting is ~$100 and the models are ~$373 — and that $373 is identical whether Pipecat, LiveKit Agents, or the OpenAI Agents SDK is holding the pieces. Self-host the framework and you knock the hosting line down to a ~$60 fixed VM, landing near $473. The spread between frameworks is noise; the spread between model choices (a $0.03/min premium TTS versus a $0.009/min one, or a speech-to-speech model at $0.06–$0.11/min) is where real money moves. For the speech-to-speech math in detail, see our OpenAI Realtime API pricing breakdown.

Mini-case: picking a framework for a booking voice agent

A client came to us (under NDA) with a manual scheduling desk: staff answering the phone all day to book and reschedule appointments. They wanted an AI agent to take those calls end to end. The requirement that decided everything was in the first sentence — “take those calls.” This was phone-first: inbound SIP, one caller at a time, no video, no room full of people.

So we didn't reach for the room model. LiveKit Agents would have carried a media server we didn't need for a single-caller phone bot, and the OpenAI Agents SDK would have meant bolting on a transport anyway. We built the pipeline explicitly — SIP in, streaming STT, one LLM with the booking tools, low-latency TTS out — so telephony was a first-class front door and every stage stayed swappable. Barge-in mattered (people interrupt when they hear a slot they want), and pipeline-level interruption handled it.

The agent now answers, checks availability, books, and reschedules without a human in the loop, and the transport-neutral pipeline means we can move the phone leg between providers without touching the conversation logic. The lesson generalizes: we started from where the audio came from, and the framework fell out of it. Want a similar assessment for your call flow? Grab 30 minutes with us and we'll map it.

A decision in five questions

Answer these in order. The first “yes” that points somewhere usually settles it.

1. Where does the audio come from? A phone line or your own transport points to Pipecat. A WebRTC room with real users points to LiveKit Agents. Already have a transport and just need agent logic? The OpenAI Agents SDK.

2. Do you need more than two participants, or video? If yes (group calls, screen share, avatars), LiveKit's room model is the path of least resistance. If it's always one human and one agent, you don't need it.

3. Are you allowed to swap the model later? If procurement or cost will force model changes, favor the vendor-neutral frameworks (Pipecat, LiveKit Agents). If you're committed to OpenAI, the OpenAI Agents SDK is the smoothest.

4. How much of the pipeline do you want to own? Want to inspect and replace every stage? Pipecat. Want the media plumbing hidden so you focus on behavior? LiveKit Agents. Want to focus on agents and tools? OpenAI Agents SDK.

5. Who runs it in production? A small team that wants managed hosting leans on LiveKit Cloud or Pipecat Cloud. A team ready to operate infrastructure self-hosts the open-source framework and keeps the per-minute fee. If nobody wants to run any of it, that's a signal you want a fully-managed platform instead — see the next section.

Figure 4. The same five questions as a decision tree — start at the audio source and follow the branch to a framework.

When NOT to use any of these frameworks

Sometimes the right answer is none of them. If you want a voice agent live this week and you don't have engineers to run infrastructure, a fully-managed platform like Vapi or Retell hides the framework entirely and charges a premium per minute for the privilege. That premium is real, but so is shipping on Friday. We compare that trade-off directly in our look at AI call-assistant APIs.

Skip the frameworks, too, if all you need is a single-model browser demo with no telephony, no multi-party, and no tool calls. A thin app talking straight to the OpenAI Realtime API over WebRTC is less code than any framework, and you can graduate to one later when the requirements grow. Adding a full framework to a toy is overhead you'll feel.

And if your product is fundamentally a phone system (IVR trees, queues, routing) with a sprinkle of AI, start from a telephony platform and add an agent, not the other way around. The framework should serve the product's center of gravity, not fight it.

Switching frameworks later: how locked in are you

Nobody wants to bet the product on a call they'll regret, so here's the honest read on reversibility. Your business logic (prompts, tools, the booking or support flow) is portable across all three; it's plain Python (or TypeScript) that doesn't care what moves the audio. That's the good news, and it means no choice here is a one-way door.

What's sticky is the media layer. Move off LiveKit Agents and you give up the room model and re-solve transport; move off the OpenAI Agents SDK's speech-to-speech path and you rebuild turn-taking around a cascade. Pipecat is the least sticky by design, since transport is already a swappable stage — you can even run OpenAI Realtime or a LiveKit transport inside it. Interestingly, these tools interoperate: Pipecat can use LiveKit as a transport, and both can call OpenAI models, so “switching” is often adding a piece rather than a rewrite.

Our rule of thumb: keep your conversation logic in your own modules, not scattered through framework callbacks, and treat the framework as the shell around it. Do that and a future migration is measured in days, not months — which is also how we build them so clients aren't trapped.

FAQ

What is Pipecat?

Pipecat is an open-source Python framework from Daily for building real-time voice and multimodal AI agents. It models a conversation as a pipeline of swappable frame processors — speech-to-text, an LLM, and text-to-speech — and stays transport-agnostic, so the same agent can run over WebRTC or a phone line. It's BSD-2 licensed with around 12.2k GitHub stars (July 2026).

Pipecat vs LiveKit: which is better?

Neither is universally better; they fit different jobs. Pipecat is better when you want a transport-agnostic pipeline you fully control, especially for phone agents. LiveKit Agents is better when your agent lives in a WebRTC room with real users, video, or multiple participants, because the media server and turn detection come built in. Decide by where your audio comes from and whether you need multi-party or video.

Is LiveKit Agents free and open source?

Yes. The LiveKit Agents framework and the underlying LiveKit media server are both open source under Apache-2.0, and you can run the entire stack on your own servers for free. LiveKit Cloud is the paid, managed way to run it: $0.01 per agent-session minute after plan allotments, with Build ($0), Ship ($50/mo), and Scale ($500/mo) tiers (livekit.com/pricing, 2026-07-13).

Does the OpenAI Agents SDK handle telephony?

No, not on its own. The OpenAI Agents SDK provides agent logic and a voice layer (a chained VoicePipeline and a speech-to-speech RealtimeAgent) but no media transport — no SIP, no WebRTC server. For phone calls you pair it with a transport such as LiveKit, a CPaaS provider, or Pipecat, which supports OpenAI Realtime as a service.

Can you run Pipecat on LiveKit transport?

Yes. Pipecat ships a LiveKit transport alongside Daily WebRTC, a small built-in WebRTC transport, and WebSocket options. That means you can keep Pipecat's pipeline model while using LiveKit's media server for transport — a common pattern when a team wants Pipecat's control but LiveKit's WebRTC infrastructure.

Which framework has the lowest latency?

In practice they're within a coin-flip of each other, because latency is set by your model stack, not the framework. A speech-to-speech model answers in roughly 300 ms; a STT+LLM+TTS cascade adds about 300–800 ms. Framework overhead is tens of milliseconds. Choose the framework for fit, then hit your latency target by choosing a speech-to-speech model or a fast cascade.

How much does each framework cost?

The frameworks themselves are free and open source (Pipecat, LiveKit Agents) or a free library (OpenAI Agents SDK). You pay for hosting, models, and telephony. Managed hosting is about $0.01/min on both LiveKit Cloud and Pipecat Cloud (July 2026); self-hosting trades that for a fixed VM. The model line (~$0.04/min for a cascade) is the same regardless of framework and usually the biggest number on the bill.

Can I switch frameworks later without a rewrite?

Mostly, if you build for it. Your prompts, tools, and conversation flow are portable Python or TypeScript; the sticky part is the media layer. Keep conversation logic in your own modules rather than framework callbacks, and a migration is usually days of work. Because these tools interoperate — Pipecat can use a LiveKit transport, and all three can call OpenAI models — switching is often adding a component rather than starting over.

What to read next

Which framework should you ship on?

Start from the audio, not the logo. Pipecat if you own the transport or you're on the phone and want a pipeline you control. LiveKit Agents if your agent belongs in a WebRTC room with real people, video, or many participants. The OpenAI Agents SDK if you're all-in on OpenAI, someone else owns the media path, and your value is in agent orchestration. Latency comes from your models, not the framework; the bill comes from your models too, so the framework choice is about fit, not cost.

The comparison on this page is yours to reuse. Run your call flow through the five questions and you'll have a defensible answer. But if you'd rather hand it to a team that has shipped agents on all three and watched the invoices, that's us. We'll pick the framework, model the cost per minute, and build the version that fits your product — not the one that's loudest this quarter.