i am using livekit cloud ot deploy my agent. sometimes using the livekit starter react ui, if i try to connect to the agent, it doesnt connect. there is no log on the agent side.

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

on browser, there are repeated api calls to /settings/regions url which does provide a list of urls and distance in response. but it keeps calling this /settings/regions url again and again

Thanks — that’s a helpful symptom. I’m looking at your issue where the Starter React UI repeatedly calls

/settings/regions

. That can cause extra network churn and may point to the client retrying region discovery before connecting. Quick checklist and next steps so I can pinpoint the root cause: • Which version of the Starter React UI /

@livekit/components-react

are you using? • What does the browser console show when those requests happen? Any errors (network failures, 429s, 500s)? Paste one full request/response pair if possible. • Is the response body for

/settings/regions

returning valid JSON with region URLs and distances each time, or is it an error/empty payload sometimes? • Are you running any custom code that calls region discovery, or is this the unmodified starter UI? • Does the repeated polling stop after a successful connect, or continue indefinitely even when connected? • Any proxy, adblocker, or corporate network that might interfere with caching or long‑lived connections? While you gather that, try this quick test: • Open DevTools → Network, filter by

/settings/regions

, then reproduce. Note the request frequency and response status codes. Share one normal and one failing example. Send the version, one request/response, and whether this behavior stops on connect — I’ll suggest the exact fix (config change, caching, or a patch) based on that. , with interactive elements

sometimes it works sometimes it doesnt. it starts a websocket to the livekit cloud everytime but the job isnt dispatched to the agent

Thanks — that helps. I’m addressing the two symptoms you mentioned: repeated calls to

/settings/regions

, and WebSocket connects that don’t dispatch a job to the agent. A few targeted questions to narrow this down: • Which versions are you using for the Starter React UI and

@livekit/components-react

? • How are you generating tokens in the UI (server endpoint, static token, TokenSource)? Paste one example response (no secrets) of the token endpoint payload and headers if you can. • In the browser console / Network tab, what is the HTTP status and response body for

/settings/regions

when it repeats? Is it always 200 with valid JSON, or are there intermittent errors (429/500/timeout)? • Do the repeated

/settings/regions

calls stop when a connection succeeds, or do they continue even after connect? • When the WebSocket opens but no job is dispatched, do you see any WebSocket close codes or ConnectionError events in the console? Copy one full WebSocket open/close sequence if possible. • Agent details: SDK/runtime version and deployment region, and whether your agent can cold-start (scales to zero). While you collect that, try this quick test and share results: 1. In DevTools → Network, reproduce until failure and capture one full sequence of

/settings/regions

requests plus the WebSocket frames. 2. Temporarily set

rtcConfig.iceTransportPolicy = 'relay'

in the client to rule out ICE/TURN issues. 3. Check your token timestamps (`nbf`/`exp`) and system clock drift. Send the version info, one

/settings/regions

request/response, and one WebSocket console excerpt — I’ll use those to recommend the exact next steps or a config/workaround. , with interactive elements

@livekit/components-react 2.9.21 token generation, etc is default from the github repo forget about the /settings/region dont htink thats the issue as its ui is able to connect via websocket to the cloud

Thanks — I’ll focus on why the UI opens a WebSocket but the job sometimes isn’t dispatched to the agent. Quick checklist of the most likely causes and the few pieces of info I need to pinpoint which one: • Confirm the agent dispatch name: what

agent_name

(dispatch name) does your agent deploy with, and does the frontend/token include that same name? If they don’t match, dispatch will not occur. • Replica count / cold starts: how many agent replicas did you deploy for that

agent_name

? Intermittent dispatches often happen with a single replica (cold starts/timeout). Deploying 3+ workers prevents contention/cold-start timeouts. • Token grants / creation timing: the starter repo token endpoint must include the dispatch info in the token when the room is created. Are you using the default token endpoint unmodified, or did you change token generation? Also confirm tokens aren’t expiring immediately (check `nbf`/`exp`). • Does dispatch succeed if you create a fresh room vs joining an existing room? Dispatch via token only applies when the room is first created. • Any WebSocket/console traces when dispatch fails (open/close codes or ConnectionError)? Paste one short excerpt. • Agent runtime/version and region, and whether agent logs ever show registration (even briefly) when dispatch succeeds. Immediate actions you can try now: • Ensure the token includes the correct

agent_name

dispatch grant and create a new room (don’t join an already-created room) to test. • Increase agent replicas to 3 for that

agent_name

to eliminate cold-starts/timeouts. • Capture one failing sequence: browser console + network (WebSocket frames) + the token response (mask secrets). Share those and I’ll give the exact fix. Tell me the

agent_name

, replica count, whether you modified token generation, and one short console/WebSocket excerpt and I’ll recommend the next concrete step. Sources: Build agent experiences faster with Session APIs | LiveKit | Diagnosing Connection Errors with Connection Test Utility | Agent dispatch | LiveKit Documentation, with interactive elements

i havent configured agent name in the agent

Thanks — that explains the symptom. If the agent has no configured

agent_name

, the frontend’s dispatch won’t target it, so rooms can open (WebSocket connects) but no job is assigned. What to do next (quick steps): 1. Choose an agent dispatch name (example:

voice-agent

). 2. Deploy the agent with that name: ◦ If using the CLI:

lk agent deploy --name voice-agent

(or set

agent_name

in your deploy config). 1. Update your token generation so the token includes the same

agent_name

dispatch grant when creating the room (ensure the token is created at room creation time). 2. Deploy multiple replicas to avoid cold-start timeouts: set replicas to 3 for that

agent_name

. 3. Test by creating a new room (not joining an existing one) and watch agent logs/console for the dispatched job. If you want, paste your deploy command/config and your token-generation snippet (remove secrets) and I’ll show the exact changes needed. , with interactive elements