Agent session recordings Download and play back audio from recorded agent sessions How to?

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

how to enable?

You're asking how to enable Agent Observability (recording) so you can download and play back audio from agent sessions — here’s a clear, step‑by‑step guide. 1) Enable at the project level • Open the LiveKit Cloud Console for your project. • Go to Settings → Data and privacy. • Turn on recording / Agent Observability for the project. 2) Optional: Control per-agent recording • Individual agents can be excluded from recording by setting

record=False

in their agent code. This allows project-level recording to remain enabled while opting out specific agents. 3) Verify recordings and play/download • After a session completes, go to your Sessions Dashboard: https://cloud.livekit.io/projects/p_/sessions • Open the completed session and select the Agent insights tab. • Use the synchronized timeline to play back audio and scrub to moments of interest. • Downloadable assets (audio, transcript, logs) are available from the session details / Agent insights view. 4) Notes to keep in mind • Observability is disabled by default — enabling it at the project level is required to capture recordings. • Data is retained for 30 days and is currently stored in the US. • Agent Observability is available in Python Agents SDK v1.3+; TypeScript support is coming soon. Would you like me to walk through these steps in your console (I can guide you click‑by‑click), or check whether a particular project or session already has observability enabled? If yes, please share the project ID and (if available) a session ID.

How to do this programmatically? I want to store recordings in s3. Also, how much is incl. in free tier?

Thanks — I’m responding to your questions about enabling recordings programmatically, storing them in S3, and what’s included in the free tier. Quick summary: • Project-level Agent Observability must be enabled in the LiveKit Cloud Console (not via API). • You can control per-agent recording in code (enable/disable). • To store full media files directly in S3, use Egress (programmatic). • Agent Observability is free during beta; Egress has specific free/minute quotas on each plan. How to enable recording programmatically (what you can do) 1. Project-level enablement (required) ◦ Go to Project Settings → Data and privacy in the Cloud Console and enable Agent Observability. This step is manual and cannot be done via API or code. 1. Per-agent control in code ◦ When the project has Observability enabled, each agent session defaults to being recorded. ◦ To disable recording for a specific agent, set

record=False

in the agent session code. ◦ To ensure recording is enabled programmatically, omit

record=False

or explicitly set

record=True

. Example (Python agent snippet)

session = AgentSession(
    stt=...,
    llm=...,
    tts=...,
    # record=True  # default is recorded if project-level Observability is enabled
)
await session.start(agent=..., room=ctx.room)

How to store recordings in S3 (recommended approach) • Agent Observability stores session audio/transcripts/logs and exposes them in the Agent Insights UI. There is no direct API to push those Observability assets automatically to S3. • If you want recordings saved directly to S3 programmatically, use Egress (Room Composite Egress) to record the room and upload the file to S3. Basic Egress flow: 1. Start a Room Composite Egress request (specify

file_output

with

s3

details) to write a media file (e.g., WEBM/WAV) directly to your S3 bucket. 2. Listen for egress/webhook events (egress_ended or room_finished) and call stop_egress when done. 3. Optionally use webhooks to track status and perform post-processing. Example (conceptual Python pseudocode):

request = api.RoomCompositeEgressRequest(
    room_name="your-room",
    file_output=api.EncodedFileOutput(
        file_type=api.EncodedFileType.WEBM,
        filepath="recordings/session-1.webm",
        s3=api.S3Upload(
            bucket="your-bucket",
            region="us-west-2",
            access_key="YOUR_KEY",
            secret="YOUR_SECRET",
        ),
    ),
)
egress_info = await api.start_room_composite_egress(request)
# stop when room ends

Security note for S3 credentials • For production, prefer temporary credentials via AWS AssumeRole (S3 AssumeRole). This requires enabling S3 AssumeRole in project settings and is an Enterprise feature. When configured, leave `access_key`/`secret` blank in Egress requests and LiveKit will assume the role to write to your bucket. Workflow suggestion • Enable Agent Observability in the Console for session insights (audio, transcripts, traces). • Use Egress to store full media files directly to S3 for long-term storage/processing. • Use webhooks (egress_ended, room_finished) to trigger any post-upload processing or notifications. Free tier / included limits • Agent Observability: Free during beta (available to LiveKit Cloud users). Observability recordings are retained for 30 days and stored in the US. • Egress (S3 recordings): ◦ Build (Free): 60 minutes/month of track/room egress ◦ Ship: 600 minutes/month ◦ Scale: 8,000 minutes/month ◦ After included minutes, egress is billed (rate referenced in docs as $0.001/minute) ◦ Concurrent egress sessions: Free tier allows 2 concurrent exports If you want, I can: • Provide a complete working code example (Python or TypeScript) to start/stop Room Composite Egress to S3. • Show how to wire webhooks (egress_ended / room_finished) to automate uploads and cleanup. • Check which method fits your goal better: storing per-session agent observability assets (download from UI) vs full-room media egress to S3. Which would you like next — a full code example for Egress to S3, or step‑by‑step webhook + download flow to move Observability assets to S3?

If I self-host, would I not be incurred the charges of egress, agent session, webrtc minutes?

Short answer: Yes — if you self‑host LiveKit you are not charged by LiveKit for egress, agent sessions, or WebRTC minutes. Those usage-based charges apply to LiveKit Cloud only. A bit more detail to help you decide: • What self‑hosting means ◦ The open‑source LiveKit server is free to run on your own infrastructure. You won’t pay LiveKit per-minute or per-GB fees when running your own servers. ◦ You keep full control of the deployment, storage, and networking. • What you are responsible for when self‑hosting ◦ Infrastructure costs (VMs, bandwidth, storage) billed by your cloud or datacenter provider. ◦ Operational tasks: scaling, monitoring, reliability, security, backups, and upgrades. ◦ Building any automation to export/retain recordings (e.g., writing egress files to your S3 bucket). • What LiveKit Cloud charges (what you avoid by self‑hosting) ◦ LiveKit Cloud bills for usage components such as WebRTC minutes, agent session minutes, egress/transcoding, and managed storage/egress to S3. ◦ Those managed-service charges do not apply if you host the servers yourself. If you’d like, I can: • Outline a cost comparison checklist (example cloud costs vs expected self-hosted infra costs). • Recommend an architecture for reliably recording and uploading sessions to S3 when self-hosting. • Provide sample scripts or egress configuration to write recordings directly to S3 from a self‑hosted LiveKit deployment. Which of those would help you next? Sources: Pricing | LiveKit | The end of Participant Minute pricing | Deploy and scale agents on LiveKit Cloud

Yes outline.

Thanks — I’ll outline a clear cost-comparison checklist and practical guidance to help you decide between LiveKit Cloud and self-hosting for agent session recordings (S3 storage). I’ll highlight what you pay for, what you avoid by self-hosting, and the operational tradeoffs to consider. What you’re asking about • Whether self-hosting avoids LiveKit Cloud usage charges (egress, WebRTC/participant minutes, agent session minutes). • A side-by-side outline of costs and operational responsibilities for Cloud vs. self-hosted when recording and storing sessions in S3. Short summary • Self-hosting: You do not pay LiveKit Cloud usage fees (no per-minute or per-GB charges to LiveKit). You pay your infrastructure, bandwidth, and storage provider directly and handle ops. • LiveKit Cloud: LiveKit bills usage (WebRTC minutes, egress/transcode, agent minutes); it manages scaling, HA, and monitoring for you. Cost comparison checklist 1) Direct charges to LiveKit • LiveKit Cloud: billed for things such as WebRTC minutes/participant minutes, agent session minutes, egress/transcoding and managed export. These charges do not apply when you self-host. • Self-hosted: LiveKit itself does not charge per-minute or per-GB when self-hosted. 2) Infrastructure & cloud provider costs (you always pay these) • Compute for servers (VMs, Kubernetes nodes) • Bandwidth (egress costs from cloud provider or datacenter) • Storage (S3/object storage costs for recordings) • Load balancers, NAT, networking • Monitoring/logging/alerting (Prometheus, Grafana, etc.) 3) Recording-specific costs • LiveKit Cloud ◦ Egress/transcoding fees (e.g., transcoding minutes) and data transfer; LiveKit Cloud includes some egress minutes depending on plan. ◦ S3 storage is billed by AWS (LiveKit does not bill for S3). ◦ Free-tier allowances apply to egress minutes (e.g., Build plan ~60 min/month) — after that you pay per-minute rates. • Self-hosted ◦ You run egress workers (processes that produce files). Compute cost depends on how many concurrent recordings/transcoding you do. ◦ Storage and outbound transfer to S3 are billed by your cloud provider (AWS charges for PUTs, storage, and data transfer as usual). ◦ No LiveKit egress/transcode billing. 4) Operational costs (time, people) • LiveKit Cloud: lower operational overhead. LiveKit provides managed scaling, failover, and upgrades. • Self-hosted: higher ops effort — setup, HA, upgrades, capacity planning, incident response. 5) Security & compliance • LiveKit Cloud: built-in features and managed upgrades; may provide enterprise features like S3 AssumeRole integration for secure uploads. • Self-hosted: you control network isolation, IAM, encryption, and retention policies; you must implement secure key handling and role assumption if desired. 6) Reliability & performance • LiveKit Cloud: SLA/managed availability and multi-region options (depending on plan). • Self-hosted: you must design HA, auto-scaling, and monitoring to meet your SLAs. Example cost drivers — estimate considerations • Number of concurrent rooms and recordings (determines required servers and egress worker capacity) • Average session length (minutes) × number of sessions (drives bandwidth & storage) • Recording type (audio-only is much cheaper than video; audio raw or opus is smallest) • Need for on-the-fly transcoding (increases CPU and costs) • S3 request and storage pricing (PUTs, GETs, storage GB-month, and egress) Practical architecture suggestions for self-hosting + S3 recordings • Use Room Composite Egress or Track Egress to produce per-session files; upload directly to your S3 bucket. • Run Egress workers in the same region as your S3 bucket to reduce egress costs and latency. • For production, use autoscaling groups or Kubernetes HorizontalPodAutoscaler for egress workers to handle peak loads. • Use S3 multipart uploads for large files and retry logic for robustness. • Use IAM AssumeRole + short-lived credentials for uploads (if you want fine-grained security); configure this in your AWS setup and use instance profiles or STS tokens in your processes. • Capture webhooks (egress_ended, room_finished) to trigger post-processing, metadata updates, or cleanup. Operational checklist before self-hosting • Capacity plan: CPU/RAM per expected concurrent rooms and egress/transcoding load. • Network plan: bandwidth reservations and cost estimates from your cloud provider. • Storage plan: S3 lifecycle rules (archive older recordings to Glacier), retention policy. • Monitoring & alerting: metrics for connection failures, CPU spikes, dropped frames, egress job failures. • Backups & upgrades: a plan to upgrade LiveKit, rolling deployment strategy, and backups for configuration. When LiveKit Cloud makes sense • You want minimal ops and fast time-to-market. • You prefer predictable managed scaling, multi-region availability, and built-in analytics. • You accept usage-based pricing in exchange for reduced operational burden. When self-hosting makes sense • You need to avoid LiveKit Cloud usage fees (per-minute or per-GB) and are able to manage infrastructure costs and ops. • You need custom networking, on-premises compliance, or air-gapped deployments. • You want to optimize at scale and control cost by tuning your infra. Would you like: • A sample cost-estimate worksheet I can populate with your expected concurrent sessions, average length, and region to compare Cloud vs self-hosted numbers? • A recommended Kubernetes deployment architecture and sizing guide for X concurrent audio-only recordings? (If yes, tell me expected concurrent recordings and average duration.) Which of those would you like me to prepare next? Sources: Universal Egress | examples/frontdesk | livekit/livekit_composite | DeepWiki | Pricing | LiveKit | The end of Participant Minute pricing | Announcing LiveKit Cloud