Thanks — I can help troubleshoot this. You're seeing 429s from Deepgram TTS reporting the maximum concurrent websockets ~45, but those errors occur even when you have fewer than 45 concurrent calls. You asked whether a single TTS call can consume more than one websocket and whether using multiple API keys could help. Quick summary of what I can and cannot confirm: • I cannot confirm from LiveKit sources whether a single Deepgram TTS call can open multiple websockets. The LiveKit docs describe using Deepgram TTS through LiveKit Inference but do not state Deepgram’s websocket concurrency behavior or per-call socket usage. (Deepgram-specific concurrency details are not included in the LiveKit documentation.) • I also cannot confirm from LiveKit sources whether rotating or using multiple Deepgram API keys will avoid Deepgram-side websocket concurrency limits. What we can do next (questions and suggestions to narrow this down): 1. How is Deepgram integrated in your self-hosted setup? ◦ Are you calling Deepgram directly from your application using Deepgram API keys, or are you using the LiveKit Inference plugin/adapter to call Deepgram? ◦ If using LiveKit Inference, which component holds the Deepgram key (the inference service, a plugin container, or clients)? 1. Can you share a small sample of how you open TTS connections (pseudocode or sequence)? In particular: ◦ Are you opening a websocket per TTS request, or are you reusing a single websocket/connection and sending multiple requests over it? ◦ Do you use streaming TTS (long-lived websocket) or discrete request/response over websocket/HTTP? Why those questions matter: • If each request opens a new websocket connection, transient overlaps (retries, backoff, or voice chunking) can cause more simultaneous sockets than the number of logical “calls” you count. • Some client libraries or integrations open control/data sockets plus additional sockets for audio or events, which can make one logical TTS session use multiple TCP/websocket connections. • If your integration creates short-lived sockets rapidly, Deepgram may see peaks that exceed the stated concurrent limit even though your measured “active calls” is lower. Practical mitigations you can try now: • Reuse connections where possible: Use a pooled or long-lived websocket and multiplex multiple TTS requests over it (if Deepgram supports that for TTS). This prevents one-request-per-socket spikes. • Add client-side concurrency limiting: throttle outbound TTS requests so you never exceed a safe concurrency level (e.g., keep a small headroom below 45). • Add exponential backoff + jitter for 429 responses to avoid thundering retries. • If you are not already, log connection creation and closure times and active-open websocket counts from your side to correlate with Deepgram 429s. • Consider queuing or batching TTS requests if they come in bursts. If you want, I can: • Walk through your integration code (pseudocode or snippets) and point out where multiple sockets might be opened. • Help design a simple concurrency limiter or connection-pooling approach for your environment. • Suggest specific logging points to collect the data needed to confirm whether multiple sockets are opened per logical call. Which of the follow-ups above would be most helpful? If you share how Deepgram is called in your setup (direct API vs. LiveKit Inference, and a short sequence or snippet), I’ll give targeted steps to reduce or eliminate the 429s. Sources: Deepgram TTS | LiveKit Documentation