When session ends, in which event does livekit publishes cost?

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

LiveKit Cloud

Thanks — you’re asking which LiveKit Cloud event publishes cost when a session (room) ends. I’ll answer that directly and explain how to track costs. Short answer • LiveKit Cloud does not publish detailed cost information in a session-end event. There is no webhook or event that contains line-item charges when a room ends. What you can use instead • Use the

room_finished

webhook event to detect when a session ends. It includes room metadata (room name, start/end time, participants) but does not include cost data. • Calculate estimates yourself by correlating

room_started

/

room_finished

timestamps and participant connection data to get connection minutes, then combine that with bandwidth/transcoding usage to estimate cost. • Final, exact charges appear on your LiveKit Cloud project billing (usage metrics and invoices) in the dashboard. Helpful details and next steps • If you want automated near-real-time cost estimates per session: ◦ Capture

room_started

and

room_finished

webhooks. ◦ Track participant join/leave timestamps to compute per-participant connection minutes. ◦ Collect bandwidth and transcoding metrics (egress/ingress) for the room if you need to include data-based charges. ◦ Apply your project’s pricing rules (connection minutes, bandwidth, transcoding, agent session pricing such as $0.01 per agent session minute) to produce an estimated cost per session. • If you’d like, I can: ◦ Outline a concrete example calculation given your project’s pricing and a sample room timeline. ◦ Suggest a webhook/event processing layout to capture the necessary metrics automatically. Which would you prefer — an example end-to-end cost calculation, or a short webhook processing design to estimate costs in real time? Sources: Best practices for managing webhook event streams | LiveKit | Understanding and Estimating Pricing for Video Conference and Livestream Us... | Deploy and scale agents on LiveKit Cloud | Terms of Service | LiveKit

both. Outline a concrete example calculation and Suggest a webhook/event processing layout

Thanks — I’ll walk through both a concrete example cost calculation and a practical webhook/event processing layout you can implement on LiveKit Cloud. Concrete example calculation (video session) Assumptions • 4 standard human participants (billable) • Room duration: 60 minutes • Average outbound bitrate per participant: 1.5 Mbps (1,500,000 bps) • Pricing used for this example: ◦ Connection minutes: $0.01 / minute ◦ Bandwidth: $0.12 / GB ◦ Transcoding (egress/composite): $0.10 / minute Step 1 — Bandwidth 1. Convert bitrate to bytes/sec: 1,500,000 ÷ 8 = 187,500 B/s 2. Bytes per participant for 60 minutes: 187,500 × 3,600 = 675,000,000 bytes 3. GB per participant: 675,000,000 ÷ (1024^3) ≈ 0.628 GB 4. Total GB for 4 participants: 0.628 × 4 = 2.512 GB 5. Bandwidth cost: 2.512 × $0.12 ≈ $0.30 Step 2 — Connection minutes 1. Total connection minutes: 4 participants × 60 minutes = 240 minutes 2. Connection cost: 240 × $0.01 = $2.40 Step 3 — Transcoding 1. Transcoding minutes (if composite/egress runs entire session): 60 minutes 2. Transcoding cost: 60 × $0.10 = $6.00 Total estimated cost = Bandwidth ($0.30) + Connection ($2.40) + Transcoding ($6.00) = $8.70 Notes on the example • Agent sessions are billed differently (example: $0.01 per agent session minute); include agent rates where relevant. • These are estimates — LiveKit Cloud does not publish line-item cost in a room-end event. Final charges are reflected in your project billing and invoices. Webhook / event processing layout to estimate costs in real time Overview • Use LiveKit webhooks to capture lifecycle and participant events, persist session state, compute running estimates periodically, and finalize on

room_finished

. Make endpoints idempotent and verify webhook signatures. Suggested components • Webhook receiver (HTTP endpoint) • Processing worker / queue for asynchronous work • Session store (DB) to persist session metadata and running cost estimates • Periodic reconciler (background job) to update running costs every N minutes Event handling flow 1. room_started ◦ Create session record: room_id, start_time, initial state, cost = 0. ◦ Optionally start a periodic job to produce running estimates. 1. participant_joined ◦ Record participant_id, join_time, participant_type (standard/agent/ingress/egress). ◦ Mark participant as billable if type = standard or agent. 1. participant_left (or participant_disconnected) ◦ Record leave_time, compute that participant's connection minutes for the interval, update running connection minutes. 1. egress_started / egress_ended (or composite/recording webhooks) ◦ Track start/end times for transcoding/egress to compute transcoding minutes. 1. Periodic status reconciliation (every 5–10 minutes) ◦ For each active session: ▪︎ Calculate elapsed minutes since last reconciliation for each billable participant (based on join/leave events). ▪︎ Estimate bandwidth since last reconciliation: use known/assumed bitrates per participant or, if available, actual egress metrics. ▪︎ Add incremental costs to the session record. ◦ Persist running estimate to DB/monitoring to display near-real-time cost. 1. room_finished ◦ Finalize session: set end_time, finalize any open participant/leaving windows, finalize egress/transcoding durations. ◦ Run final cost calculation: ▪︎ Sum connection minutes × connection rate ▪︎ Sum bandwidth GB × bandwidth rate ▪︎ Sum transcoding minutes × transcoding rate ◦ Persist final cost and push summary to your billing/analytics dashboard. Implementation details & best practices • Use

room_finished

to detect session end; it contains start/end timestamps and room metadata but not cost details. Use participant events to compute connection minutes and egress events to compute transcoding minutes. • Store every webhook event raw + parsed to allow reconciliation if events are missing or duplicated. • Validate webhook authenticity (JWT/signature) and return 2XX quickly; perform cost computations asynchronously. • Make handlers idempotent — webhooks may be retried. Use event IDs or timestamps to avoid double-counting. • If you need more precise bandwidth, capture egress metrics (if available) or instrument clients to report actual bytes sent/received. • Expose a near-real-time dashboard using the session store for ops/finops visibility; keep reconciliation frequency reasonable to balance accuracy and load. Would you like: • A sample data schema for the session store (tables/fields) that matches this flow? • An end-to-end example implementation (pseudo-code or a Node/Python sketch) of webhook handlers and reconciler using these events? Pick which one and I’ll provide the next level of detail. Sources: Understanding and Estimating Pricing for Video Conference and Livestream Us... | Deploy and scale agents on LiveKit Cloud | Server-side | livekit/livekit_composite | DeepWiki | Best practices for managing webhook event streams | LiveKit

which model was used ?

Thanks — quick clarification: by “which model was used?” do you mean one of these? • The pricing model used in the concrete cost calculation example (the cost rates and assumptions like $0.01/min, $0.12/GB, $0.10/min). • The AI model for LiveKit Cloud agents referenced earlier (the agent session pricing example). • The AI assistant / language model that generated the support responses you’ve been reading. Tell me which of the three you mean and I’ll answer precisely. If you meant the pricing assumptions, I can also show how to swap in your actual rates.

model used for stt, llm and tts for session in events

Thanks — I’ll answer which models LiveKit Cloud can use for STT, LLM, and TTS during agent/session events, and how they’re specified. Short answer • LiveKit uses LiveKit Inference (a unified model gateway) or provider plugins to run STT, LLM, and TTS. You choose the specific model for a session when you configure an AgentSession or inference call. LiveKit supports multiple models per category (examples listed below). STT (speech-to-text) examples you can select • AssemblyAI:

universal-streaming

,

universal-streaming-multilingual

• Cartesia:

ink-whisper

(100 languages) • Deepgram:

flux

(English),

nova-3

(multilingual),

nova-2

(33 languages / variants) • ElevenLabs:

scribe-v2-realtime

(41 languages) • Plugins available for Amazon Transcribe, Azure AI Speech, Google Cloud Speech, OpenAI, etc. (For multilingual automatic choice, use

deepgram/nova-3:multi

.) LLM (large language model) examples you can select • OpenAI: GPT-4o, GPT-4o mini, GPT-4.1, GPT-5 variants • Google Gemini: Gemini 3 Pro / Flash, Gemini 2.5 variants • DeepSeek: DeepSeek V3 / V3.2 • Kimi (Moonshot AI): Kimi K2 Instruct • Plugins available for Anthropic (Claude), Amazon Bedrock, Mistral, Together, xAI, and more. TTS (text-to-speech) examples you can select • Cartesia:

sonic-3

,

sonic-2

,

sonic-turbo

,

sonic

(multilingual) • Deepgram:

aura-2

(English/Spanish) • ElevenLabs:

eleven_flash_v2

,

eleven_turbo_v2

,

eleven_multilingual_v2

• Inworld:

inworld-tts-1.5-max

,

inworld-tts-1.5-mini

• Rime:

arcana

,

mistv2

• Plugins available for Baseten, Google Gemini, OpenAI, Resemble, etc. How you specify models in a session • You set the chosen model identifiers when creating/configuring an AgentSession. Example (pseudo-code):

session = AgentSession(
    stt="deepgram/nova-3:en",
    llm="openai/gpt-4.1-mini",
    tts="cartesia/sonic-3:voice-id",
)

Notes and practical tips • The exact model used for a session is determined by your session configuration (or plugin settings). LiveKit does not implicitly pick a single model — you request the model you want via the Inference API or plugin config. • For real-time audio-to-audio use cases, LiveKit supports Realtime-capable models (e.g., OpenAI Realtime, Amazon Nova Sonic) via the Realtime models path. • You can customize model params (language, voice, extra kwargs) per session. • If you need a recommended combination for a specific language, latency budget, or cost target, tell me your constraints and I’ll suggest STT/LLM/TTS choices and parameter settings. Would you like: • A recommended STT+LLM+TTS combo for low-latency real-time conversations, or • Exact model strings and example AgentSession JSON for a specific language/region? Sources: Introducing LiveKit Inference: A unified model interface for voice AI | Speech-to-text (STT) models overview | LiveKit Documentation | Deepgram TTS | LiveKit Documentation | Large language models (LLM) overview | LiveKit Documentation | DeepSeek LLM | LiveKit Documentation

does events have this info about which model was used

Thanks — I’m responding to your question about whether LiveKit Cloud events include which STT/LLM/TTS model was used. Short answer • No — LiveKit Cloud session/webhook events do not include explicit model identifiers for STT, LLM, or TTS. Events focus on session lifecycle, participants, and conversation content, not the provider or model names. How you can determine which model was used • Check the AgentSession configuration you created for the session — the model strings (for STT, LLM, TTS) are set there (for example:

stt="deepgram/nova-3:en"

,

llm="openai/gpt-4.1-mini"

,

tts="cartesia/sonic-3:voice-id"

). That configuration is the authoritative source of which models the session used. • Use Agent Observability in the LiveKit Cloud dashboard to inspect agent traces and session behavior. Observability can help you infer model usage from the agent’s configured tools and calls, though it does not necessarily attach explicit model identifiers into every event. • Add custom logging inside your agent logic: log the model identifiers at session start or whenever you switch models. Emit those logs to your own monitoring or link them to room IDs so you can correlate later with webhook events. Practical recommendation • If you need model-level visibility in downstream tooling or billing: ◦ Record the AgentSession model choices to your session store when the session is created. ◦ Include that record’s session/room ID in any cost or event summaries you produce. ◦ Optionally emit a custom webhook or log entry that explicitly states the STT/LLM/TTS model strings for that session. If you want, I can: • Show an example AgentSession payload and the exact fields to store for later correlation, or • Provide a short snippet (Node/Python) that logs the model identifiers at session start and ties them to the `room_id`/session events. Which would you prefer? Sources: Streamline troubleshooting with Agent Observability | Turns overview | LiveKit Documentation | Agent session | LiveKit Documentation