Thanks — I’m responding to your pricing and architecture questions for a 1→10,000 live broadcast (60 min) with receive-only viewers. Short answers first • Yes — billing is primarily WebRTC participant minutes + downstream data transfer. • Yes — 10,000 viewers × 60 minutes = 600,000 WebRTC minutes. • For bandwidth, use ~1.2–1.7 Mbps per viewer for 720p (codec-dependent) and ~3.5–4.5 Mbps per viewer for 1080p as planning ranges. • A single room at 10,000 viewers is supported by LiveKit Cloud scale plans; very large single-room concurrency typically uses Scale/Enterprise-level limits rather than the default small-account caps. • Most cost-efficient pattern: publisher via WebRTC + LiveKit’s global WebRTC delivery (edge CDN) — you generally do not need to offload to external HLS/CDN unless you accept higher latency. • Recommendation for best tradeoff: use simulcast/adaptive layers, enable VP9 where clients support it, and enable livestream mode to reduce signaling overhead. Detailed breakdown and quick cost model 1) Billing components • You’ll be billed for WebRTC participant minutes (connected viewer time) and downstream data transfer (GB out). Other billed items (recording, telephony) are N/A here. 2) WebRTC minutes • Model as 600,000 WebRTC minutes (10,000 viewers × 60 minutes). 3) Downstream bandwidth assumptions (use these planning averages) • 720p: plan 1.2–1.7 Mbps per viewer (use 1.7 Mbps for conservative calc with H.264; 1.2 Mbps if VP9 is used). • 1080p: plan 3.5–4.5 Mbps per viewer. • Example (720p, conservative 1.7 Mbps): ◦ Total bits = 1.7 Mbps × 10,000 × 3,600s = 61,200,000 Mb = ~7.65 TB. ◦ Use your bandwidth unit costs to estimate dollar spend (pricing tiers/inclusions on Scale plan will affect final cost). 4) Concurrency / pricing tier • 10,000 concurrent receive-only viewers is a large single-room scenario that aligns with Scale / higher-tier plans. Scale plan inclusions and overages apply; for sustained or predictable high volume, a custom volume arrangement (enterprise) can reduce unit costs. 5) Architecture and cost-efficiency options • Best low-latency + cost approach: ◦ Keep the publisher on WebRTC. ◦ Deliver to viewers directly via LiveKit’s global WebRTC edge network (no extra CDN) — this preserves sub-second latency and is cost-competitive. ◦ Use simulcast or SVC so viewers only receive the layer matching their bandwidth/viewport. ◦ Enable VP9 where supported to reduce downstream bandwidth by ~15–30%. ◦ Use livestream mode to minimize unnecessary participant events for passive viewers. • When to use HLS/CDN instead: ◦ Use HLS only if you can accept higher latency (seconds) and want to leverage very-large-scale HTTP caching or ultra-cheap bandwidth billing from a CDN for multi-hundred-thousand viewers. That trades off interactivity and ultra-low latency. 6) Practical recommendations to reduce cost while keeping low latency • Prioritize simulcast/SVC + subscriber selection (deliver lower layers to smaller viewports). • Prefer VP9 for viewers/browsers that support it. • Avoid sending full-resolution streams to hidden/off-screen participants. • Use livestream mode to reduce signaling. • If you expect frequent peaks or predictable sustained usage, discuss volume pricing (Scale vs. Enterprise) to get bandwidth or WebRTC-minute discounts. If you’d like, I can: • Run a precise cost estimate using your preferred codec (H.264 vs VP9) and your bandwidth pricing per GB, or • Show the exact per-GB and per-minute plan inclusions and overage math for the Scale plan vs potential Enterprise options. Which would you prefer: a quick cost table using H.264 conservative bitrates or an estimate assuming VP9? Sources: Pricing | LiveKit | Pricing | LiveKit | A tale of two protocols: comparing WebRTC against HLS for live streaming | ... | WebRTC Video Bitrate Guide | LiveKit | Configuring the Client SDK for Optimal Video Quality, with interactive elements