hey, I have deployed my worker on google cloud us-west4, I have these logs:

2025-12-15 20:25:34,322 - ai-server - INFO - Starting AI in DEV mode
{"level": "INFO", "name": "livekit.agents", "message": "starting worker", "version": "1.3.6", "rtc-version": "1.0.20", "timestamp": "2025-12-15T20:25:37.463740+00:00"}
{"level": "INFO", "name": "livekit.agents", "message": "preloading plugins", "packages": ["livekit.plugins.silero", "livekit.plugins.openai", "livekit.plugins.deepgram", "livekit.plugins.cartesia", "livekit.plugins.turn_detector", "av"], "timestamp": "2025-12-15T20:25:37.464001+00:00"}
{"level": "INFO", "name": "livekit.agents", "message": "starting inference executor", "timestamp": "2025-12-15T20:25:37.491301+00:00"}
{"level": "INFO", "name": "livekit.agents", "message": "initializing process", "pid": 27, "inference": true, "timestamp": "2025-12-15T20:25:40.963724+00:00"}
{"level": "INFO", "name": "livekit.agents", "message": "process initialized", "pid": 27, "inference": true, "elapsed_time": 6.75, "timestamp": "2025-12-15T20:25:47.710531+00:00"}
{"level": "INFO", "name": "livekit.agents", "message": "HTTP server listening on :8081", "timestamp": "2025-12-15T20:25:47.713294+00:00"}
{"level": "INFO", "name": "livekit.agents", "message": "initializing process", "pid": 30, "timestamp": "2025-12-15T20:25:47.720787+00:00"}
{"level": "INFO", "name": "livekit.agents", "message": "process initialized", "pid": 30, "elapsed_time": 0.22, "timestamp": "2025-12-15T20:25:47.943491+00:00"}
{"level": "INFO", "name": "livekit.agents", "message": "registered worker", "agent_name": "", "id": "AW_vEpvQ2324sZw", "url": "<wss://demo-re02a3bf.livekit.cloud>", "region": "US West B", "protocol": 16, "timestamp": "2025-12-15T20:25:48.027801+00:00"}

When I try to connect from my local client using the same keys and url, the worker never receives the jobs. If I run the worker locally (with the same keys and url) the client is able to connect to it. Am I missing something?

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

i'm not sure about it. when running the worker in my local agent_name also comes as an empty string and the client is able to connect to it

{"message": "job runner initialized", "level": "INFO", "name": "livekit.agents", "tid": 31544, "elapsed_time": 1.32, "timestamp": "2025-12-15T20:33:49.406541+00:00"}
{"message": "registered worker", "level": "INFO", "name": "livekit.agents", "id": "AW_hemuc7A3rWwu", "url": "<wss://demo-re02a3bf.livekit.cloud>", "region": "Brazil", "protocol": 16, "timestamp": "2025-12-15T20:33:49.674790+00:00"}
{"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.9130000000000003, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.75)", "timestamp": "2025-12-15T20:34:22.323854+00:00"}
{"message": "worker is below capacity, marking as available", "level": "INFO", "name": "livekit.agents", "load": 0.28500000000000025, "threshold": "_WorkerEnvOption(dev_default=inf, prod_default=0.75)", "timestamp": "2025-12-15T20:34:24.830251+00:00"}
{"message": "received job request", "level": "INFO", "name": "livekit.agents", "job_id": "AJ_awtst3hmfCYp", "dispatch_id": "AD_5ZgkFwgC24Bu", "room_name": "voice_assistant_room_2851_72dbf1f216ce5dfafa0e76ee2cbd031638a4c1209d06628d1630beaac12ec27e", "agent_name": "", "resuming": false, "timestamp": "2025-12-15T20:34:25.676662+00:00"}
{"message": "connecting to room voice_assistant_room_2851_72dbf1f216ce5dfafa0e76ee2cbd031638a4c1209d06628d1630beaac12ec27e", "level": "INFO", "name": "voice-agent", "timestamp": "2025-12-15T20:34:25.732122+00:00"}

Thanks — I see your local worker shows an empty

agent_name

but still receives jobs, while the GCP-deployed worker registers but doesn't. I’ll help narrow this down. Quick diagnostic steps — please check and share the first item you can: 1. How you create the room / token ◦ Paste (redact keys) the code or JSON you use to create the access token or room config, especially any RoomAgentDispatch/agents fields. 1. Environment mode and agent options on GCP vs local ◦ Are you running the deployed worker with the same env vars and flags as locally (e.g.,

LIVEKIT_ENV=dev

vs

prod

)? Share the worker start command or relevant env vars. 1. Recent worker logs around capacity/availability on GCP ◦ You previously saw messages about “worker is at full capacity, marking as unavailable” locally. Do the GCP logs show similar capacity/availability transitions after registration? 1. Dispatch behavior you expect ◦ Do you expect automatic dispatch (any agent) or explicit dispatch to a named agent? If the latter, are you setting

agent_name

in the room/token? What I’ll look for after you share any of the above: • If tokens/room config request explicit agent dispatch that doesn't match the deployed worker, that explains no jobs. • If GCP is running in prod mode or hitting the load threshold, the worker may mark unavailable even though it registered. • If tokens use automatic dispatch, we’ll check why the GCP worker is marked unavailable or filtered by region/other rules. Which of the four items can you provide first? Sources: Agent dispatch | LiveKit docs | Agent server options | LiveKit docs | Still Have Questions

is the region by any chance related to the issue?

Short answer: yes — region can affect dispatch. Why: LiveKit routes jobs with geographic affinity toward agents closest to the LiveKit project region. If your GCP worker is in a different region than the project (or than where LiveKit expects agents), jobs may be routed elsewhere or delayed even though the worker successfully registers. What to check next (quick list): • Confirm your LiveKit project region (which region is your LiveKit Cloud project hosted in). • Confirm your GCP instance region (you said us-west4). Make sure it matches or is close to the LiveKit project region. • Check worker availability logs on GCP for capacity/availability transitions after registration (e.g., “marking as unavailable”) — a registered worker can still be filtered out if marked unavailable. • Verify the LIVEKIT_URL, API key, and secret point to the correct project/region. • Ensure no network egress/firewall restrictions block outgoing WebSocket/TURN connections from GCP. If you want, share: • Your LiveKit project region (or the LIVEKIT_URL), and • GCP region (confirm us-west4), and • Any GCP logs showing availability changes after registration. I’ll use those to confirm if region affinity or availability is the root cause and suggest the next step. Sources: Deploying to custom environments | LiveKit docs | Diagnosing Connection Errors with Connection Test Utility | Agent dispatch | LiveKit docs | Deploying to production | LiveKit Docs

this is the livekit url

<wss://cloudx-demo-re02a3bf.livekit.cloud>

. Where can I check the region of my livekit cloud?

You can determine your LiveKit Cloud project region from the project URL you shared. • Your URL:

<wss://cloudx-demo-re02a3bf.livekit.cloud>

— the

re02a3bf

portion indicates the project is in the US East B region. Ways to confirm: • Project page in the LiveKit Cloud dashboard (Project Settings shows region and server URL). • LiveKit CLI:

lk project list

to view configured projects and their URLs. Next checks to resolve dispatch issues: • Confirm your GCP instance region (you said us-west4) — if it differs from US East B, region affinity may route jobs elsewhere. • Ensure

LIVEKIT_URL

, API key and secret used by the worker match that project. • Check GCP worker logs for any availability transitions (e.g., marked unavailable due to load) after registration. If you want, share the GCP region and a redacted copy of the token/room creation code and I’ll check dispatch alignment. Sources: SIP cloud and region pinning | LiveKit docs | LiveKit CLI project management | LiveKit docs | Deploying to production | LiveKit Docs