Is

len(worker.active_jobs)

an accurate way to know how many requests a worker is currently processing?

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

Is there a way to configure

max_concurrent_jobs

?

Thanks — good follow-up. There is no direct

max_concurrent_jobs

setting. You control concurrency by providing a custom

load_fnc

and setting

load_threshold

on your

AgentServer

. For example, to cap at ~9 concurrent jobs:

def compute_load(agent_server: AgentServer) -> float:
    return min(len(agent_server.active_jobs) / 9, 1.0)

server = AgentServer(load_threshold=0.9)
server.load_fnc = compute_load

Note:

load_fnc

and

load_threshold

are configurable only for self-hosted/custom deployments — they cannot be changed in LiveKit Cloud. Would you like help writing a

load_fnc

that fits your exact capacity or deployment setup? Sources: Agent server options | LiveKit docs

Already doing this but for some reason even though the max jobs is set to 10, I can see in metrics that sometimes the active jobs goes upto 25.

active_jobs_cnt = len(worker.active_jobs)

job_load = min(1.0, active_jobs_cnt / MAX_JOBS_PER_WORKER)

return job_load

Threshold is set to 0.7

Thanks — I hear your frustration. You're using a load function and threshold but see spikes up to 25 active jobs even though MAX_JOBS_PER_WORKER is 10. To help diagnose, I need a few details and I'll suggest likely causes and quick checks. Please share: • Are you running a single worker process per host or multiple worker processes/containers on the same host? • Is this self-hosted or LiveKit Cloud? • The exact AgentServer/worker startup code (how/where you set

server.load_fnc

and

load_threshold

). • Any relevant logs around job assignment when the spike occurs (timestamps help). • Whether jobs sometimes block or hang (long-running tasks) and typical job duration. Likely causes and quick checks: • Multiple worker instances: if multiple worker processes/containers share the same host, each has its own

active_jobs

— totals can exceed 10 across instances. • Load evaluation timing:

load_fnc

is consulted when dispatching; concurrent dispatch decisions can race, temporarily allowing more than the intended number before load updates propagate. • Threshold vs hard limit:

load_threshold

prevents further assignments once load > threshold but is not a strict hard cap; spikes above the implied MAX can occur briefly. • Long-running or stuck jobs: if jobs aren't finishing,

active_jobs

will accumulate past the expected steady-state. • Miswired function: ensure

load_fnc

reads

agent_server.active_jobs

(not a different

worker

object) and that

MAX_JOBS_PER_WORKER

value is correct in that context. Immediate actions you can take: • Add logging inside

load_fnc

to record

len(agent_server.active_jobs)

and returned load whenever called. • Log job start/finish with job IDs and timestamps to detect stuck jobs or long tails. • Temporarily reduce

load_threshold

(e.g., to 0.5) to lower the effective concurrency while you investigate. • If you need a strict cap, enforce a guard inside job-acceptance code: reject new jobs when

len(worker.active_jobs) >= MAX_JOBS_PER_WORKER

. If you share the startup snippet and any logs around a spike, I’ll review them and point out what to change.