LiveKit vs Vapi (2026): Pricing, Latency, Lock-In, and a Fair Way to Test Both

Most LiveKit vs Vapi comparisons stop at "build versus buy." That framing is correct and almost useless, because it does not tell you what you give up, what it costs at your volume, or how to prove which one sounds better to your callers.

This guide does the parts the vendor pages leave out. It maps exactly which layer each product owns, prices every billable line item from the October 2026 pricing pages, runs the total cost of ownership at three volumes with the assumptions labeled, counts the network hops in a phone turn, and shows where turn-detection behavior really comes from. It also covers something most people miss: Vapi already uses LiveKit and Daily components inside its own stack.

LiveKit vs Vapi at a glance

All prices in this post come from LiveKit's pricing page and Vapi's pricing page as of October 2, 2026. Both change often, so re-check before you sign anything.

They are different layers: what each one owns

The cleanest way to compare them is to list every job a production voice agent needs and write down who owns it. If you want the generic version of this stack first, see our voice agent stack guide.

The key row is orchestration. Vapi's own data flow documentation states that its orchestration layer (endpointing, interruption detection, background noise and voice filtering, backchanneling, emotion detection, filler injection) is "not customizable" and runs only on Vapi infrastructure (Vapi data flow). Everything else in a Vapi call can be swapped for your own provider or server. That one closed layer is both the product and the lock-in.

On LiveKit, the orchestration loop is a Python or Node class in your repo. LiveKit renamed workers to "agent servers," and endpointing and interruption settings now live under `turn_handling` on `AgentSession` (turn handling options). You can read the code, fork it, and step through it in a debugger.

Vapi already contains LiveKit and Daily parts

This surprises most buyers, and it is fully sourced:

• Vapi's data flow page lists its WebRTC transport as "Web and mobile apps via LiveKit/Daily" (Vapi data flow).
• The Vapi pricing page lists "Daily WebRTC" as a free transport, next to Vapi WebSockets and Vapi SIP (Vapi pricing).
• The published `@vapi-ai/web` package (version 2.7.1) declares `@daily-co/daily-js` as a runtime dependency (npm).
• Vapi's speech configuration docs say that when smart endpointing is off and the transcriber has no end-of-turn detection, "the system defaults to LiveKit if the language is set to English" (Vapi voice pipeline configuration).

So for an English web call, a Vapi agent may be moving audio over Daily's WebRTC stack and deciding turn ends with a LiveKit model. The phrase "Vapi vs LiveKit" is partly "LiveKit components with Vapi's orchestration on top versus LiveKit components with your orchestration on top." The useful question is not which brand is faster. It is which configuration of shared parts you get by default, and how much of it you can change.

Pricing in October 2026: every line item that bills

Vapi line items

Concurrency is measured at the subscription level, and when every slot is busy "you cannot start an outbound call or accept an inbound call until a slot becomes available" (Vapi call concurrency). The `POST /call` response includes a `subscriptionLimits` object with `concurrencyBlocked` and `remainingConcurrentCalls`. Alert on it. A blocked inbound call is a missed customer, and it will not show up in your latency charts.

LiveKit Cloud line items

Models are separate. You either bring provider keys through plugins, or pay LiveKit Inference's per-minute prices. For example, the pricing page lists Deepgram Nova-3 monolingual at $0.0048/min and Flux at $0.0065/min on Build/Ship, with lower Scale rates.

Bandwidth is a rounding error for audio. People searching "livekit pricing" often worry about data transfer. Do the math: an Opus voice stream at an assumed 32 kbps is 32,000 / 8 × 60 = 240 KB per minute. One million minutes is about 240 GB, well inside Scale's 3 TB allotment. Bandwidth only matters once you add video or avatars.

Worked TCO at 10k, 100k, and 1M minutes per month

The fair way to compare platforms is to hold the model layer constant. Both products let you bring your own STT, LLM, and TTS keys at the same provider prices, so those costs cancel. What differs is the platform layer and the engineering it demands.

Assumptions (illustrative, change them for your business):

• Phone traffic, BYO SIP trunk on both. Carrier cost $0.005/min on both.
• Model layer (STT + LLM + TTS on your own keys) $0.04/min on both.
• Traffic falls in 10 business hours on 22 days, so 13,200 busy minutes per month, with a peak-to-average ratio of 2. Peak concurrency = minutes ÷ 13,200 × 2.
• LiveKit records every session in Cloud and emits an assumed 30 observability events per call minute.
• Vapi uses the cheapest package that covers peak concurrency, plus $10 lines.
• Engineering at a loaded $16,000 per FTE-month. Vapi needs 0.25, 0.5, and 1.0 FTE at the three volumes; LiveKit Cloud needs 0.5, 1.0, and 1.5 FTE.

Platform layer only

If you need Vapi's 99% uptime SLA, Pro adds 10% of hosting: $5,000 at 1M minutes, which takes Vapi's platform layer to about $56,220.

All-in, including engineering

The break-even formula

The platform gap is roughly $0.033 to $0.037 per minute at most volumes. The extra engineering LiveKit needs is a fixed monthly cost. So:

break-even minutes per month = (extra LiveKit FTE × loaded FTE cost) / platform gap per minute

extra FTE = 0.5, FTE = $16,000, gap = $0.0347/min
break-even = 8,000 / 0.0347 ≈ 230,000 minutes per month

At 230k minutes, LiveKit's platform layer is about $3,800 and Vapi's is about $11,780, a gap of roughly $8,000, which pays for exactly the half-engineer we assumed. Each additional half-engineer that LiveKit costs you pushes the break-even out by another 230k minutes. If your team already runs realtime infrastructure, the extra FTE may be close to zero and LiveKit wins much earlier.

Three line items deserve a second look:

1. LiveKit's $500 Scale plan pays for itself at about 29,000 minutes. Ship costs $50 plus about $0.019 per minute after its allotments (agent, SIP, and recordings). That crosses $500 near 29k minutes. Many teams sit on Ship too long because it looks cheaper.

2. Recordings are about a quarter of LiveKit's bill at 1M minutes. $4,750 of $18,350 is Cloud session recording. If you capture audio with Egress instead, track egress is $0.001/min, but you also lose the Cloud insights playback for those sessions. Decide deliberately.

3. Vapi concurrency is cheap, but you must buy it ahead of peaks. 142 extra lines cost $1,420 a month, small next to $50,000 of hosting. The real cost is the calls you drop if a campaign spikes past your lines.

Self-hosting LiveKit removes agent session minutes, the SIP fee, and Cloud recordings, which is roughly $0.018/min at 1M minutes, or about $18,000 a month. That pays for about one SRE at our assumed loaded cost before you buy any compute. It also changes your turn detector, which we cover below. Our managed vs self-hosted orchestration guide and voice agent TCO model go deeper on the compute side.

Where latency is added: counting the hops

People compare "Vapi latency" to "LiveKit latency" as if the platform were one number. It is not. A cascaded phone turn crosses the same kinds of network legs on both. What differs is who picks where those legs go, and which fixed delays are on by default.

Human conversation sets the target. Stivers and colleagues measured question-answer gaps in 10 languages and found a mean of 208 ms, with language means within about 250 ms of that (Stivers et al., PNAS 2009). Telephony engineering adds its own ceiling: ITU-T G.114 recommends keeping one-way mouth-to-ear delay under 150 ms for most applications (ITU-T G.114). A voice agent will not hit 208 ms, but every avoidable 100 ms moves it further from natural timing.

The hops in one phone turn

The hop counts are nearly identical. The difference is geography, and you can write it as a formula:

geography tax per turn ≈ RTT(caller edge, orchestrator)
                       + RTT(orchestrator, LLM)
                       + RTT(orchestrator, TTS)
                       + 0.5 × RTT(orchestrator, STT)
                       + n_tools × RTT(orchestrator, your tool API)

Worked example with assumed public-internet round trips: a caller in India reaching a US-hosted orchestrator pays an assumed 230 ms RTT on the first term alone, every turn. Vapi documents two regions, US and EU. LiveKit lets you run the agent in-region, and LiveKit Inference runs a co-located Deepgram deployment in Mumbai for supported models (LiveKit Deepgram docs). For US callers with US providers, the geography tax is small on both.

Tool calls are the other lever. On Vapi, each tool is an HTTP round trip from Vapi to your server. Vapi's own guidance for the `assistant-request` webhook is to host it close to `us-west-2`, and that webhook must answer within 7.5 seconds end to end, a limit that is "not configurable" (Vapi server events). If your backend lives in `us-east-1`, every tool call crosses the country twice. On LiveKit, a tool that reads from a database in the same VPC costs a few milliseconds.

The fixed delays that are on by default

Vapi's docs include their own illustrative timeline: endpointing 0.6 s + LLM 0.8 s + TTS 0.5 s + `waitSeconds` 0.4 s = 2.3 s to first audio (Vapi voice pipeline configuration). Those are Vapi's example numbers, not measurements. They still make the point: 400 ms of that budget is a pad you can lower. Setting `waitSeconds` to 0.1 is often the single cheapest latency change on a Vapi agent, but test it, because the pad also hides early endpoints.

On LiveKit, the trap runs the other way. In STT turn-detection mode, `min_delay` "is applied after the STT end-of-speech signal, and therefore in addition to the STT provider's endpointing delay" (LiveKit turn handling options). If you use Deepgram Flux end-of-turn and leave `min_delay` at its 0.5 s default, you stack half a second on top of Flux's own decision. For more on how these timers interact, see our endpointing guide and time to first audio.

Turn detection: same brand name, different model

Since Vapi offers a `livekit` smart endpointing provider, you might assume a Vapi agent and a LiveKit agent detect turn ends the same way. The docs suggest otherwise.

Vapi's speech configuration page lists `livekit` under text-based providers, tuned with a `waitFunction` that maps a probability to milliseconds (default `200 + 8000 * x`) (Vapi speech configuration). LiveKit's current default, `TurnDetector` v1, is an audio model that "encodes user audio directly," combining semantics with intonation, pitch, and rhythm. LiveKit has deprecated its text turn detector and plans to remove it in Agents SDK 2.0 (LiveKit turn detector). Vapi's docs do not say which LiveKit model runs behind its provider, so treat it as unverified and test it.

Why the difference matters: LiveKit publishes accuracy for its text detector. In English, the true positive rate (correctly saying the user is done) is 99.3%, but the true negative rate (correctly saying the user will keep talking) is 87.0%. Roughly 13 of every 100 mid-sentence pauses get judged as finished turns by that model. For a caller reading a 16-digit account number with pauses, those errors are the "agent cut me off" complaints. LiveKit's own side-by-side demo shows the text model committing a flight-booking turn three times (2.76 s, 4.88 s, 6.40 s) while the audio model waits until 6.41 s.

The research explains why audio wins. Ekstedt and Skantze's Voice Activity Projection work trains a model to predict upcoming voice activity for both speakers from audio alone, and shows it beats prior approaches on zero-shot turn-shift and backchannel prediction (Ekstedt and Skantze, Interspeech 2022). Prosody carries the "I'm not done" signal that a transcript throws away. Arora et al.'s Talking Turns benchmark used a turn-taking judge model trained on human conversation and found deployed spoken dialogue systems "sometimes do not understand when to speak up, can interrupt too aggressively and rarely backchannel" (Arora et al., ICLR 2025). Full-Duplex-Bench breaks turn-taking into pause handling, backchanneling, smooth turn-taking, and user interruption, scored separately (Lin et al., 2025). The practical lesson from all three: score turn behaviors separately, because a system can be fast and still interrupt badly. Our turn-taking evaluation guide covers the metrics.

The self-hosting catch. LiveKit's full `v1` audio model is served on LiveKit Inference and is free for agents deployed to LiveKit Cloud. When you run the agent elsewhere with the `start` command, the default becomes `v1-mini`, a CPU model released under the LiveKit Model License rather than Apache 2.0. If `v1` times out mid-session, the session falls back to `v1-mini` and stays there. LiveKit also warns to use compute-optimized instances rather than burstable ones to avoid inference timeouts from CPU credit limits. Leaving LiveKit Cloud can quietly change your turn-taking quality, so re-test before you migrate.

What you can and cannot control

That last row is a production gotcha. Vapi API Request tools wait 20 seconds by default, and the dashboard "currently exposes tool messages but not `timeoutSeconds` or `backoffPlan`" (Vapi tool reliability). A slow backend can leave a caller on hold-style filler for 20 seconds unless you set it through the API.

Here is a Vapi assistant excerpt that removes the hidden pad and pins turn detection to Deepgram Flux. It uses only fields from Vapi's docs; treat it as illustrative and validate against the API reference.

{
  "transcriber": {
    "provider": "deepgram",
    "model": "flux-general-en",
    "language": "en",
    "eotThreshold": 0.7,
    "eotTimeoutMs": 5000
  },
  "startSpeakingPlan": {
    "waitSeconds": 0.1,
    "customEndpointingRules": [
      { "type": "assistant", "regex": "(account number|card number|phone number)", "timeoutSeconds": 3.0 }
    ]
  },
  "stopSpeakingPlan": {
    "numWords": 2,
    "voiceSeconds": 0.2,
    "backoffSeconds": 1.0,
    "acknowledgementPhrases": ["okay", "right", "uh-huh", "yeah", "mm-hmm"]
  },
  "monitorPlan": { "listenEnabled": true }
}

And the matching LiveKit session, simplified from the documented quickstart, with Flux as the turn detector and `min_delay` set low so it does not stack on top of Flux:

# Simplified, illustrative. Verify against current LiveKit Agents docs.
from livekit import agents
from livekit.agents import AgentServer, AgentSession, Agent, TurnHandlingOptions
from livekit.plugins import deepgram

server = AgentServer()

@server.rtc_session(agent_name="support-agent")
async def entrypoint(ctx: agents.JobContext):
    session = AgentSession(
        stt=deepgram.STTv2(model="flux-general-en", eot_threshold=0.7, eot_timeout_ms=5000),
        # llm=..., tts=...  (same providers and keys as the Vapi arm)
        turn_handling=TurnHandlingOptions(
            turn_detection="stt",                      # Flux decides the turn end
            endpointing={"mode": "fixed", "min_delay": 0.1, "max_delay": 3.0},
            interruption={"mode": "vad", "min_duration": 0.2},
            preemptive_generation={"enabled": False},  # match Vapi's documented flow
        ),
    )
    await session.start(room=ctx.room, agent=Agent(instructions="You are a support agent."))

if __name__ == "__main__":
    agents.cli.run_app(server)

Telephony: bring your own SIP trunk on both

Both platforms accept a BYO SIP trunk, so you can keep your carrier, numbers, and rates. The differences are in the details. Our SIP vs WebRTC guide explains the protocol layer.

Vapi. You create a credential with `"provider": "byo-sip-trunk"`, then attach a `byo-phone-number` to it (Vapi SIP trunking). Three things to know:

• Vapi warns against IP-based trunk authentication. Its servers are shared, so if your carrier has several customers using IP auth, "calls may be routed incorrectly." Use credentials unless your provider gives you a unique termination URI.
• US media IPs are dynamic; you allow UDP 40000 to 60000. The EU region uses a static media IP. Firewall teams need to know which region you are in.
• Keep the API host and SIP host in the same region (`api.eu.vapi.ai` with `sip.eu.vapi.ai`). Mixing them breaks setup.

Vapi charges nothing for SIP transport; your carrier bills you directly.

LiveKit. You configure inbound and outbound trunks plus dispatch rules, and pay $0.004 (Ship) or $0.003 (Scale) per third-party SIP minute after the allotment. From the codec negotiation reference:

• Default SIP codecs are PCMU, PCMA, and G.722. AMR-WB is opt-in. G.722 gives you 16 kHz wideband audio, which helps STT on carriers that support it.
• LiveKit answers an inbound INVITE without SDP (a "delayed offer") with `400 Bad Request` unless support enables delayed offers for your project. Some PBXs send delayed offers by default, which looks like a mystery failure on day one.
• Adding codecs makes the INVITE larger, and on UDP large packets can fragment and get lost. LiveKit lets you send only the codecs you list.

Both also sell their own numbers. LiveKit's US local numbers are $1 a month and $0.01 per inbound minute. Vapi includes 1 to 10 free numbers depending on package.

Observability and data ownership

If you plan to evaluate calls, you need the audio, the timestamps, and the per-turn timings. The two platforms give you very different raw material. Our what to log on every call guide has the full field list.

Vapi gives you clean artifacts after the call. Authenticated endpoints return a mono recording, a stereo recording with customer and assistant on separate channels, customer-only and assistant-only tracks, gzipped JSONL call logs, and a PCAP when enabled (Vapi call artifacts). The stereo and customer-only files are valuable: you can re-run STT on the caller channel alone to check transcription accuracy. Limits to plan around:

• Raw data retention is 14 days on Usage only, 30 on Core, and 180 on Pro. Export within that window or lose it.
• You can send recordings and call logs to your own S3, GCS, R2, Supabase, or Azure bucket. Vapi's system logs and usage metrics "are never uploaded to custom storage buckets."
• Live audio is available through `monitorPlan.listenEnabled`, which returns a `listenUrl` WebSocket for each call.
• Signed artifact URLs expire quickly; request a fresh one each time.

LiveKit gives you the pipeline itself. Each assistant message carries a `MetricsReport` with `e2e_latency`, `llm_node_ttft`, and `tts_node_ttfb`; each user message carries `transcription_delay` and `end_of_turn_delay` (LiveKit data hooks). `ctx.make_session_report()` builds a JSON report with history, events, and recording metadata, and it runs entirely in your process, so it works self-hosted too. One gotcha: LiveKit Cloud recordings are captured after background voice cancellation is applied (LiveKit recording docs). If you want to measure STT on what the caller sent, record with Egress. Cloud "export to cloud storage" is still listed as coming soon on the pricing page.

This snippet logs per-turn latency to your own pipeline, using the documented `conversation_item_added` event. It is illustrative.

from livekit.agents import ConversationItemAddedEvent
from livekit.agents.llm import ChatMessage

def attach_turn_logger(session, call_id: str, sink):
    @session.on("conversation_item_added")
    def _on_item(ev: ConversationItemAddedEvent):
        if not isinstance(ev.item, ChatMessage):
            return
        m = ev.item.metrics or {}
        sink.write({
            "call_id": call_id,
            "role": ev.item.role,
            "end_of_turn_delay": m.get("end_of_turn_delay"),
            "llm_node_ttft": m.get("llm_node_ttft"),
            "tts_node_ttfb": m.get("tts_node_ttfb"),
            "e2e_latency": m.get("e2e_latency"),
        })

Using the room name as `call_id` is the simplest way to join these rows to your evaluation results later, which answers a question we often get: how to correlate LiveKit room events with voice agent evaluation scores.

Lock-in and migration cost

Lock-in is not a yes-or-no property. It is the number of engineer-weeks it takes to leave. Our vendor lock-in guide and migration guide cover the general case. Here is the specific map.

The expensive part is never the config translation. It is re-tuning turn-taking, because the orchestration that produced your current behavior is closed, so you cannot copy it. Budget for a full regression run on both platforms in parallel. As an illustrative planning figure, a mid-complexity agent with five tools and one handoff is often two to four engineer-weeks to port and another two to re-tune. Your number depends on how much logic lives in webhooks.

LiveKit lock-in is lower but not zero. The Agents framework is Apache 2.0, and you can leave LiveKit Cloud for self-hosting. You still lose the hosted `v1` turn detector, Cloud insights, and LiveKit Inference billing on the way out.

Decision matrix by team type

For other matchups, see our Vapi vs Retell comparison and Pipecat Cloud vs LiveKit Cloud.

How to run a fair LiveKit vs Vapi head-to-head

Vendor demos are tuned. Your callers are not. This protocol isolates the platform from everything else. It builds on our bake-off guide.

1. Freeze the model layer. Use the same STT, LLM, TTS, voice, and prompt on both, with your own keys in the same provider regions. Mock every tool behind one HTTP server that returns fixed payloads after a fixed 150 ms delay, so backend variance cannot leak into the result.

2. Pin the carrier. Point both platforms at the same BYO SIP trunk and DIDs in the same area code. Call from the same origin. Otherwise you are benchmarking carriers.

3. Run two arms per platform. Arm A uses each platform's defaults, because that is what most teams ship. Arm B pins turn detection to Deepgram Flux on both, with Vapi `waitSeconds` at 0.1 and LiveKit `min_delay` at 0.1, so the same end-of-turn model decides on both and only the orchestration differs.

4. Build a scenario-by-condition matrix. Use at least 40 scripted scenarios from your real call mix (account lookups, digit strings, corrections, interruptions, silent pauses, transfers) crossed with 4 conditions: clean, café noise at 10 dB SNR, G.711 narrowband, and 2% packet loss. That gives 160 cells.

5. Define metrics before you run. Measure p50 and p95 first-audio latency (caller end of speech to first agent audio, measured from the recording, not the dashboard). Count premature cutoffs (agent starts while the caller is mid-utterance) and missed barge-ins (agent keeps talking more than 1 s after the caller starts). Score task success with a fixed rubric and tool-argument accuracy against expected JSON.

6. Size the sample correctly. To detect task success moving from 85% to 90% at 80% power and α = 0.05, you need about 686 calls per arm. Turn-level metrics need fewer calls: detecting premature cutoffs falling from 8% to 4% takes about 552 turns per arm. With 10 turns per call and an assumed intra-call correlation of 0.1, the design effect is 1 + (10 − 1) × 0.1 = 1.9, so about 1,050 turns, or roughly 105 calls.

7. Read variance, not averages. Bootstrap the p95 difference with 10,000 resamples clustered by call. Repeat the whole run on two different days and at two times of day, because shared provider endpoints have rush hours.

8. Set pass/fail gates up front. For example: p95 first audio under 1.5 s, premature cutoffs under 5% of turns, missed barge-ins under 3%, task success no worse than the incumbent minus 2 points. Pick the platform that passes on your scenarios at the lowest TCO from the model above.

Both vendors now ship testing tools: Vapi has evals, simulations, and scorecards, and LiveKit has Agent Simulations in beta. They are useful for development. For a platform decision, though, a vendor's own simulator is grading its own product. That is where an independent evaluator such as Evalgent fits: the same synthetic callers, audio conditions, and rubric run against both stacks, scored from the recordings. Platform-specific setup is in our Vapi testing guide and LiveKit testing guide.

Where independent evaluation fits

Three moments benefit from an outside view. Before you choose, a bake-off on your own scenarios replaces vendor claims with evidence. Before you migrate, a regression baseline on the old platform tells you whether the new one sounds worse before customers do. After launch, scoring production calls catches the drift that happens when a provider ships a new model under the same name.

Evalgent does this as an independent third party: it runs scripted and synthetic callers against agents on LiveKit, Vapi, or your own stack, and scores latency, turn-taking, task success, and policy adherence from the audio. It does not replace either platform's logging. It turns their raw material into a comparison you can defend in a procurement review.

Frequently asked questions

Is LiveKit or Vapi cheaper?

At list prices LiveKit Cloud's platform layer runs about $0.014 to $0.018 per minute, versus about $0.05 for Vapi, with models costing the same on both. LiveKit needs more engineering, though. With our labeled assumptions, Vapi is cheaper all-in below roughly 230k minutes a month and LiveKit is cheaper above it.

Does Vapi use LiveKit?

Partly, according to Vapi's own docs. Its data flow page says WebRTC runs "via LiveKit/Daily," and its endpointing docs list a `livekit` smart endpointing provider that is the English default when the transcriber has no end-of-turn detection. Vapi's web SDK also depends on Daily's `daily-js` package.

Which has lower latency, LiveKit or Vapi?

Neither is faster by default for every caller. Hop counts are similar. Vapi adds a 0.4 s `waitSeconds` pad by default, and LiveKit starts the LLM early through preemptive generation. Geography matters most: Vapi runs in US or EU, while LiveKit can run near your callers and tools.

How much does LiveKit Cloud cost in 2026?

Build is free with 1,000 agent minutes. Ship is $50 a month with 5,000 minutes, and Scale is $500 with 50,000. After that, agent sessions cost $0.01 per minute, third-party SIP $0.003 to $0.004, and recordings $0.005. Models are billed separately, through your own keys or LiveKit Inference.

Can I bring my own SIP trunk to Vapi and LiveKit?

Yes. Vapi uses a `byo-sip-trunk` credential and does not charge for SIP transport, but it warns against IP-based authentication on its shared servers. LiveKit supports inbound and outbound trunks, billing $0.003 to $0.004 per minute after allotments, with PCMU, PCMA, and G.722 offered by default.

Can I get raw call audio from Vapi?

You get mono, stereo, customer-only, and assistant-only recordings after the call, plus a live `listenUrl` WebSocket if monitoring is enabled. Retention is 14 to 180 days depending on package unless you configure your own bucket. You cannot insert processing into Vapi's media path.

How hard is it to migrate from Vapi to LiveKit?

Config translation is quick; re-tuning is not. Prompts and speaking plans map directly. Tools move from webhooks into agent code. The real cost is matching turn-taking behavior, because Vapi's orchestration is closed. Run both platforms in parallel on the same test suite before you cut over.

Should a small team start on Vapi and switch later?

Often yes, if you design for the exit. Keep business logic behind your own API rather than in Vapi-specific features, store recordings in your own bucket, and keep a regression suite. Then switching at 200k-plus minutes is a project, not a rewrite.

The bottom line

LiveKit vs Vapi is a choice between owning the orchestration loop and renting it, and at October 2026 prices the rent costs about $0.035 per minute, which equals one half-engineer at roughly 230k minutes a month. Price both with your own volume, then run the same scenarios through both before you commit, because turn-taking defaults, not logos, decide what your callers hear.