# Cloud Agent Concurrency Failover
**URL:** https://community.livekit.io/t/cloud-agent-concurrency-failover/1064
**Category:** Agents
**Tags:** agent-development, agent-deployment, livekit-cloud
**Created:** [May 8, 2026, 6:52pm UTC](https://community.livekit.io/t/cloud-agent-concurrency-failover/1064 "2026-05-08T18:52:15Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@Andrew\_Hilton](https://community.livekit.io/u/Andrew_Hilton)
#### Post date: [May 8, 2026, 6:52pm UTC](https://community.livekit.io/t/cloud-agent-concurrency-failover/1064/1 "2026-05-08T18:52:15Z")
I am taking a hybrid managed and self-hosted autoscaling approach for the agents in my app, I am curious about the max concurrency behavior on the cloud managed agents when interacting with self-hosted agents. I understand that livekit load-balances participant requests to available workers, what if a Ship tier worker reaches its max concurrent calls of 20, is it taken out of the pool or will a routed request result in an error for the user?
---
### Author:  [@Muhammad\_Usman\_Bashir](https://community.livekit.io/u/Muhammad_Usman_Bashir)
#### Post date: [May 9, 2026, 12:17am UTC](https://community.livekit.io/t/cloud-agent-concurrency-failover/1064/2 "2026-05-09T00:17:05Z")
On the OSS side, the dispatch is clean: workers self-report `load_fnc` against `load_threshold` (`prod default 0.7`) and flip to `WorkerStatus.WS_FULL` via `UpdateWorkerStatus` when they cross it. `WS_FULL` workers drop out of the dispatch pool; jobs route to other available workers. If everything’s full, jobs queue server-side rather than erroring (cf. [Issue: Jobs keep enqueued, even for empty rooms · Issue #1024 · livekit/agents · GitHub](https://github.com/livekit/agents/issues/1024)).
What’s not publicly verifiable: whether Ship-tier’s “20 concurrent calls” is enforced via that same flip (likely, same framework) or as a hard reject at exactly `20`. In the soft case, self-hosted workers under the same `agent_name` absorb overflow naturally. In the hard case, self-host has to be an explicit fallback. Worth a quick controlled ramp test, or @CWilson can confirm in a line.
Cc: @Andrew_Hilton