On 12 September 2026 we counted the integration directories in both repositories: LiveKit Agents ships 77 packages under livekit-plugins/, of which 51 expose a speech-to-text, text-to-speech, LLM or realtime class; Pipecat ships 62 directories under src/pipecat/services/, of which 55 do. The model ecosystems are near-parity. The transport decides.
The honest comparison is architectural, not a feature tick-list. LiveKit Agents grew out of a WebRTC media server and brings telephony in through a SIP bridge. Pipecat, published by Daily, is a pipeline framework with pluggable transports. That origin explains nearly every divergence below: plugin counts, the Apache-2.0 versus BSD-2-Clause licence split, turn detection, OpenTelemetry span shape, Python versus TypeScript, and what your work is worth if you switch.
They are not mutually exclusive, and most comparisons get this wrong
Pipecat ships a LiveKit transport at src/pipecat/transports/livekit/, with a dedicated runner at src/pipecat/runner/livekit.py, and Pipecat’s own README lists “LiveKit (WebRTC)” in its transport table alongside Daily, SmallWebRTCTransport, Vonage, WebSocket Server and WhatsApp. Pipecat 1.10.0, released 12 September 2026, added LiveKitParams.audio_out_queue_size_ms to tune the outgoing LiveKit audio buffer.
So “LiveKit or Pipecat” is a false binary: a working combination is Pipecat orchestrating the pipeline while LiveKit carries the media and the SIP leg. Read what follows as a question about which project owns your media path.
The Transport Ownership Rule
The Transport Ownership Rule: choose the framework whose media path you are already willing to operate. The model plugins overlap on 37 providers as at 12 September 2026, so they are not the deciding factor; the transport is the part you cannot cheaply undo.
Here it is as a decision table. Pick the first row that describes you.
| If your constraint is | Pick | Because |
|---|---|---|
| You already run LiveKit rooms for video or WebRTC | LiveKit Agents | The agent joins the room as a participant: no second media plane, no second set of credentials. |
| You already have a Twilio, Telnyx, Plivo, Exotel or Genesys media stream and no WebRTC | Pipecat | Six carrier serializers ship in src/pipecat/serializers/. You terminate the websocket yourself and never introduce a media server. |
| You need SIP trunking in week one and do not want to build the bridge | LiveKit Agents | livekit/sip is a SIP bridge (dial in, dial out, digest auth, DTMF) driven by two calls: CreateSIPTrunk, then CreateSIPDispatchRule. |
| Your inference must stay on your own hardware, models included | Pipecat | Service classes run models in-process. WhisperSTTService transcribes “with a locally-downloaded Whisper model”; also piper, xtts, moonshine, funasr, pocket_tts. |
| Your team writes TypeScript and will not maintain a Python service | LiveKit Agents | agents-js is the only first-party non-Python server option. Pipecat’s JavaScript is client SDKs. |
| You want turn-detection weights you can relicense, fork or run elsewhere | Pipecat | Smart Turn v3.2 ships in-repo under BSD-2-Clause; LiveKit’s turn models sit under a separate licence. |
| Your observability stack must read GenAI traces without a translation layer | LiveKit Agents 1.8.0+ | 1.8.0 moved spans, metrics and logs onto the OpenTelemetry GenAI semantic conventions. |
| You want the pipeline itself to be the composable unit | Pipecat | Its README calls each pipeline an agent, composable with “handoff, parallel fan-out, sidecar workers, or distributed deployments”. |
What we counted, and why an integration count measures packaging, not capability
Every comparison quotes a plugin number from a README. We counted the directories instead, on 12 September 2026, at livekit/agents commit 34a4e8f and pipecat-ai/pipecat commit f67c18a, applying one rule to both: count a directory only if it contains a source file whose name begins with stt, tts, llm or realtime. Blunt on purpose — reproducible, and the same on both sides.
| Repository | Directories | After the speech-path rule | What the excluded ones are |
|---|---|---|---|
| livekit/agents (Python) | 77 | 51 | 16 avatar vendors, Silero VAD, NLTK, a LangChain adapter, Krisp noise filtering, a Chromium plugin, an eval exporter, the deprecated turn-detector plugin, two internal packages, a template |
| pipecat-ai/pipecat | 62 | 55 | 3 avatar vendors, a vision model, a memory service, a search service, a gateway client |
| livekit/agents-js (TypeScript) | 38 | 25 | 9 avatar vendors, Silero, Krisp, the first-party turn detector, a deprecated Mistral alias |
Now the caveat that makes the number honest. A directory count measures how a project packages integrations, not what it can reach — and it cuts both ways. By vendor name the sets give 37 providers in both, 14 only in LiveKit, 18 only in Pipecat. Three things qualify that. First, at least six of that 18 are reachable from LiveKit anyway, because its OpenAI plugin exposes with_ollama(), with_openrouter(), with_deepseek(), with_together(), with_sambanova() and with_nebius() against OpenAI-compatible endpoints. Second, the same effect inflates Pipecat’s side: 20 of its 55 directories are thin OpenAILLMService subclasses whose substantive content is a default base_url — TogetherLLMService sets https://api.together.xyz/v1 and little else — the same mechanism LiveKit implements as a static method inside one directory, where it costs nothing in the count. Third, services/grok/llm.py is a deprecated shim re-exporting services/xai/llm.py, and LiveKit packages xAI too — so 54 Pipecat directories are distinct against LiveKit’s 51, and the genuinely Pipecat-only count is 17, not 18.
What survives is real: Pipecat packages local, in-process runners — whisper, piper, kokoro, moonshine, xtts, funasr, pocket_tts — as first-class services, while LiveKit points an OpenAI-compatible client at a server you run. The 14 LiveKit-only names skew regional — LINE Clova, RTZR, Gnani, Vakyam, Spitch, Palabra, Uplift AI. Take neither on trust: open both listings and search for the vendors you intend to use. They go stale fast — 76 LiveKit directories on 10 September, 77 on 12 September, which is why every figure here is dated.
The licence asymmetry almost nobody surfaces
Both are permissively licensed, and there the symmetry stops. Pipecat is BSD-2-Clause throughout, and its Smart Turn v3.2 end-of-turn model ships as a file in the same repository — src/pipecat/audio/turn/smart_turn/data/smart-turn-v3.2-cpu.onnx — under that licence. The smart-turn project puts it plainly: “This is a truly open model (BSD 2-clause license).”
LiveKit Agents is Apache-2.0, but its turn-detection models are not. The repository carries a second file, MODEL_LICENSE, which states, in its introduction: “you may use these LiveKit models freely but can only use them together with the LiveKit Agents framework. You cannot use the LiveKit models on a standalone basis or with any other frameworks.”
This is a documented boundary, not a fault: LiveKit publishes it in its own README and repository root. But it is the clause that turns a reversible choice into a partly irreversible one, and the one an open-source review finds three months after you shipped.
Turn detection: the same job, two different bets
Turn detection is where callers decide whether they are talking to a machine. LiveKit’s current detector is built into livekit-agents as livekit.agents.inference.TurnDetector, and the older livekit-plugins-turn-detector package is marked deprecated in its own README. It runs a hosted v1 model through LiveKit’s inference gateway with a local v1-mini fallback; its docstring is precise about the trade, because setting local_fallback=False “keeps it cloud-only, so the mini weights (~108MB, resident for the process’ life) are never loaded and turns commit on the endpointing delay instead”. The mini model ships per-language thresholds for 14 languages.
Pipecat’s Smart Turn v3.2 runs locally from the ONNX file in the package; the project states support for 23 languages, inference “in as little as 10ms on some CPUs, and under 100ms on most cloud instances”, and an 8MB quantised CPU build alongside a 32MB GPU build. Pipecat also treats turn strategy as swappable: src/pipecat/turns/ holds separate strategies for turn start, turn stop and user muting, including wake-phrase and minimum-word variants.
Neither is better. One bets on a managed model with a local safety net, the other on weights you hold — the licence bet again, in your latency budget.
Observability: LiveKit Agents 1.8.0 changed the shape of your traces
Both emit OpenTelemetry; Pipecat carries tracing utilities at src/pipecat/utils/tracing/, including a turn_trace_observer scoping spans to a conversational turn. LiveKit’s 1.8.0 release on 7 September 2026 is the version boundary to get right. Its notes state that spans, metrics and logs “now follow the OTel GenAI semantic conventions, so Langfuse, Datadog Agent Observability, and other GenAI-aware backends read LiveKit traces natively”, and that PII filtering moved in-process. The same notes list the breaking half: conversation content is no longer emitted as span events, so gen_ai.system.message, gen_ai.user.message, gen_ai.assistant.message, gen_ai.tool.message and gen_ai.choice are gone, replaced by attributes — and “dashboards and processors reading the events see nothing”. Realtime inference also moved off the agent_turn span onto a new realtime_inference child span.
On 1.7.x with dashboards built on the old events, budget the migration; start today on 1.8.1, released 10 September 2026, and you get the conventions for free. What a useful trace has to contain, whichever framework you pick, is in our breakdown of AI agent observability: traces, logs and outcomes.
“What happens to my work if I switch?” Object by object
The cost of a wrong choice is the migration. Here is what transfers, checked against both codebases on 12 September 2026.
| What you built | Transfers? | Why |
|---|---|---|
| System prompt and conversation design | Yes | Plain text and structure. Usually the most expensive artefact you own, and it is portable. |
| Provider choice and API keys | Mostly | 37 vendor names appear in both speech-path sets. Check your specific three first. |
| Tool and function definitions | Rewrite, logic intact | LiveKit uses a function_tool decorator on an agent class; Pipecat uses register_function() on the LLM service. Same bodies, different registration. |
| Turn-detection tuning | No | Different models, different threshold semantics, and the LiveKit model licence forbids carrying its weights elsewhere. |
| Telephony configuration | No | SIP trunk plus dispatch rule against a LiveKit server, versus a carrier media-stream websocket plus a serializer. |
| Client applications | Depends | Keep the LiveKit transport under Pipecat and your LiveKit client SDKs keep working. Move to a carrier websocket and they do not. |
| Observability dashboards | Partial | Both speak OpenTelemetry, so the pipes survive; span and attribute names do not match. |
| Evaluation and test suites | Rewrite | LiveKit ships a built-in test framework and judges; Pipecat has src/pipecat/evals/ and a CLI eval command. The cases survive, the harness does not. |
Read it as a ranking: prompts and provider choices are cheap to move, transport and turn detection are not.
Who each option is wrong for
LiveKit Agents is the wrong choice if your media path is already a carrier websocket and a WebRTC media server buys you nothing; if your open-source review requires every weight you run to be under a licence you can fork; or if you want local in-process inference classes rather than a client pointed at a server you host.
Pipecat is the wrong choice if your server-side team will not own Python; if you need a SIP bridge off the shelf rather than assembled per carrier; or if you already operate LiveKit rooms and a second orchestration layer is pure overhead.
Both are the wrong choice if nobody will own a long-running audio service in production. Neither framework answers your phone, holds your consent state, washes your do-not-call list or wakes someone at 2am when a speech vendor returns 5xx mid-call. We priced that surface in engineer-days in how long it takes to build a voice AI agent in-house, and the telephony half in how to connect an AI agent to your SIP trunk. Apply your own loaded cost to those totals before you pick a framework, not after.
Zian AI sits on the other side of that boundary: a commercial platform in partnership-application beta, with outbound appointment setting, 24/7 support in 30+ languages, phone, SMS, email and WhatsApp outreach, CRM integrations for HubSpot, Salesforce, HighLevel and Zapier, and private model deployment on customer infrastructure. That is a different purchase from a framework; the comparison is in our build versus buy analysis for AI agents, not on this page, which is about two frameworks that are both good.
Frequently asked questions
Can I run Pipecat on the LiveKit transport?
Yes. Pipecat ships a LiveKit transport at src/pipecat/transports/livekit/ and a matching runner at src/pipecat/runner/livekit.py, and its README lists LiveKit (WebRTC) in the transport table. Pipecat 1.10.0, released 12 September 2026, added a LiveKitParams.audio_out_queue_size_ms setting for the outgoing LiveKit audio buffer.
Which one has more model integrations?
Counted on 12 September 2026 with one rule applied to both repositories, Pipecat has 55 speech-path service directories and LiveKit Agents has 51. One of those 55 is grok, a deprecated alias that re-exports the xai service, so 54 are distinct. The raw directory counts run the other way, 77 to 62, because LiveKit packages avatar vendors, VAD and utilities in the same folder. Treat both numbers as packaging, not capability.
Are both frameworks free to use commercially?
Both are permissive. Pipecat is BSD-2-Clause and LiveKit Agents is Apache-2.0. The exception is the LiveKit turn-detection models, which ship under a separate LiveKit Model License. That licence states the models cannot be used on a standalone basis or with any other frameworks. The framework code itself is unaffected.
Do I need LiveKit Cloud to use LiveKit Agents?
No. The media server at livekit/livekit and the SIP bridge at livekit/sip are both Apache-2.0 and self-hostable. One thing to know: the built-in turn detector resolves to the hosted v1 model when it detects a hosted or development environment and to the local v1-mini model otherwise, so a self-hosted deployment gets the local model by default.
Which one should I use if my team only writes TypeScript?
LiveKit Agents, through agents-js, is the only first-party non-Python server option of the two. Note the packaging gap: on 12 September 2026 the TypeScript repository carried 38 plugin directories against the 77 in the Python repository. Capability parity has improved, and LLM, STT and TTS fallback adapters are all now present in agents-js, but check your specific providers in the plugins directory before committing.
Working out which side of the line you are on
If the framework question still feels like the wrong question, it probably is. Apply For Partnership at https://zian.ai/#waitlist and we will talk about the outcome you want, not the transport you would have to run.