Thanks — you're asking whether you can collect LiveKit metrics in a separate application to avoid choking your LiveKit SDK service. Yes — you can, and that’s the recommended approach. What you can do (options): • Emit metrics events asynchronously (e.g.,

metrics_collected

,

eou_metrics_collected

) and handle them in background tasks so they don't block the main agent loop. • Forward metrics to an external collector using OpenTelemetry/OTLP so a separate collector or backend (Prometheus, Jaeger, cloud APM) receives the data. • Use a dedicated metrics service: post metrics via HTTP webhooks, push to a message queue, or write to a usage-aggregation service that processes and stores metrics outside the SDK process. • Aggregate with LiveKit’s

UsageCollector

(or session reports) and periodically flush/export those reports after session end to an external system. Best practices to avoid impact: • Perform network calls or heavy processing (serialization, DB writes, logging) off the main thread/process. • Buffer or batch metrics and send them in intervals. • Prewarm components (e.g., VAD) where applicable to reduce per-session overhead. • Use existing observability exports (OpenTelemetry/OTLP) where possible to centralize processing. If you want, tell me which SDK and language you’re using (Node, Python, or other) and whether you prefer OTLP, webhooks, or a message queue — I’ll provide a short code example and implementation steps. Sources: STT Metrics | LiveKit docs | Examples | livekit/livekit_composite | DeepWiki | Agents (Python) | livekit/livekit_composite | DeepWiki | Agents (Node.js) | livekit/livekit_composite | DeepWiki | LiveKit Pricing