Thanks — I see you're hitting a

WSServerHandshakeError: 400 Invalid response status

when connecting to Deepgram's Flux model using your AgentSession code, and that you already tried a new API key. Let's walk through the most likely causes and quick checks you can run to get this resolved. Summary of the most likely causes • Authentication failure (most common): the Deepgram key is missing, not loaded, or not sent correctly. • Wrong model name: the Flux model requires the specific name

flux-general-en

. • Network/proxy blocking WebSocket handshakes (corporate proxies, ZScaler, VPNs). • Extra/unsupported query parameters in the WebSocket URL. What to check and try (in order) 1. Confirm the API key is loaded and being sent ◦ Add a quick check to confirm your env var is present:

from dotenv import load_dotenv
     import os

     load_dotenv()
     print("DEEPGRAM_API_KEY loaded:", "yes" if os.getenv("DEEPGRAM_API_KEY") else "no")

• If it prints "no", ensure

.env

is loaded before you read the key and that the key name matches. 1. Use the exact model name required ◦ Update your STT config to use:

stt=deepgram.STTv2(model="flux-general-en", eot_timeout_ms=1000)

•

flux-general

is rejected;

flux-general-en

is the correct model name. 1. Test the WebSocket handshake manually ◦ A successful handshake returns HTTP 101. You can try a curl-style test to confirm:

curl -i -N -H "Upgrade: websocket" \
       -H "Connection: Upgrade" \
       -H "Sec-WebSocket-Key: SGVsbG8sIHdvcmxkIQ==" \
       -H "Sec-WebSocket-Version: 13" \
       -H "Authorization: Token YOUR_DEEPGRAM_API_KEY" \
       "<wss://api.deepgram.com/v2/listen?model=flux-general-en&sample_rate=16000&encoding=linear16&eot_timeout_ms=1000>"

• Replace

YOUR_DEEPGRAM_API_KEY

. If you still get a 400 here, the issue is at the Deepgram handshake step (auth or params). 1. Reduce parameters to a minimal test ◦ Temporarily remove extra params and test:

stt=deepgram.STTv2(model="flux-general-en")

• If that works, add one parameter at a time to find which param triggers rejection. 1. Check network/proxy interference ◦ Corporate proxies or deep packet inspection (ZScaler, other appliances) often break WebSocket handshakes. ◦ Try running the same script from a different network (home/mobile hotspot) to rule out proxy/firewall issues. 1. Ensure the plugin and env loading are correct ◦ Confirm Deepgram plugin is installed:

pip install "livekit-agents[deepgram]"

• Confirm

load_dotenv()

runs before

os.getenv("DEEPGRAM_API_KEY")

. Debugging helpers to add • Print the full WebSocket URL the client is using (to confirm model/query string). • Print whether the DEEPGRAM key is present (see step 1). • Capture and share the exact server response headers if you can (curl -i helps). What to do if this persists • If the key is present, the model name is

flux-general-en

, you've tried minimal params, and you still get a 400 from the manual curl test — this is a rejection at the Deepgram server during the handshake (typically auth or parameter-related). • Since you've already tried a new key, re-check that the key has streaming/API permissions and that there's no accidental whitespace/newline when loading it from env. If you'd like, share: • The output of the DEEPGRAM_API_KEY loaded check, • The exact WebSocket URL your client prints, • Whether the manual curl attempt returned 101 or 400 and any response headers you see. I can then suggest the next targeted steps based on those results. Sources: Deepgram STT | LiveKit Documentation | Configure ZScaler proxy for LiveKit connections | LiveKit