Why livekit elevenlabs plugins creates a new context for every new stream for multi context web socket?

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

not just new context but a new connection altogether whenever a request is sent in the same livekit room/session.

Thanks — you're asking why the ElevenLabs plugin opens a brand-new WebSocket connection for each request (not just a new context) even when requests come from the same LiveKit room/session. Good clarification. Short answer: • A new WebSocket per request ensures strict per-stream isolation at the protocol level: ElevenLabs' streaming protocol expects one session/socket per synthesis stream so state, chunk ordering, and interruption semantics remain deterministic and independent. Technical reasons (concise): • Protocol session model: The ElevenLabs WebSocket protocol requires a dedicated session for each synthesis turn to manage lifecycle events (start, partial chunks, completion, cancel). Reusing a socket would require multiplexing those lifecycle messages and increases protocol complexity. • Per-stream transient state: Each synthesis needs its own tokenization, chunk scheduler, and alignment metadata tied to that connection. Tying those to separate sockets avoids cross-talk and race conditions. • Interruptions and cancellations: Independent sockets let the plugin abort or preempt a single stream cleanly without impacting other concurrent streams on the same room. • Timing and ordering guarantees: Separate connections give clear boundaries for chunk ordering and timestamp alignment per turn, which is important for accurate lip-sync/transcription alignment. • Resource/scale tradeoff: Opening many short-lived sockets simplifies correctness at the cost of connection overhead. That tradeoff is often chosen for real-time voice agents to favor determinism and low-latency behavior. If you want alternatives or optimizations, I can: • Suggest connection-reuse or multiplexing approaches (and the complexity they introduce), • Outline how to batch short requests or reuse a long-lived connection safely, • Or review your usage pattern (messages/sec, average stream length) and suggest a practical strategy. Which would you like me to show next?