@agreeable-zebra-12399 Hi, did you find the solution? I'm also facing this and it's literally frustrating 🥲

Thanks — I hear you both. I’m sorry this is blocking your work; that repeated “Context X not found” plus the WebSocket errors is frustrating. I’ll keep this short and actionable so you (or Abhishek) can move forward quickly. What I’m responding to: you’re seeing Inworld WebSocket connection errors and Inworld returning “Context ... not found” during TTS, even after switching to predefined voices. Logs show the plugin hits a WebSocket/session failure which then causes internal streams (BufferedSentenceStream) to be closed and TTS retries to fail. What I need right now (the most important items) • Result of the direct cURL test shown in your logs (the one that posts to Inworld TTS with your Base64 Bearer). Tell me whether it: ◦ Succeeds and returns audio, or ◦ Returns “Context not found” (or another error). Paste the response body (redact keys). • The first ~20 debug log lines for the WebSocket handshake attempt from the plugin run (the lines during the initial WS connection). Redact any keys but keep the request path and the exact error payload/status. • Whether a minimal standalone script that only creates an Inworld TTS instance and calls synth (no LiveKit room) succeeds or fails. If you can’t run the cURL test, at least paste the exact cURL response or the initial WS handshake logs. Quick actionable checks to try right away 1. Curl test (isolate the plugin) • Run the curl printed in your logs exactly. If it fails with “Context not found”, the issue is with the Inworld API/session or the key/permissions. If it succeeds, the LiveKit plugin/WS lifecycle is the problem. 1. Confirm API key encoding & runtime value • Ensure INWORLD_API_KEY is the Base64 string (no extra newlines). Decode locally and verify it matches your Inworld key. • Confirm the agent process picks up the same ENV var (print a masked value at startup). 1. Minimal standalone repro • Create a tiny script that only initializes Inworld TTS and synthesizes “Hello”. If it works, the problem is how the plugin is used inside your agent (retries/concurrency). 1. Add defensive handling / recreate-on-failure (workaround) • Catch Inworld APIError / APIConnectionError in your TTS flow, close the current TTS object, sleep a short backoff (0.5–1s), recreate the TTS instance, and retry once. This forces a fresh WebSocket/session and often fixes transient context/session failures. 1. Guard tokenizer stream calls • Before calling

end_input()

/

flush()

check if the tokenizer stream is still open. Avoid calling these on a closed stream to prevent the downstream RuntimeError. 1. Network & proxy • Ensure outbound secure WebSocket access to api.inworld.ai:443 is allowed and there’s no proxy that breaks WS upgrade. 1. Upgrade packages • Make sure you’re on the latest

livekit-plugins-inworld

/

livekit-agents

— later versions include WebSocket/session handling fixes. If you share the cURL result and the initial WS logs (I know you’ve pasted long logs already — we specifically need the handshake/request/first failure lines), I will: • Tell you whether the failure is Inworld-side or plugin-side. • Give a tiny code diff to add recreate-on-failure and stream guards to your agent so it won’t crash and will attempt a fresh session automatically. Paste the curl result or the first WS handshake error and I’ll give the exact next steps/code to run. I’ll stay with you step-by-step until this is resolved.