I wanted to know how track publishing and unpublishing affect billing?

Thanks for reaching out, Chirag. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

I have a room with Agent and the user from frontend When the user mutes I want to pause the Agent/Remove it from room Is there anyway to pause the agent? If I remove the agent participant from the room, it disconnects and the agent process starts shutting down. So is there anyway I can pause this agent or have a similar behaviourso that when the user unmutes I can resume it?

Thanks — I’m responding about pausing the agent when the user mutes. You cannot "pause" a participant in LiveKit; removing the agent disconnects it and will shut down the agent process. Instead, keep the agent connected and disable its audio I/O so it effectively pauses without disconnecting. Recommended approach: • When the user mutes: ◦ Disable the agent’s input and output: ▪︎ Python:

session.input.set_audio_enabled(False)

and

session.output.set_audio_enabled(False)

▪︎ Node:

session.input.setAudioEnabled(false)

and

session.output.setAudioEnabled(false)

◦ If the agent is speaking, call

session.interrupt()

to stop speech immediately. • When the user unmutes: ◦ Re-enable audio I/O (

True

/

true

) to resume listening and speaking. This keeps the agent session alive, avoids process shutdown, and allows instant resume. Would you like a short code snippet for your environment (Node or Python) or help wiring this to your frontend mute event? Sources: Text and transcriptions | LiveKit docs

will this also reduce billing?

Short answer: Yes — disabling the agent’s audio input/output will reduce bandwidth charges for that agent, but connection minutes will still accrue while it remains connected. Details: • Bandwidth: When you disable the agent’s audio I/O, the agent stops sending upstream audio and stops receiving downstream audio, so the bandwidth for that media stops and associated bandwidth charges stop. • Connection time: The agent remains connected to the room, so connection minutes (participant time) continue to accrue. • No per-track fee: There’s no separate per-track flat charge; costs come from bandwidth and connection time. If you want to lower both bandwidth and connection-minute costs, you must disconnect the agent (which triggers shutdown). Do you want an estimate of bandwidth savings based on your typical audio bitrate and session length?

is there anyway to check the bandwidth used and connection time? in the sdk or any api

Thanks — I’m responding about how to check bandwidth used and connection time. • Connection time ◦ SDK: Track connect/disconnect events and record timestamps to compute session duration (e.g., Room connected → start time; Room disconnected → end time). ◦ Billing: Agent/participant connection minutes are billed from join to disconnect on the server, so SDK timestamps are an accurate client-side approximation but server-side telemetry is billing-grade. • Bandwidth usage ◦ SDK: Use WebRTC stats exposed by the LiveKit SDK (e.g.,

getStats()

/

localParticipant.getStats()

in JS) to read

inbound-rtp

/

outbound-rtp

reports and calculate bitrate over time (bytesSent/bytesReceived → bits/sec). ◦ Example (JS): poll

room.localParticipant.getStats()

and compute delta of bytes over time to estimate bps per track. ◦ Note: SDK stats let you estimate per-track bandwidth but are not the official billing meter. • Server / Console ◦ For billing-accurate metrics (total downstream bandwidth, connection minutes), use LiveKit Cloud analytics / Console where total usage is recorded and exported. Would you like a short example snippet for your environment (Node or browser JS or Python) to start polling stats and computing bandwidth and connection time? Sources: Understanding and Estimating Pricing for Video Conference and Livestream Us... | Announcing LiveKit Cloud | client-sdk-js | livekit/livekit_composite | DeepWiki | Say hello to improved Cloud analytics | LiveKit Pricing

in the python sdk specifically

Thanks — I’ll show how to get connection time and estimate bandwidth in the LiveKit Python SDK. Connection time (approximate) 1. Record timestamps on join and leave events. 2. Example (async usage):

import time
from livekit import Room, RoomEvent

start_time = None

async def on_connected(_):
    global start_time
    start_time = time.time()

async def on_disconnected(_):
    duration_s = time.time() - start_time
    print(f"Connection duration: {duration_s:.1f} seconds")

room = Room()
room.on(RoomEvent.CONNECTED, on_connected)
room.on(RoomEvent.DISCONNECTED, on_disconnected)

# join the room as usual...

This mirrors billed connection minutes (server measures join → disconnect), so client timestamps are an accurate approximation. Bandwidth estimation (per-track) 1. Poll track stats exposed by the SDK (these wrap WebRTC getStats). Compute byte deltas over time to get bps. 2. Example pattern:

import asyncio
import time

async def sample_bandwidth(local_participant, interval=1.0):
    prev = {}
    while True:
        stats = await local_participant.get_stats()  # list of reports
        now = time.time()
        for r in stats:
            # look for outbound-rtp / inbound-rtp reports
            if r.type in ("outbound-rtp", "inbound-rtp"):
                key = (r.type, r.ssrc)
                bytes_val = getattr(r, "bytesSent", None) or getattr(r, "bytesReceived", 0)
                if key in prev:
                    prev_bytes, prev_time = prev[key]
                    delta_b = bytes_val - prev_bytes
                    delta_t = now - prev_time
                    bps = (delta_b * 8) / delta_t if delta_t > 0 else 0
                    direction = "sent" if r.type == "outbound-rtp" else "recv"
                    print(f"{direction} track {r.kind} ssrc={r.ssrc}: {bps:.0f} bps")
                prev[key] = (bytes_val, now)
        await asyncio.sleep(interval)

Notes and tips • Use

outbound-rtp

reports for local published tracks and

inbound-rtp

for received tracks. • Sum bps across tracks/subscribers to estimate downstream usage; upstream is local outbound. • SDK stats are estimates (WebRTC-derived). Billing-grade totals (downstream bytes, connection minutes) are recorded server-side and available in LiveKit Cloud Console/analytics. If you want, tell me whether you need: • a complete runnable example (join flow + stats sampling), or • code for agent sessions specifically (how to sample when agent is connected).

give some example about the billing parameters with sample figures

Thanks — I’ll provide sample billing calculations using the LiveKit rates and show how disabling audio affects costs. Assumptions / rates used • Agent session: $0.01 per minute. • Downstream bandwidth: $0.12 per GB. • Upstream bandwidth: free. • Audio bitrate examples: 32 kbps (low), 64 kbps (medium), 128 kbps (high). • Round minutes and GB for clarity. Examples 1) 1 agent, 60 minutes, audio 32 kbps (typical voice) • Agent session: 60 min * $0.01 = $0.60 • Bandwidth (downstream): 32 kbps = 32,000 bits/sec = 4,000 bytes/sec ◦ Data over 60 min = 4,000 B/s * 60 * 60 = 864,000,000 B ≈ 0.804 GB (note: this uses 1 GB = 10^9 B) ◦ Cost = 0.804 GB * $0.12 = $0.0965 • Total ≈ $0.6965 → ~$0.70 2) 1 agent, 60 minutes, audio 64 kbps • Agent session: $0.60 • Bandwidth: doubles → ≈1.608 GB → cost ≈ $0.193 • Total ≈ $0.793 → ~$0.79 3) 1 agent, 60 minutes, audio 128 kbps • Agent session: $0.60 • Bandwidth: ≈3.216 GB → cost ≈ $0.386 • Total ≈ $0.986 → ~$0.99 4) Short session: 10 minutes, audio 32 kbps • Agent session: 10 * $0.01 = $0.10 • Bandwidth: 0.134 GB → cost ≈ $0.016 • Total ≈ $0.116 → ~$0.12 Effect of disabling audio I/O (pause-like behavior) • Disabling audio stops upstream (free) and downstream media for that agent, so downstream bandwidth costs stop while disabled. • Connection minutes continue to accrue while agent remains connected. • Example: If you disable audio for 50 of 60 minutes in Example 1: ◦ Agent session: still 60 min = $0.60 ◦ Bandwidth billed only for 10 min: 0.804 GB * (10/60) ≈ 0.134 GB → $0.016 ◦ Total ≈ $0.616 → saved ≈ $0.08 vs leaving audio on. Quick formulas you can apply • Agent cost = minutes_connected * $0.01 • Bandwidth GB = (bitrate_kbps / 8) * seconds / 1e9 ◦ seconds = minutes * 60 • Bandwidth cost = bandwidth_GB * $0.12 • Total = Agent cost + Bandwidth cost Would you like these examples recalculated using 1 GiB = 1024^3 bytes, a different audio bitrate, or to include multiple subscribers’ downstream impact? Sources: LiveKit Pricing | Understanding and Estimating Pricing for Video Conference and Livestream Us... | Deploy and scale agents on LiveKit Cloud | Towards a future-aligned pricing model | Job lifecycle | LiveKit docs

4) Short session: 10 minutes, audio 32 kbps • Agent session: 10 * $0.01 = $0.10 • Bandwidth: 0.134 GB → cost ≈ $0.016 • Total ≈ $0.116 → ~$0.12 Explain how is 10 minutes derived? I want to understand the Agent Session pricing in detail

Thanks — I’ll explain how the 10-minute figure was chosen and exactly how Agent Session pricing works. • Why "10 minutes" in the example: it was an arbitrary short-session sample used to illustrate per-minute billing. It represents a session that lasted from join to disconnect for exactly 10 minutes (600 seconds). • How Agent Session pricing is measured: ◦ Billing counts the time an agent participant is connected to a room, from the moment the agent successfully joins until it disconnects. ◦ Time is measured in minutes. Charges apply per minute connected at $0.01 per minute. ◦ Partial minutes are rounded according to the billing system’s minute granularity (the example used whole minutes for simplicity). • Example math for 10 minutes: ◦ Minutes connected = 10 ◦ Agent session cost = 10 * $0.01 = $0.10 • Important notes: ◦ Muting/unpublishing tracks does not stop agent session billing — the agent must disconnect to stop session-minute charges. ◦ Disabling audio I/O reduces bandwidth costs but not connection-minute charges. ◦ For billing reconciliation use the LiveKit Cloud Console telemetry (server-side join/disconnect timestamps) as the authoritative source of minutes billed. Would you like me to: • Recompute examples with different session lengths, or • Show how to record join/disconnect timestamps in your Python agent to verify billed minutes?

so this includes only agent? and not the standard user? or sum of duration of all the users in a room

Good question — I’ll clarify. • Agent session minutes apply only to agent participants. Each agent is billed for the time that agent is connected to a room (join → disconnect) at $0.01/minute. • Standard (human) users are billed separately as WebRTC connection minutes. Each standard participant’s connection time is counted individually and charged under the WebRTC/participant metric. • They are not combined: agent minutes are not the sum of all users’ minutes. Example: ◦ One agent + three users in a room for 10 minutes: ▪︎ Agent session minutes = 10 (agent) ▪︎ WebRTC minutes = 30 (3 users × 10 minutes) ▪︎ Billing treats those independently. If you want, I can: • Run sample totals for your expected concurrent users and agent count, or • Show how to pull join/disconnect timestamps in Python so you can reconcile billed minutes. Which would you prefer? Sources: Deploy and scale agents on LiveKit Cloud | Understanding and Estimating Pricing for Video Conference and Livestream Us... | LiveKit Pricing | Agents and handoffs | LiveKit docs | Agents (Python) | livekit/livekit_composite | DeepWiki

WebRTC/participant metric. And this comes under agent session or bandwidth?

Good question — I’ll clarify. • The WebRTC/participant metric is a connection-time charge for standard (human) participants. It is billed based on each participant’s time connected to a room (join → disconnect). • It is separate from: ◦ Agent session minutes (which apply only to agent participants at $0.01/min). ◦ Bandwidth charges (which bill downstream data transfer in GB). • In short: WebRTC/participant = connection minutes for regular users (not part of agent session or bandwidth line items). Bandwidth is billed independently based on bytes egressed. Would you like an example bill breakdown using your expected counts and durations?

yes

Thanks — I’ll provide a clear example bill breakdown including agent session minutes, WebRTC/participant minutes, and bandwidth charges for typical scenarios. I’ll use the previously stated rates: • Agent session: $0.01 per minute (agent participants only) • WebRTC/participant: $0.01 per minute (example rate for standard participant minutes) • Downstream bandwidth: $0.12 per GB • Upstream bandwidth: free If you want different rates, tell me and I’ll recalc. Below are three scenarios with step-by-step math. Scenario A — Single agent + 1 user (30 minutes), audio 32 kbps • Agent minutes: 1 agent × 30 min = 30 min → Agent cost = 30 × $0.01 = $0.30 • WebRTC minutes: 1 user × 30 min = 30 min → WebRTC cost = 30 × $0.01 = $0.30 • Bandwidth (downstream): ◦ Bitrate = 32 kbps = 32,000 bits/s = 4,000 B/s ◦ Data per minute = 4,000 B/s × 60 = 240,000 B/min ◦ Data for 30 min = 240,000 × 30 = 7,200,000 B ≈ 0.0072 GB (1 GB = 10^9 B) ◦ Bandwidth cost = 0.0072 × $0.12 = $0.00086 • Total ≈ $0.30 + $0.30 + $0.00086 = $0.60086 → ~$0.60 Scenario B — 1 agent + 3 users (60 minutes), audio 64 kbps • Agent minutes: 1 × 60 = 60 min → Agent cost = 60 × $0.01 = $0.60 • WebRTC minutes: 3 users × 60 = 180 min → WebRTC cost = 180 × $0.01 = $1.80 • Bandwidth (downstream): ◦ Bitrate 64 kbps = 8,000 B/s ◦ Data per minute = 8,000 × 60 = 480,000 B ◦ Data per participant for 60 min = 480,000 × 60 = 28,800,000 B ≈ 0.0288 GB ◦ Downstream egress from server includes sending to each subscriber; with 3 users receiving, total downstream = 0.0288 GB × 3 = 0.0864 GB ◦ Bandwidth cost = 0.0864 × $0.12 = $0.01037 • Total ≈ $0.60 + $1.80 + $0.01037 = $2.41037 → ~$2.41 Scenario C — 2 agents (each connected), 5 users, session 120 minutes, audio 32 kbps • Agent minutes: 2 agents × 120 min = 240 min → Agent cost = 240 × $0.01 = $2.40 • WebRTC minutes: 5 users × 120 min = 600 min → WebRTC cost = 600 × $0.01 = $6.00 • Bandwidth (downstream): ◦ Bitrate 32 kbps = 4,000 B/s ◦ Data per minute = 4,000 × 60 = 240,000 B ◦ Data per participant for 120 min = 240,000 × 120 = 28,800,000 B ≈ 0.0288 GB ◦ Assuming each user receives audio from both agents (2 streams), per-user downstream = 0.0288 × 2 = 0.0576 GB ◦ Total downstream across 5 users = 0.0576 × 5 = 0.288 GB ◦ Bandwidth cost = 0.288 × $0.12 = $0.03456 • Total ≈ $2.40 + $6.00 + $0.03456 = $8.43456 → ~$8.43 Notes and assumptions • WebRTC/participant per-minute rate used here is $0.01 for illustration; replace with your actual rate if different. • Bandwidth calculation assumes 1 GB = 10^9 bytes. If you prefer GiB (1024^3), values change slightly. • Upstream bandwidth (participant → LiveKit) is free and not billed. • Bandwidth is counted per downstream stream (server -> subscriber). When multiple subscribers receive the same track, egress multiplies. • Agent minutes are counted per agent participant; muting or unpublishing tracks does not stop agent-minute billing unless you disconnect the agent. Would you like these numbers recomputed with: • your exact WebRTC participant rate, • GiB units (1 GiB = 1024^3 bytes), • or specific bitrates/participant counts from your expected workload?

provide links for detailed documentation on this

Thanks — here are direct documentation links for the billing and usage topics we discussed: • Pricing overview (agent minutes, bandwidth rates): https://livekit.io/pricing • Understanding LiveKit Cloud pricing & estimating usage: https://kb.livekit.io/articles/3947254704-understanding-livekit-cloud-pricing • Agents docs (agent sessions, toggling audio I/O, interrupt): https://docs.livekit.io/agents/ • Agent audio control example (toggle I/O): https://github.com/livekit/agents/blob/main/examples/voice_agents/toggle_io.py • Server SDK / Admin API (room & participant info): https://docs.livekit.io/server-sdk/ • Dashboard / Cloud Console (billing & analytics): https://docs.livekit.io/dashboard/ • Bandwidth & egress notes (egress billing explanation): https://docs.livekit.io/cloud/pricing/ • Deploy & scale agents (lifecycle, cold starts): https://docs.livekit.io/agents/ops/deployment/ If you want, I can: • Point to the exact API/endpoints or Python calls to pull join/disconnect timestamps, • Prepare a short Python snippet that converts

get_egress_info()

or participant stats into GB and cost, or • Recompute your sample bill using GiB (1024^3) instead of GB (10^9). Which would be most helpful? Sources: LiveKit Pricing | Understanding and Estimating Pricing for Video Conference and Livestream Us... | Text and transcriptions | LiveKit docs | Deploying to production | LiveKit Docs | Server-side | livekit/livekit_composite | DeepWiki

What can I do to reduce the costs ?

Good question — here are practical ways to reduce LiveKit costs (agent minutes, WebRTC participant minutes, and bandwidth), with actionable steps you can apply. 1) Reduce agent session minutes • Pause audio I/O instead of disconnecting when idle: ◦ Use

session.input.set_audio_enabled(False)

and

session.output.set_audio_enabled(False)

to stop media while keeping the agent alive. • Stop the agent when truly idle: ◦ Disconnect the agent if you expect long idle periods (this stops minute billing but requires restart on resume). • Use short-lived agents when possible: ◦ Start agents on demand for interactions and shut them down after inactivity (implement idle timeout). • Warm/cold strategy: ◦ Keep a small pool of warm agents for low-latency needs and spin up additional agents on demand. 2) Reduce WebRTC/participant minutes • Only keep human participants connected when needed: ◦ Disconnect or move silent/idle users out of media rooms (use a lightweight signaling-only presence channel if you need presence without media). • Aggregate sessions: ◦ For review/listen-only scenarios, consider recording once and serving playback instead of keeping everyone connected. 3) Reduce bandwidth (egress) costs • Lower media bitrates: ◦ Use lower audio bitrates (e.g., 32–48 kbps for voice) and adaptive bitrate settings. • Publish fewer tracks: ◦ Avoid sending unnecessary secondary tracks (e.g., multiple audio streams, high-res video). • Use selective forwarding: ◦ Only subscribe participants to tracks they need; avoid forwarding every track to every participant. • Pause output when user mutes: ◦ Disable agent output when the user mutes to stop downstream egress. • Use recording/transcoding wisely: ◦ Store recordings server-side rather than streaming to many participants live. 4) Architect for efficient egress • Fan-out considerations: ◦ Bandwidth is billed per downstream stream. Reduce number of simultaneous subscribers to heavy streams, or use a single mixed stream where appropriate. • Use multicast/streaming for large audiences: ◦ For many listeners, consider converting a live room to a broadcast/streaming egress (CDN) to reduce repeated egress from LiveKit. 5) Monitor, measure, and automate • Instrument join/disconnect timestamps and per-track stats (Python SDK

get_stats()

/ admin API) to analyze hot spots. • Use dashboard analytics to reconcile billed minutes and egress. • Implement auto-scaling and idle timeouts based on real usage patterns. 6) Pricing-aware features • Prefer free upstream (send) where possible — design interactions that minimize downstream server egress. • Bundle sessions: group short interactions into fewer, longer sessions when agent-minute startup overhead is costly. If you want, I can: • Estimate potential savings for your workload if you share typical session length, concurrent users, and audio bitrate, or • Provide a Python snippet to auto-pause agent I/O on user mute and log timestamps for billing reconciliation. Which would you like?

What does downstream bandwidth include? and upstream bandwidth is free right?

Thanks — I’ll clarify both items. • Downstream bandwidth = all data sent from LiveKit servers to participants (server → client). This includes: ◦ Media egress (audio/video sent to subscribers) ◦ Per-subscriber copies of published tracks (if 1 track is sent to N subscribers, egress counts N times) ◦ Recorded playback or live egress (recording downloads or streaming out) ◦ Any server-generated media (agent TTS audio sent to users, transcriptions sent as audio, mixed/marshaled streams) ◦ Additional exported egress (CDN or stream outputs originating from the LiveKit servers) • Upstream bandwidth = data sent from participants to LiveKit (client → server). This is not billed. Quick implications • Reducing the number of simultaneous subscribers to a heavy stream or switching to a mixed/combined stream reduces downstream egress. • Pausing an agent’s output stops downstream egress for that agent but does not stop connection-minute billing. Docs: • https://livekit.io/pricing • https://docs.livekit.io/cloud/pricing/ Would you like an example showing how per-subscriber egress multiplies for a given bitrate and user count?