melodic-zoo-29246
02/12/2026, 8:18 PMtall-airline-16756
02/12/2026, 8:18 PMtall-airline-16756
02/12/2026, 8:19 PMWSServerHandshakeError with a 429 (Too Many Requests) when connecting to <wss://agent-gateway.livekit.cloud/v1/stt>. That status means the server is refusing the WebSocket handshake because the client is making too many connection attempts in a short time.
What you can do next
• Check agent lifecycle: Ensure your agent process is long-running rather than frequently creating short-lived connections. LiveKit Cloud expects a few persistent agents instead of many rapid reconnects.
• Add exponential backoff retries: When a connection fails with 429, retry with increasing delays (for example: 500ms, 1s, 2s, 4s) and a maximum retry limit to avoid further rate limiting.
• Space out test/dev connections: If you’re running load tests or rapid restarts, slow down connection frequency or use a separate test project so you don’t affect production limits.
• Confirm network path: Verify your environment can reach agent-gateway.livekit.cloud and that there’s no intermediate rate limiting (proxy, firewall, or cloud provider) causing bursts of reconnects.
Quick troubleshooting questions to narrow this down
1. Are you seeing this only during development/test runs or in production as well?
2. How many agent instances/clients are attempting to connect at the same time?
3. Are your agents restarting frequently (e.g., crash loops, autoscaling churn)?
4. Do you already have retry/backoff logic implemented? If so, what backoff strategy are you using?
If you share answers to the questions above (and any relevant snippets of how you create/reconnect the WebSocket), I’ll suggest concrete changes to your connection/retry logic and deployment configuration.
Sources: Can you increase agent deployment limits? | LiveKit | server-sdk-go | livekit/livekit_composite | DeepWiki | Diagnosing Connection Errors with Connection Test Utility