how to connect to a room with cli which worker is running in local ?

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

worker is running in my pc, and I want to connect to a room and trigger this worker’s entrypoint

I'd be happy to guide you through connecting to a room and triggering a worker's entrypoint running locally. Just follow these steps: 1. Define the Entrypoint Function: This

entrypoint

function is where your agent’s main logic lives. Inside it, make sure to explicitly call

ctx.connect()

to join the room. Here's a simple example:

async def entrypoint(ctx: JobContext):
    await ctx.connect(auto_subscribe=AutoSubscribe.SUBSCRIBE_ALL)
    <http://logger.info|logger.info>(f"Connected to room {ctx.room.name}")

2. Configure WorkerOptions: Next, create an instance of

WorkerOptions

and pass your

entrypoint

function as the

entrypoint_fnc

parameter. For example:

if __name__ == "__main__":
    cli.run_app(WorkerOptions(entrypoint_fnc=entrypoint, worker_type=WorkerType.ROOM))

3. Start the Worker Locally: Use

cli.run_app()

to launch your worker application. Just a quick reminder to have your LiveKit server URL, API key, and secret set as environment variables to keep things secure. 4. Connect to the Room: Finally, use the LiveKit CLI to connect to the room you want to test. For example:

livekit-agent connect --room my-room --participant-identity my-participant

This setup will make sure your worker joins the room smoothly and handles jobs effectively. If you run into any questions or need a hand with anything else, please don’t hesitate to ask—I’m here to help! Sources: Worker options | LiveKit Docs | Anatomy of an Agent | LiveKit Docs | Job lifecycle | LiveKit Docs | OpenAI and LiveKit partner to turn Advanced Voice into an API | examples/primitives/participant_entrypoint.py

ok I am connecting to room but entrypoint is not triggered

I'm here to help you understand why the entrypoint function in LiveKit might not be triggered as expected. Remember, this function is called when a job is assigned to the worker—not just when connecting to a room. Let's walk through some common reasons this might happen and how you can fix them: 1. Worker Registration: First, please double-check that your worker is properly registered with the LiveKit server. It's important that your

LIVEKIT_API_KEY

,

LIVEKIT_API_SECRET

, and

LIVEKIT_URL

environment variables are all set correctly. 2. Job Dispatch: The entrypoint triggers when a job is dispatched to the worker. Make sure the

worker_type

in your

WorkerOptions

matches what you need (like

WorkerType.ROOM

). 3. Request Handling: If you’ve defined a

request_fnc

, please ensure it explicitly accepts the job by calling

await req.accept()

. If you haven’t defined one, don’t worry—jobs are automatically accepted by default. 4. Agent Dispatch: When using

agent_name

in

WorkerOptions

, confirm that the participant’s token includes the same

agent_name

. Alternatively, you can assign the job explicitly using the

createDispatch

API. 5. Worker Capacity: It’s a good idea to check if your worker might be overloaded or at full capacity. If needed, adjusting the

load_threshold

or

load_fnc

can help balance things out. 6. Entrypoint Configuration: Lastly, verify that your entrypoint function is correctly passed to

WorkerOptions

as

entrypoint_fnc

. One more important tip: make sure your entrypoint function explicitly calls

ctx.connect()

to join the room. Without this, even if the entrypoint triggers, the agent won’t appear in the room. To get a clearer picture, check your worker logs for messages like "starting entrypoint" or "connecting to room." If you run into any difficulties or want me to walk through any of these steps, just let me know—I’m here to help! Sources: livekit-agents/livekit/agents/worker.py | Anatomy of an Agent | LiveKit Docs | Worker options | LiveKit Docs | Job lifecycle | LiveKit Docs | Building an Automated IVR Menu Caller | LiveKit Docs

If job dispatch isn’t working as expected, let’s walk through some key areas together to help you get it sorted: 1. Agent Name Configuration: Double-check that the

agent_name

in

WorkerOptions

exactly matches the

agent_name

in your

RoomAgentDispatch

rule. Even a small mismatch can stop jobs from being assigned. 2. Request Handling: If you’re using a

request_fnc

, make sure it explicitly calls

req.accept()

. Without this, the job won’t be assigned. If you haven’t defined a

request_fnc

, don’t worry—jobs are accepted automatically by default. 3. Environment Variables: It’s important to verify that

LIVEKIT_API_KEY

,

LIVEKIT_API_SECRET

, and

LIVEKIT_URL

(or

ws_url

in

WorkerOptions

) are all set correctly. Missing or incorrect values here can prevent your worker from registering properly with the LiveKit server. 4. Entrypoint Logic: Make sure your entrypoint function calls either

ctx.connect()

or

ctx.shutdown()

. If neither is called within 10 seconds, you might see a warning from JobContext, and the job could get stuck. 5. Worker Load: Check if your worker might be overloaded. The default load threshold in production is 0.7, and exceeding this will stop new jobs from being dispatched. You can adjust the

load_threshold

or consider scaling your worker capacity if needed. It’s also a great idea to peek at your worker logs for any warnings or errors during startup and job assignment. If you’re still running into trouble after these checks, please don’t hesitate to reach out—I’m here to help you get this working smoothly! Sources: livekit-agents/livekit/agents/ipc/job_proc_executor.py | Getting Help | livekit/livekit_composite | DeepWiki | SIP troubleshooting guide | LiveKit Docs | Worker options | LiveKit Docs | Anatomy of an Agent | LiveKit Docs