We are getting 429s on an organisation. That organisation is a dev one that is on a free plan but our main on in production is on the scale plan and spends a lot of money per month. Is it possible to share bandwidth across both orgs? We have a separate one to ensure that devs do not push breaking changes to production agents and to have separate between local and production.

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

Does the LiveKit team offer a solution around this to ensure security is maintained between different environments? Is there a contact email address or specific person to reach out to?

You're asking whether LiveKit offers solutions to keep dev and prod environments secure and who to contact — I’m responding with recommended approaches and the appropriate contacts. Recommended practices to maintain security/isolation between environments: • Use separate LiveKit projects for dev, staging, and production with distinct

LIVEKIT_API_KEY

,

LIVEKIT_API_SECRET

, and

LIVEKIT_URL

. • Store secrets in environment variables or a secret manager; never commit them to source control. • Apply role-based access controls so only needed people/services can access each project. • Keep heavy testing on a paid/staging project sized for your load (the free plan has strict limits that cause 429s). Contacts: • For technical or deployment questions: support@livekit.io • For security/privacy or compliance questions: privacy@livekit.io • For enterprise onboarding, larger deployments, or sales assistance: https://livekit.io/contact-sales If you’d like, tell me which security concerns matter most (e.g., preventing accidental production access, secret management, auditing, or E2EE) and whether you prefer a staged paid project or upgrading your dev project — I’ll recommend the most practical next steps. Sources: Deploying to custom environments | LiveKit docs | Secrets management | LiveKit docs | LiveKit Pricing | LiveKit | Contact sales

If I am seeing 429 for both tts and stt it means I've hit provided limits for the week / month right? when does this reset?

You're seeing 429s for TTS and STT because you've hit LiveKit Inference limits. • TTS/STT use concurrency limits (number of active generations/connections). When concurrency is maxed, new requests return 429 until existing sessions finish and capacity frees up. • Rate limits (used for some LLM endpoints) are enforced over sliding windows (e.g., per minute); those reset continuously as the window advances. • Monthly metered quotas (inference credits on free plans) reset on the first day of each calendar month. If you tell me whether the 429s occur when many sessions are active or during short bursts of requests, I can recommend whether to throttle/retry with backoff, reduce concurrent sessions, or upgrade the dev project to a paid tier. Sources: Quotas and limits | LiveKit docs

There are currently no concurrent sessions that I can see running - the last call was 5 minutes ago and no agents are currently seen on the dashboard

Thanks — you mentioned there are no visible concurrent sessions and the last call was 5 minutes ago. Here are the likely causes and next steps. Possible causes • Concurrency limits: even if no sessions show on the dashboard, an active inference may still be counted for a short time after a call completes. • Rate limits / sliding windows: short bursts of requests can exceed per-minute windows and return 429s even with few concurrent sessions. • Monthly metered quota exhausted: your dev project's inference credits (free-plan monthly allotment) reset on the first day of the calendar month; if credits are used up, requests will 429 until the quota resets or the plan is upgraded. What to check now • Verify your project plan (Build/free vs Ship/Scale) in the Cloud dashboard. • Check the Inference usage and quotas in the dashboard to see if you’ve hit the monthly credit cap or are spiking rate/concurrency. • Review recent request patterns (bursts vs steady) and exact timestamps of 429 responses. Immediate mitigations • Implement retry with exponential backoff for 429 responses. • Add client-side throttling to limit bursts and reduce concurrent inferences. • If you need sustained higher capacity for dev testing, upgrade the dev project to a paid plan or use a paid staging project sized for your load. If you’d like, share: • which plan the dev project is on, and • an example timestamped request pattern or recent 429 response headers (if available), and I’ll recommend the most targeted next step.

raise WSServerHandshakeError( aiohttp.client_exceptions.WSServerHandshakeError: 429, message='Invalid response status', url='wss://agent-gateway.livekit.cloud/v1/stt' 5 minutes ago

Thanks — you shared the exact error and timestamp. I’m responding about why the STT websocket returned a 429 and what to check next. What this error means • A 429 on the STT websocket handshake indicates you hit an inference-related limit (rate or concurrency) or exhausted metered inference credits for that project. The websocket server rejects the handshake with 429 when capacity/quota isn’t available. What to check now • Project plan: confirm the dev project is on the free Build plan (has low concurrency and monthly credit limits). • Inference usage/quotas in the LiveKit Cloud dashboard to see if monthly credits are exhausted or if concurrency is maxed. • Recent request pattern around that timestamp (bursts vs steady) and any other 429s with matching times. Immediate mitigations • Retry websocket connections with exponential backoff. • Limit concurrent STT/TTS sessions in dev (reduce simultaneous connections). • Shift heavy testing to a paid staging project or upgrade the dev project to a paid tier for higher concurrency and credits. If you want, share the dev project’s plan (Build/Ship/Scale) and a short sample of your connection pattern (e.g., number of connection attempts around that time). I’ll give a targeted recommendation (throttle settings or plan tier to fit your testing).