I created an agent and I want to deploy on scale. How many rooms can the agent join at the same time? Of course with independent conversations

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

Are there limits on the API of livekit outside the server?

Thanks — I’m responding to your question about whether there are limits on LiveKit’s APIs outside of server-side resource constraints. Short answer • Yes. LiveKit enforces usage limits beyond what your own servers can handle. These are mainly plan-based quotas and concurrency caps on the managed LiveKit Cloud services (inference, agent sessions, WebRTC connections, telephony, etc.). Self‑hosted deployments do not have those managed-service limits. Key limits to know • Inference concurrency (LLM/STT/TTS): hard caps by plan ◦ Build: 5 concurrent inference sessions ◦ Ship: 20 concurrent inference sessions ◦ Scale: 50 concurrent inference sessions ◦ Enterprise: custom concurrency (higher limits available) ◦ Note: inference concurrency on self‑serve plans is a hard cap. • Agent session concurrency (concurrent agent sessions allowed) ◦ Build: 5 ◦ Ship: 20 ◦ Scale: up to 600 (Enterprise can be custom) • WebRTC concurrent connections ◦ Build: 100 ◦ Ship: 1,000 ◦ Scale: 5,000 • Telephony and SIP / phone number limits ◦ Telephony minutes, number pools, and trunk usage have caps; some can be increased through account changes. When these limits apply vs self-hosting • These plan-based quotas apply when using LiveKit Cloud managed services. • If you self-host LiveKit and the agent services, the managed-service quotas (inference concurrency, cloud connection caps) do not apply — capacity is determined by your own infrastructure. What I can help with next • If you want, tell me which plan you’re on (Build / Ship / Scale / Enterprise) and the features you rely on (inference, telephony, WebRTC peers). I can: a. Translate your target concurrency into the plan limits you’ll hit. b. Suggest scaling options (add instances, multi‑tenant agents, or move to self‑host/Enterprise). c. Recommend a test plan to measure real concurrency for your agent workload. Which option would you like to go with? Sources: How much can LiveKit scale? | LiveKit | Pricing | LiveKit

What command do I have to run to create a sample of agent in linux after authentication

Thanks — I’m responding to your question about the exact command to run on Linux to create a sample agent after you’ve authenticated. If you’ve already authenticated with LiveKit Cloud (for example via

lk cloud auth

or by exporting

LIVEKIT_API_KEY

,

LIVEKIT_API_SECRET

, and

LIVEKIT_URL

), run this from your project root:

lk agent create

What this does • Packages your agent code, builds a Docker container, and creates a sample agent entry in LiveKit Cloud. • Generates a

livekit.toml

file with agent metadata so later commands (like

lk agent deploy

) can reference the same agent. Notes and tips • Ensure the project contains an agent entrypoint (e.g.,

agent.py

or

agent.ts

) before running the command. • If you prefer CI/CD, you can also create agents from GitHub Actions using the

livekit/deploy-action

with

OPERATION: create

. Would you like the exact steps for authentication first, or help preparing the project structure (example `agent.py`/`agent.ts`) before running

lk agent create

? Sources: examples/drive-thru | livekit/livekit_composite | DeepWiki | Deploy LiveKit Agents with GitHub Actions | LiveKit

wesley@wesley:~/Documents/projects/popai/voice-agent-demo-tagalog$ lk agent create Using default project [tagalog] Creating new agent deployment unable to determine agent language: expected package.json, requirements.txt, pyproject.toml, or lock files, please navigate to a directory containing an agent written in a supported language wesley@wesley:~/Documents/projects/popai/voice-agent-demo-tagalog$

Thanks — I’m responding to the error you hit when running

lk agent create

about the agent language not being detected. Why you saw that error • The CLI looks for a language indicator file in the current directory (one of:

package.json

,

requirements.txt

,

pyproject.toml

, or language lock files). If none are found, it can’t tell which runtime to use and refuses to create the agent. How to fix it (choose the option that matches your project) 1) If your agent is Node.js • Make sure there is a

package.json

in the project root. • If you don’t have one yet, create it quickly:

npm init -y

• Add your entrypoint (e.g.,

agent.js

or

agent.ts

) and ensure

package.json

has a

start

script if needed. 2) If your agent is Python • Ensure

requirements.txt

or

pyproject.toml

exists in the root. • To create a minimal `requirements.txt`:

echo "livekit-client" > requirements.txt

(Replace with the actual Python packages your agent needs.) • Ensure your agent entrypoint (e.g.,

agent.py

) is in the same directory. 3) If you’re using another supported language or a different layout • Put the language file (one of the above) in the directory where you run

lk agent create

. • Alternatively, change to the correct project directory before running the command:

cd /path/to/your/agent/project
  lk agent create

Quick checklist to run before retrying • You’re in the project root:

pwd

• Directory contains either

package.json

,

requirements.txt

, or

pyproject.toml

• Your agent entrypoint file is present (e.g.,

agent.py

,

agent.ts

,

index.js

) • You’re authenticated (you mentioned you already are) If you’d like, I can: • Review the output of

ls -la

from your project root to confirm which files are present. • Suggest a minimal example

agent.py

or

package.json

tailored to your language to get

lk agent create

to succeed. Which language is your agent written in (Node.js or Python)? If you paste

ls -la

from that folder, I’ll point out the exact change you need.

but I remember a command that will create like a project sample, that is what I am looking for. I used it multiple times in empty folders and they worked. I never needed to create anything

Thanks — I’m responding to your memory about a command that scaffolds a sample agent in an empty folder. Run this in an empty directory:

lk agent init

What it does • Scaffolds a complete sample agent project (creates the required files, dependencies, and config) so you don’t need to add package.json, requirements.txt, etc. • You can specify language if you want: ◦ For Python:

lk agent init --lang python

◦ For Node:

lk agent init --lang node

Next steps • After

lk agent init

, you can inspect the files, install dependencies, then authenticate and run: a. Authenticate:

lk cloud auth

(or set

LIVEKIT_API_KEY

,

LIVEKIT_API_SECRET

,

LIVEKIT_URL

) b. Create/deploy:

lk agent create

(or

lk agent deploy

as needed) Would you like me to walk through the workflow for your preferred language (Python or Node) or help you run

lk agent init

step‑by‑step? Sources: Agents (Python) | livekit/livekit_composite | DeepWiki | Agents Framework | livekit/livekit_composite | DeepWiki | Agents (Node.js) | livekit/livekit_composite | DeepWiki

after lk agent deploy I got this error Using project [mil] Using agent [CA_AdgogWD7aohu] error: Failed to spawn:

src/agent.py

Caused by: No such file or directory (os error 2) wesley@wesley:~/Documents/projects/popai/voice-agent-demo-tagalog/tagalog$

Thanks — I’m responding to the error you saw when running

lk agent deploy

that says

Failed to spawn: src/agent.py

(No such file or directory). What that error means • The deploy process expects an agent entrypoint at

src/agent.py

(the default for Python starter projects). It can’t find that file, so the container build/start fails. Quick fixes — pick the one that fits your project 1) If your agent file exists but is elsewhere • Move it into the expected path:

mkdir -p src
  mv path/to/your/agent.py src/agent.py

• Then run

lk agent deploy

from the project root. 2) If your entrypoint has a different name (e.g.,

main.py

) • Rename it or adjust the Docker/CMD to point to the correct file. Easiest is to rename:

mkdir -p src
  mv main.py src/agent.py

• Or update your `Dockerfile`/`livekit.toml` command to spawn the correct file (if you have a custom Dockerfile). 3) If you used

lk agent init

or a starter template and files are missing • Re-run

lk agent init --lang python

(or

--lang node

) in an empty folder to scaffold the sample project. • Then authenticate and run

lk agent create

/

lk agent deploy

. Checklist to verify before re-deploying • You are in the project root where

livekit.toml

is located. •

src/agent.py

exists for Python agents (or the appropriate entrypoint for Node). •

livekit.toml

/

Dockerfile

align with your entrypoint. If you want, I can help directly — please paste the output of these commands from your project folder: 1. pwd 2. ls -la 3. tree -a (if available) Or simply paste

ls -la

of the current directory and the

src

folder (if it exists), and I’ll point out the exact change to make. Sources: Agents (Python) | livekit/livekit_composite | DeepWiki | examples/voice_agents | livekit/livekit_composite | DeepWiki | Voice AI quickstart | LiveKit Documentation | Agents (Node.js) | livekit/livekit_composite | DeepWiki

wesley@wesley:~/Documents/projects/popai/voice-agent-demo-tagalog/tagalog$ ls -la total 688 drwxrwxr-x 8 wesley wesley 4096 Mar 11 21:07 . drwxrwxr-x 5 wesley wesley 4096 Mar 11 21:07 .. drwxrwxr-x 3 wesley wesley 4096 Mar 11 21:07 .agents -rw-rw-r-- 1 wesley wesley 4611 Mar 11 21:07 AGENTS.md drwxrwxr-x 3 wesley wesley 4096 Mar 11 21:07 .claude -rw-rw-r-- 1 wesley wesley 185 Mar 11 21:07 CLAUDE.md -rw-rw-r-- 1 wesley wesley 3081 Mar 11 21:07 Dockerfile -rw-rw-r-- 1 wesley wesley 809 Mar 11 21:07 .dockerignore -rw-rw-r-- 1 wesley wesley 50 Mar 11 21:07 .env.example -rwx------ 1 wesley wesley 147 Mar 11 21:07 .env.local -rw-rw-r-- 1 wesley wesley 187 Mar 11 21:07 GEMINI.md drwxrwxr-x 4 wesley wesley 4096 Mar 11 21:07 .github -rw-rw-r-- 1 wesley wesley 431 Mar 11 21:07 .gitignore -rw-rw-r-- 1 wesley wesley 939 Mar 11 21:07 pyproject.toml -rw-rw-r-- 1 wesley wesley 7806 Mar 11 21:07 README.md drwxrwxr-x 3 wesley wesley 4096 Mar 11 21:07 src drwxrwxr-x 2 wesley wesley 4096 Mar 11 21:07 tests -rw-rw-r-- 1 wesley wesley 621693 Mar 11 21:07 uv.lock drwxrwxr-x 6 wesley wesley 4096 Mar 11 21:07 .venv wesley@wesley:~/Documents/projects/popai/voice-agent-demo-tagalog/tagalog$ pwd /home/wesley/Documents/projects/popai/voice-agent-demo-tagalog/tagalog wesley@wesley:~/Documents/projects/popai/voice-agent-demo-tagalog/tagalog$ wesley@wesley:~/Documents/projects/popai/voice-agent-demo-tagalog/tagalog$ cd src/ wesley@wesley:~/Documents/projects/popai/voice-agent-demo-tagalog/tagalog/src$ ls -la total 24 drwxrwxr-x 3 wesley wesley 4096 Mar 11 21:07 . drwxrwxr-x 8 wesley wesley 4096 Mar 11 21:07 .. -rw------- 1 wesley wesley 5248 Mar 11 21:07 agent.py drwxrwxr-x 2 wesley wesley 4096 Mar 11 21:07 agent_starter_python.egg-info -rw-rw-r-- 1 wesley wesley 53 Mar 11 21:07 init.py wesley@wesley:~/Documents/projects/popai/voice-agent-demo-tagalog/tagalog/src$

Thanks — I’m responding to the

Failed to spawn: src/agent.py

error and the directory listing you provided. Good news: your project does contain

src/agent.py

, so the file exists. The error means the deploy process couldn’t execute that file inside the container at runtime. Let’s check the few common causes and fix them. Please run these checks in your project root and share results if something looks off. 1) Verify

agent.py

is executable (permissions) • In the project root run:

ls -l src/agent.py

• If it’s not executable, make it so:

chmod +x src/agent.py

2) Confirm the Dockerfile starts the right file • Open

Dockerfile

and look for the

CMD

or

ENTRYPOINT

that launches the agent. For a Python starter it should reference

src/agent.py

(or the correct path). Example expected form:

CMD ["python", "src/agent.py"]

• If the Dockerfile references a different path or name, update it to

src/agent.py

or adjust to the actual path. 3) Check

livekit.toml

agent command (if present) • Open

livekit.toml

and look for an

entry

or

command

field pointing to the agent entrypoint. Ensure it matches

src/agent.py

. 4) Ensure dependencies are installed in the container • Your pyproject.toml and Dockerfile should install dependencies (pip / uv). If the container build fails to install packages, the spawn step may fail. Rebuild the agent image and watch logs:

lk agent deploy --verbose

Share the build logs if you see errors during package install. 5) Confirm you’re deploying from the project root • You are in the project root (your

pwd

shows the correct path). Good — continue deploying from here. 6) Quick diagnostic: run locally in the same environment • Try running the agent locally to ensure it starts without containerization issues:

python src/agent.py

If that errors, paste the stack trace here. If those checks don’t reveal the issue, please paste: • The

CMD

/

ENTRYPOINT

lines from your

Dockerfile

. • The `command`/`entry` (if any) from

livekit.toml

. • Output of

ls -l src/agent.py

. • The first ~50 lines of the

lk agent deploy --verbose

build log (if available). I’ll use those to pinpoint whether this is a permissions, path, Dockerfile, or build-time dependency problem and give the exact change to fix it.

This is the dockerfile

# syntax=docker/dockerfile:1

# Use the official UV Python base image with Python 3.13 on Debian Bookworm
# UV is a fast Python package manager that provides better performance than pip
# We use the slim variant to keep the image size smaller while still having essential tools
ARG PYTHON_VERSION=3.13
FROM <http://ghcr.io/astral-sh/uv:python${PYTHON_VERSION}-bookworm-slim|ghcr.io/astral-sh/uv:python${PYTHON_VERSION}-bookworm-slim> AS base

# Keeps Python from buffering stdout and stderr to avoid situations where
# the application crashes without emitting any logs due to buffering.
ENV PYTHONUNBUFFERED=1

# --- Build stage ---
# Install dependencies, build native extensions, and prepare the application
FROM base AS build

# Install build dependencies required for Python packages with native extensions
# gcc: C compiler needed for building Python packages with C extensions
# g++: C++ compiler needed for building Python packages with C++ extensions
# python3-dev: Python development headers needed for compilation
# We clean up the apt cache after installation to keep the image size down
RUN apt-get update && apt-get install -y \
    gcc \
    g++ \
    python3-dev \
  && rm -rf /var/lib/apt/lists/*

# Create a new directory for our application code
# And set it as the working directory
WORKDIR /app

# Copy just the dependency files first, for more efficient layer caching
COPY pyproject.toml uv.lock ./
RUN mkdir -p src

# Install Python dependencies using UV's lock file
# --locked ensures we use exact versions from uv.lock for reproducible builds
# This creates a virtual environment and installs all dependencies
# Ensure your uv.lock file is checked in for consistency across environments
RUN uv sync --locked

# Copy all remaining application files into the container
# This includes source code, configuration files, and dependency specifications
# (Excludes files specified in .dockerignore)
COPY . .

# Pre-download any ML models or files the agent needs
# This ensures the container is ready to run immediately without downloading
# dependencies at runtime, which improves startup time and reliability
RUN uv run "src/agent.py" download-files

# --- Production stage ---
# Build tools (gcc, g++, python3-dev) are not included in the final image
FROM base

# Create a non-privileged user that the app will run under.
# See <https://docs.docker.com/build/building/best-practices/#user>
ARG UID=10001
RUN adduser \
    --disabled-password \
    --gecos "" \
    --home "/app" \
    --shell "/sbin/nologin" \
    --uid "${UID}" \
    appuser

# Copy the application and virtual environment with correct ownership in a single layer
# This avoids expensive recursive chown and excludes build tools from the final image
COPY --from=build --chown=appuser:appuser /app /app

# Switch to the non-privileged user for all subsequent operations
# This improves security by not running as root
USER appuser

# Run the AgentServer using UV
# UV will activate the virtual environment and run the agent.
# The "start" command tells the AgentServer to connect to LiveKit and begin waiting for jobs.
CMD ["uv", "run", "src/agent.py", "start"]

Thanks — I’m responding to the Dockerfile you pasted and the previous “Failed to spawn: src/agent.py” error. Your Dockerfile looks correct in that it expects to run

uv run src/agent.py start

. Since

src/agent.py

exists, the problem is likely one of the common runtime issues below. Follow these checks in order and share any failing output if it doesn’t fix the problem. 1) Ensure agent file is executable and has a valid entrypoint • Make the file executable and add a shebang if missing:

chmod +x src/agent.py
  sed -n '1,5p' src/agent.py

• If the first line isn’t a Python shebang (e.g.

#!/usr/bin/env python3

), add it as the top line. 2) Verify the script runs locally under the project virtualenv • Activate your virtualenv and run the start command the same way the container will:

# from project root
  source .venv/bin/activate
  uv run src/agent.py start

• If this errors, paste the traceback. Fix any missing imports or runtime errors before deploying. 3) Rebuild and watch the full deploy logs • Deploy with verbose logs to see whether build succeeds and the container can spawn:

lk agent deploy --verbose

• Watch for errors during

uv sync

(dependency install), the

RUN uv run "src/agent.py" download-files

step, or at the final

CMD

spawn. Paste the failing section if you need help interpreting it. 4) Confirm dependencies and uv commands exist in build stage • Your Dockerfile runs

uv run "src/agent.py" download-files

during build. If

download-files

is not a valid command implemented in

agent.py

(or it raises an exception), build will fail. Try running that locally:

source .venv/bin/activate
  uv run "src/agent.py" download-files

• If it fails, either implement/guard that command or remove that build-time step. 5) Check file ownership after COPY into final image • You copy /app from build to final and switch to

appuser

. If

src/agent.py

isn’t readable/executable by

appuser

, spawn will fail. Verify permissions in build output or test by running the image locally:

# build image locally to inspect
  docker build -t test-agent .
  docker run --rm -it test-agent ls -l /app/src/agent.py
  docker run --rm -it test-agent uv run src/agent.py start

• If permissions are restrictive, ensure

COPY --from=build --chown=appuser:appuser /app /app

succeeded (your Dockerfile includes this; verify file modes). 6) If using Windows line endings or encoding issues • Ensure Unix line endings:

file src/agent.py
  dos2unix src/agent.py  # if needed

If none of the above surfaces the issue, please paste: • Output of

ls -l src/agent.py

• The result of

uv run src/agent.py start

run locally (paste the error/traceback) • The failing lines from

lk agent deploy --verbose

(or the last ~30 lines of build/deploy logs) I’ll take the logs and point to the exact line to change so your agent spawns correctly in the container.