Thanks — I can help with that. You're asking how to update the environment variable(s) of a deployed Node.js agent. The easiest way is to use the CLI command that updates secrets for an agent and restarts it so the new values take effect. Use the following command:

lk agent update-secrets --secrets KEY=VALUE --overwrite

Example (replace with your real key/value):

lk agent update-secrets --secrets OPENAI_API_KEY=sk-newvalue123 --overwrite

Notes and options: • --secrets: Provide one or more

KEY=VALUE

pairs. For multiple pairs, separate them with commas. • --secrets-file: You can instead supply a file with

KEY=VALUE

lines. • --overwrite: Required to confirm you want to replace existing secret values. • --id: Use this if you have multiple agents and need to target a specific agent. If omitted, the agent ID may be read from your

livekit.toml

. Behavior: • The new values are injected securely into the agent container at runtime and the agent is restarted so the updated environment variables take effect. • Do not supply

LIVEKIT_API_KEY

,

LIVEKIT_API_SECRET

, or

LIVEKIT_URL

manually — those are injected automatically by LiveKit Cloud. If you’d like, tell me: • Which variable(s) you want to update (names only), and • Whether you have multiple agents (so I can show the

--id

usage or a secrets-file example). Sources: Agents Framework | livekit/livekit_composite | DeepWiki | Server-side | livekit/livekit_composite | DeepWiki

Thanks — I’m responding to your two questions: whether you can update a deployed Node.js agent’s env vars via the LiveKit Cloud web UI, and how to list the variables already present. Short answers • Yes — you can add, edit, or delete environment variables (managed as “secrets”) from the LiveKit Cloud web dashboard under your project’s Agents section. • You can list the secret names, but secret values are never exposed. Use the CLI

lk agent secrets

to see keys; the dashboard also shows configured secret keys. What you can do in the Cloud dashboard • Open your LiveKit project, go to Agents → select the agent → Secrets (or similar) to add/edit/delete secrets. • Changes are injected into the agent container and the agent is restarted so the new values take effect. • Secrets set in the dashboard behave the same as those passed via

--secrets

or a

--secrets-file

from the CLI and take precedence over local .env files. How to list secrets (keys only) 1. Via CLI:

lk agent secrets --id your-agent-id

• This lists the secret names (keys). Values are hidden for security. 1. Via the web UI: ◦ The dashboard displays configured secret names for the selected agent (values are not shown). Important security notes • Secret values are never displayed in UI/CLI outputs or logs. •

LIVEKIT_API_KEY

,

LIVEKIT_API_SECRET

, and

LIVEKIT_URL

are auto-injected by LiveKit Cloud and are filtered from user-provided secret listings (they won’t appear in your secret list). If you’d like, tell me: • The variable name(s) you want to update and whether you prefer using the web UI or CLI, and I’ll give exact step-by-step instructions for that path (or an example

--secrets-file

format). Sources: Agent deployment overview | LiveKit Documentation | Examples | livekit/livekit_composite | DeepWiki | Agents (Python) | livekit/livekit_composite | DeepWiki | Agents Framework | livekit/livekit_composite | DeepWiki

Thanks — I’m responding to both parts: whether you can rename a deployed Node.js agent, and whether agent names must start with "CA_". Short answer • You cannot rename an agent in-place. To change the agent name you must update the agent’s

agentName

and redeploy it as a new agent. • No — agent names do not need to start with

CA_

. There’s no required prefix; use any string you prefer. How to "rename" (recommended steps) 1. Update your agent code to set the new

agentName

(for Node.js this is the

agentName

in

WorkerOptions

or equivalent). 2. Deploy the agent as a new instance: ◦ Use

lk agent deploy

(or the Cloud dashboard deployment flow) to create the new agent. 1. Update anything that referenced the old name: ◦ Change dispatch rules, tokens, or frontend logic that routed to the old

agentName

. 1. Verify the new agent is working, then remove the old deployment if you no longer need it. Notes • The rename requires redeployment because

agentName

is used as the agent identifier for explicit dispatch and cannot be changed on an existing deployment. •

LIVEKIT_API_KEY

,

LIVEKIT_API_SECRET

, and

LIVEKIT_URL

are auto-injected and unrelated to the agent name. If you’d like, tell me: • Whether you prefer step-by-step instructions for redeploying via the CLI or the Cloud dashboard, and • The current agent name and the new name you want — I’ll provide exact commands and the list of places you’ll likely need to update. Sources: Agent dispatch | LiveKit Documentation

Thanks — I’m responding to your question about viewing the error details for your agent that shows status = “error.” You can view the error using either the LiveKit Cloud web dashboard or the

lk

CLI. Both show logs and status details that will tell you what failed. Web dashboard (quick visual): • Open the LiveKit Cloud dashboard and go to your Project → Agents. • Click the agent that shows the error. • Open the Logs tab to stream runtime logs and see error messages. • Also check the agent’s status/details panel — it often shows a short error summary or link to the failing deployment/version. CLI (useful for build vs runtime errors): 1. List agent status (shows current state and any error summary):

lk agent status --id <your-agent-id>

1. View runtime/deploy logs (common for start/runtime errors):

lk agent logs --id <your-agent-id> --log-type=deploy

1. View build logs (if the error happened during build/deploy):

lk agent logs --id <your-agent-id> --log-type=build

Notes and tips • Logs will show stack traces, missing secret notices, dependency errors, or runtime exceptions — that’s the place to look first. • Make sure your CLI is authenticated (your environment or config contains the project credentials) so

lk

can access your agent. • If you’re using Agent Observability, check the Agent insights / Trace views in the dashboard for correlated traces that help pinpoint where the error occurred. If you want, tell me: • Your agent ID (or paste the exact short error/summary you see in the dashboard), and • Whether the error occurred during build or after the agent started. I’ll walk you through reading the relevant logs and point out likely causes based on the log output. Sources: Agents Framework | livekit/livekit_composite | DeepWiki | Agent deployment overview | LiveKit Documentation | Streamline troubleshooting with Agent Observability | Server-side | livekit/livekit_composite | DeepWiki | Examples | livekit/livekit_composite | DeepWiki

You’re asking how to restart a deployed Node.js agent and how to terminate the agent’s concurrent sessions. Below are the practical options depending on whether you’re using LiveKit Cloud (web UI) or the CLI / programmatic approach. Tell me which environment you’re using (Cloud vs self-hosted) and whether you want to end sessions selectively or all at once, and I’ll give exact commands/steps. Restart the agent • LiveKit Cloud dashboard: ◦ Project → Agents → select the agent → click Restart. This performs a rolling restart of the agent instances and applies the current deployment. • CLI: ◦ Run:

lk agent restart --id <agent-id>

• This gracefully restarts the agent instances (honors drain behavior) and brings up new instances with the same version. Kill or end concurrent sessions • Quick note: there is no single CLI button that force-kills individual agent sessions. Use one of these approaches depending on how forceful you need to be: 1) Graceful drain and restart (recommended) • Use the restart above. The agent will enter a draining state: it stops accepting new sessions and lets active sessions finish or time out according to the drain timeout. • Ensure your agent handles `SIGTERM`/`SIGINT` and calls

session.shutdown()

so sessions close promptly. 2) Force-end all sessions in a room (immediate) • Delete the room to end every participant/session in it: ◦ Programmatically via Room Service API (server SDK):

// example (Node)
       const { RoomServiceClient } = require("livekit-server-sdk");
       const client = new RoomServiceClient(process.env.LIVEKIT_URL, process.env.LIVEKIT_API_KEY, process.env.LIVEKIT_API_SECRET);
       await client.deleteRoom(roomName);

• Deleting the room immediately disconnects all participants, including agents connected to that room. 3) End a session from inside the agent • From agent code you can call

ctx.shutdown()

or

session.shutdown()

to end the agent’s job for a session. • You can expose an admin RPC or HTTP endpoint in the agent to trigger this remotely if you need operational control. 4) Shorten drain timeout (self-hosted) • If self-hosted, reduce the configured

drain_timeout

so restarts terminate sessions faster. Ensure agent code gracefully reacts to termination signals. Other options • Rollback to a previous version (CLI) will restart instances using that version:

lk agent rollback --id <agent-id> --version <version-number>

• In the Cloud dashboard you can view Active Jobs / Versions and stop or restart the agent pool from the agent details page. If you want, tell me: • Are you on LiveKit Cloud or self-hosted? • Do you want to end all sessions globally, kill sessions in a specific room, or terminate a specific agent job? • Share the agent ID or room name (names only) and I’ll provide the exact CLI commands or dashboard clicks for your case. Sources: Agents telephony integration | LiveKit Documentation | Server options | LiveKit Documentation | Self-hosted deployments | LiveKit Documentation

You’re asking how to increase the memory warning limit shown in your agent logs (example:

"memoryUsageMB":504.39,"memoryWarnMB":500,... "process memory usage is high"

). Short answer: you cannot change that built-in warning threshold from the agent runtime or dashboard. It’s an internal diagnostic threshold and not exposed as a configurable option. What you can do instead • Monitor & optimize memory: ◦ Identify which plugins or operations use the most memory (VAD, TTS, large model loads) and prewarm/shared-load resources where possible. ◦ Reduce per-session memory by unloading or closing large resources when not needed. ◦ Add in-process checks using

process.memoryUsage()

and take action (log, prevent new sessions, or call

session.shutdown()

). • Scale horizontally: ◦ Add more agent instances so each handles fewer concurrent jobs rather than pushing one process’ memory higher. ◦ Use orchestration (Kubernetes/auto-scaling) to spin up more agents when memory or load increases. • Increase host/container memory (self-hosted): ◦ Give the VM/container more RAM so the process has more headroom. This won’t change the warning threshold, but it reduces the chance of actual OOMs. ◦ For production, consider instance sizes recommended for your expected concurrency. • Implement custom monitoring or suppress noisy alerts: ◦ Build your own memory thresholds and alerts in the agent using

process.memoryUsage()

and your observability stack. ◦ Filter or suppress the specific log message at your log aggregation layer if it’s benign and you want to reduce noise. • Immediate aggressive actions (if you need to free memory now): ◦ Restart the agent to reclaim memory:

lk agent restart --id <agent-id>

(or restart via the Cloud dashboard). ◦ Delete the room(s) hosting active sessions to force disconnects if you need to clear sessions immediately. Notes • The built-in

memoryWarnMB

(seen as 500 MB in your log) is informational—you cannot increase or disable it via an agent option or Cloud setting. • If you’re self-hosting, you can change surrounding infrastructure (more RAM, autoscaling) or add your own runtime checks; but the agent’s internal threshold itself is not configurable. If you like, tell me: • Are you on LiveKit Cloud or self-hosted? • Which plugins or workloads the agent runs (VAD, STT, large LLMs, TTS)? • Do you want step-by-step help to add custom memory checks, scale agents, or restart/replace the agent now? I’ll provide exact commands and guidance based on your environment. Sources: Server options | LiveKit Documentation | Self-hosted deployments | LiveKit Documentation | Silero VAD plugin | LiveKit Documentation

Thanks — I see your agent is running VAD, Deepgram STT, Azure OpenAI LLM, and ElevenLabs TTS. That mix can be memory intensive, so let’s focus on practical steps you can take now to reduce memory pressure, avoid frequent memory warnings, and keep the agent stable. Immediate actions (fast wins) • Restart the agent to reclaim memory now: ◦ CLI:

lk agent restart --id <agent-id>

◦ Cloud: Project → Agents → select agent → Restart • If you need to free memory immediately for active calls, delete the room(s) hosting the agent to drop all participants: ◦ Use the Room Service API to

deleteRoom(roomName)

. Investigate what’s using memory • Check agent logs for errors or signs of repeated model loads: ◦ Deploy logs:

lk agent logs --id <agent-id> --log-type=deploy

◦ Runtime logs:

lk agent logs --id <agent-id> --log-type=deploy

(runtime view) • Add runtime memory sampling in your agent to see peaks:

setInterval(() => {
    const mb = process.memoryUsage().rss / 1024 / 1024;
    console.log(`rssMB=${mb.toFixed(2)}`);
  }, 15000);

This shows whether memory rises steadily per session or spikes on specific actions (like loading TTS or LLM responses). Optimization recommendations for your stack • Prewarm/shared-loading resources ◦ Load STT/LLM/TTS clients and large models once per process rather than per session. ◦ Use a

prewarm

step to initialize Deepgram, Azure OpenAI clients, and the ElevenLabs TTS engine when the agent starts so requests reuse warmed resources. • Avoid per-session model reloads ◦ Ensure you’re not re-creating large client/model objects inside session handlers. Create singletons that are reused across sessions. • Limit concurrency per process ◦ If a single process handles many simultaneous sessions, reduce per-process concurrency. Let each agent process handle fewer simultaneous jobs to lower peak memory. • Stream rather than buffer ◦ For audio and responses, stream data where possible to avoid large in-memory buffers. • Release unused objects ◦ Explicitly null out big buffers/objects after use so GC can reclaim memory sooner. • Tune SDK plugin behavior ◦ If any plugin (VAD/STT/TTS) has configuration for buffer sizes, sample rates, or batching, lower those to reduce memory use. Scaling and infra options • Scale horizontally ◦ Run more agent instances so each process takes fewer concurrent sessions. ◦ Use autoscaling based on memory metrics (Kubernetes HPA with a custom metric or your cloud provider autoscaler). • Increase host RAM ◦ Give your container/VM more memory. This won’t change the 500MB warning threshold but reduces OOM risk and provides headroom for LLM/TTS usage. • Use smaller worker sizes for heavy tasks ◦ If possible move heavy LLM/TTS work to a separate worker type (dedicated to LLM/TTS) so standard agents remain lightweight. Observability and alerting • Create custom alerts on your memory metric (RSS) and use your own thresholds. The internal

memoryWarnMB=500

is informational and cannot be changed. • Filter or suppress the built-in “process memory usage is high” alerts in your log aggregator if they’re noisy, and rely on your own alarm rules tied to RSS or OOM events. Code-level patterns you can apply • Singleton service initialization: ◦ Initialize Deepgram/LLM/TTS clients at module scope or in an agent-wide

prewarm

so each session reuses the same clients. • Graceful shutdown handling: ◦ Handle `SIGTERM`/`SIGINT` to close/cleanup heavy resources to avoid leaks across restarts. • Explicit resource cleanup: ◦ After a session ends, call cleanup on any SDK objects that hold native resources and set large references to

null

. If you want, I can: • Review specific log snippets showing memory growth and point to the exact cause. • Suggest exact code changes to prewarm and share client instances in your Node.js agent. • Provide a sample agent pattern that prewarms Deepgram, Azure OpenAI client, and ElevenLabs TTS and safely reuses them across sessions. Which of these would help most right now — do you want logs reviewed, a prewarm example, or commands to scale/restart the agent?

Thanks — you’re running on LiveKit Cloud with VAD, Deepgram STT, Azure OpenAI LLM, and ElevenLabs TTS. I’ll focus on practical steps you can take in Cloud to address the memory warning and keep your agent healthy. Quick recap of the situation • The log shows memoryUsageMB ≈ 504 with memoryWarnMB = 500. That warning is informational from the LiveKit agent runtime and cannot be reconfigured on LiveKit Cloud. • Because you’re on LiveKit Cloud, you cannot change the internal memoryWarnMB threshold — instead, focus on reducing per-process memory, scaling, or restarting to reclaim memory. Immediate actions you can take (LiveKit Cloud) • Restart the agent (reclaims memory immediately): ◦ Dashboard: Project → Agents → select agent → Restart. ◦ CLI:

lk agent restart --id <agent-id>

• If the agent is in error state, view logs first to find root cause: ◦ Dashboard agent → Logs tab. ◦ CLI:

lk agent logs --id <agent-id> --log-type=deploy

and

--log-type=build

. Optimize memory use for your specific stack • Prewarm/shared-load heavy models or libs once per process: ◦ Ensure LLM client initialization, TTS models, and Deepgram connectors are created at process start and reused rather than recreated per session. • Avoid loading full LLM/TTS model artifacts in every session: ◦ Use lightweight client libraries to call Azure OpenAI and ElevenLabs rather than hosting heavy local models in-process. • For Deepgram STT, prefer streaming connections and reuse the same STT client across sessions. • Release large objects after use: ◦ Null out large buffers, close streams, and call any SDK-specific cleanup APIs after a session ends. • Implement a prewarm pattern if not already used so shared resources are not duplicated per session. Monitoring & custom alerts (since you can’t change the built-in threshold) • Add a small in-agent monitor to alert or take action earlier/later than the built-in warning:

setInterval(() => {
    const rssMB = process.memoryUsage().rss / 1024 / 1024;
    if (rssMB > 800) {
      // custom alert, or trigger graceful shutdown for new sessions
      console.warn(`Custom memory alert: ${rssMB.toFixed(2)} MB`);
    }
  }, 30000);

• Send these metrics to your observability (CloudWatch/Datadog) and create alerts based on thresholds you control. Scaling and capacity strategies (recommended for Cloud) • Scale horizontally: run more agent instances so each handles fewer concurrent sessions — this prevents any single process from hitting high memory. • Use smaller per-session resource footprints: prefer cloud-hosted inference (Azure OpenAI, ElevenLabs) rather than loading models in-process. • If a particular feature (e.g., TTS or an LLM call) spikes memory, consider routing that workload to a dedicated agent type with higher capacity or lower concurrency. If you need immediate memory relief • Restart the agent (see above). • If specific rooms are causing spikes, delete those rooms to drop all participants: ◦ Programmatically via RoomService (server SDK) or delete via the dashboard Rooms view. Next steps I can help with • Walk you through exact dashboard clicks or

lk

commands to restart and inspect logs now. • Provide a short audit checklist for your agent code (places to prewarm, clean up, or reuse clients). • Draft a small in-agent memory-monitor snippet to trigger safe behavior (e.g., stop accepting new sessions, call

session.shutdown()

). • Recommend how to split workloads (e.g., route TTS-heavy jobs to a separate agent pool). Which of these do you want to do next? If you want immediate help, share whether you’d like: • Step-by-step restart + log inspection (I’ll give exact commands/steps), or • A code checklist/snippets to reduce memory for VAD, Deepgram, Azure OpenAI, and ElevenLabs usage.

You’re asking how to list and kill agent sessions using the CLI. Short answer: the CLI does not list or kill agent sessions directly. Agent sessions run inside rooms, so with the CLI you list rooms and end sessions by deleting the room (or use the Server SDK to remove a specific participant). What you can do with the CLI 1. List active rooms

lk room list

• Use this to find rooms where agents may be active. If you name rooms predictably (or include agent info in the room name), this makes finding agent sessions straightforward. 1. Delete a room (terminates all participants, including the agent)

lk room delete --room <room-name>

• Deleting the room immediately disconnects everyone in that room and ends the agent session. Limitations of the CLI • There is no CLI command that directly lists agent sessions or participant identities for agents. • There is no CLI command to remove a single agent participant; you can only delete the whole room via CLI. If you need finer control (recommended for selective termination) • Use the Server SDK (Node/Python) to inspect room participants and remove a specific agent participant by identity: ◦ Example approach: call RoomService to get participant list, then call removeParticipant(roomName, participantIdentity) or delete the room for full termination. • You can also implement an admin RPC/HTTP endpoint in your agent to trigger

ctx.shutdown()

for a specific job. If you want, I can: • Provide the exact Server SDK code snippet to list participants and remove an agent participant, or • Help you find the correct room(s) from

lk room list

if you share your room-naming pattern or agent ID (names only). Which would you prefer?

Thanks — you shared the agent logs and said the agent starts and registers but you can’t connect (it works locally). I’m responding to that: the agent is registering with Cloud but shows repeated memory warnings (~528–551 MB) which likely prevents it from receiving jobs/connections. What the logs show • The agent started, is listening on port 8081, and registered with LiveKit Cloud (so startup and registration succeeded). • The agent repeatedly logs: "process memory usage is high" with memoryUsageMB ≈ 528–551 and memoryWarnMB = 500. • Cloud does not accept custom load thresholds, and LiveKit Cloud will avoid dispatching new jobs to agents that exceed internal resource thresholds. Why that causes connection problems • Even though the process is running, LiveKit Cloud’s scheduler uses resource metrics (memory/CPU) to decide which agents are available. Sustained memory above the warning threshold causes the agent to be excluded from job dispatch, so the agent appears unable to accept connections in production even though it registered successfully. Concrete steps to diagnose & fix 1. Check agent logs for post-registration errors ◦ Inspect logs after the "registered worker" message for any errors related to joining rooms, permissions, or publishing. ◦ CLI command:

lk agent logs --id <agent-id>

(look at both deploy/runtime output). 1. Reduce per-process memory so Cloud marks the agent available ◦ Prewarm and reuse heavy resources (LLM clients, TTS/ STT connectors) instead of loading per session. ◦ Avoid creating large buffers/objects per-session. Release references (null large variables) after use. ◦ If you’re loading any model artifacts locally, switch to remote inference (Azure OpenAI / ElevenLabs) to reduce RAM. 1. Test a minimal agent in Cloud ◦ Deploy a stripped-down version (no LLM/TTS/STT) to confirm that with lower memory the agent becomes dispatchable. This isolates whether the workload is the cause. 1. Verify environment / permissions ◦ Ensure required secrets are injected (LIVEKIT_API_KEY, LIVEKIT_API_SECRET, LIVEKIT_URL) — these are auto-injected on Cloud but confirm any other secrets (API keys for Deepgram, ElevenLabs, Azure) are present. ◦ Confirm agent permissions (publish/subscribe) in code if you override them. 1. Restart to reclaim memory ◦ Quick recovery: restart the agent to free memory and allow a fresh start: ▪︎ Dashboard: Project → Agents → select agent → Restart ▪︎ CLI:

lk agent restart --id <agent-id>

1. If a room needs to be terminated immediately ◦ Delete the room to drop all participants including the agent: ▪︎ CLI:

lk room delete --room <room-name>

(this ends the agent session in that room) 1. Add custom memory monitoring (optional) ◦ Implement a small in-agent check with

process.memoryUsage()

to log and optionally refuse new jobs earlier or call

session.shutdown()

before Cloud marks the agent overloaded. What I need from you to continue troubleshooting • Do you see any client-side connection error messages (ConnectionError or similar)? If so, paste the exact error text. • Confirm whether you’re on LiveKit Cloud (you are) and share: ◦ Agent ID (names only), and ◦ Whether your agent loads any large models or opens heavy media pipelines at startup (VAD, STT, TTS, LLM). • If you want, I can give a short checklist of likely memory hotspots in your code (prewarm patterns, places to release references) or step-by-step CLI/dashboard commands to inspect logs and restart. If you prefer, tell me “restart + show logs” and I’ll give the exact commands to run now and which log lines to paste back so I can point at the most likely culprit. Sources: Self-hosted deployments | LiveKit Documentation | Server options | LiveKit Documentation | Diagnosing Connection Errors with the Connection Test Utility | LiveKit