I cannot connect to my agent deployed on livekit cloud today, it is stuck on current status pending. If trying to check the logs it just says "failed to get logs: The agent has shut down due to inactivity. It will automatically start again when a new session begins."

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

I have a paid plan. This is my agent ID: CA_gRhgg69YXnSQ

Thanks — I see you’re on a paid plan and gave agent ID

CA_gRhgg69YXnSQ

. Let’s narrow this down. Please run these checks and share results (or paste any errors): 1. Confirm agent status: ◦

lk agent status --id CA_gRhgg69YXnSQ

◦ Share the output (replicas, CPU/memory, any error lines). 1. Try forcing a session start: ◦ Open a client that joins the agent’s room (or trigger whatever workflow creates a session). Did the agent transition from pending to running? If not, note any client-side errors. 1. If the agent becomes running, fetch logs: ◦

lk agent logs --id CA_gRhgg69YXnSQ

◦ Paste the most recent error lines (last 50–200 lines). 1. If the agent remains pending after a session start, tell me: ◦ The exact CLI outputs from steps 1 and 3. ◦ Whether you recently changed deployment/replica settings or performed a rollout. I’ll use those outputs to diagnose why cold-start prevention isn’t keeping the agent always-on. , with interactive elements

lk agent status --id CA_gRhgg69YXnSQ Using default project [witney-ai-prod] Using agent [CA_gRhgg69YXnSQ] ┌─────────────────┬──────────────┬─────────┬──────────┬────────────┬─────────┬───────────┬──────────────────────┐ │ ID │ Version │ Region │ Status │ CPU │ Mem │ Replicas │ Deployed At │ ├─────────────────┼──────────────┼─────────┼──────────┼────────────┼─────────┼───────────┼──────────────────────┤ │ CA_gRhgg69YXnSQ │ K6ZKkmvrCmE4 │ us-east │ Sleeping │ 0m / 2000m │ 0 / 4GB │ 0 / 1 / 1 │ 2026-04-30T042415Z │ └─────────────────┴──────────────┴─────────┴──────────┴────────────┴─────────┴───────────┴──────────────────────┘ Starting a session (this was working yesterday and I'm sure that if I redeploy the agent, it would work, but this is not a sustainable way of fixing the issue) This is the getToken code: 'use server' import { ConnectionDetails } from '@/types' import { RoomConfiguration } from '@strong-father-34524/protocol' import { AccessToken } from 'livekit-server-sdk' const API_KEY = process.env.LIVEKIT_API_KEY const API_SECRET = process.env.LIVEKIT_API_SECRET export async function getToken( email: string, mockTestimonyId: string, questionIndex = 0 ): Promise<ConnectionDetails> { if (API_KEY === undefined) { throw new Error('LIVEKIT_API_KEY is not defined') } if (API_SECRET === undefined) { throw new Error('API_SECRET is not defined') } const roomName =

room-for-${email}-${~~(Math.random() * 1000000)}

const participantName = email const participantToken = await getParticipantToken( participantName, roomName, mockTestimonyId, questionIndex ) return { roomName, participantToken, participantName, } } async function getParticipantToken( participantName: string, roomName: string, mockTestimonyId: string, questionIndex: number ) { const at = new AccessToken(API_KEY, API_SECRET, { identity: participantName, // Token to expire after 10 minutes ttl: '10m', }) at.addGrant({ roomJoin: true, room: roomName }) at.roomConfig = new RoomConfiguration({ agents: [ { metadata: JSON.stringify({ mockTestimonyId, questionIndex }), }, ], }) return at.toJwt() } SES Removing unpermitted intrinsics client-DIoW71JT.js:18 publishing track {room: 'room-for-stanislas.duprey+lawyer@proton.me-196453', roomID: 'RM_C2xsiMmhWgbw', participant: 'stanislas.duprey+lawyer@proton.me', pID: 'PA_hsERF2CVbCVs', trackID: undefined, …}enabled: truekind: "audio"muted: falsepID: "PA_hsERF2CVbCVs"participant: "stanislas.duprey+lawyer@proton.me"room: "room-for-stanislas.duprey+lawyer@proton.me-196453"roomID: "RM_C2xsiMmhWgbw"source: "microphone"streamID: "622e6409-0f00-42d5-8c54-4c8f2b71be66"streamTrackID: "622e6409-0f00-42d5-8c54-4c8f2b71be66"trackID: undefined[[Prototype]]: Object client-DIoW71JT.js:18 ✅ Connected to room at 2026-04-30T142135.548Z

Thanks — I’m looking at the Sleeping status and your logs. I’ll help diagnose why cold-start prevention isn’t keeping the agent always-on. Quick summary of what I see: • Agent CA_gRhgg69YXnSQ is on your paid project but shows Status: Sleeping with 0/1 replicas. • Your client successfully connected to a room, so the token flow and client join appear to work. Please run these two commands and paste their outputs so I can pinpoint the cause: 1. Get the full deployment manifest / config: ◦

lk agent get --id CA_gRhgg69YXnSQ

1. Show recent events and replica details: ◦

lk agent status --id CA_gRhgg69YXnSQ --events

◦ If

--events

isn’t supported, run:

lk agent logs --id CA_gRhgg69YXnSQ --lines 200

after you trigger a session start. Also answer these quick questions: • Did you change replicas, autoscaling, or perform a rollout recently? • Is the paid plan definitely Ship/Scale/Enterprise (not Build)? Which plan name is shown in your billing/dashboard? If you prefer, you can scale the agent to force a running replica while we investigate: •

lk agent scale --id CA_gRhgg69YXnSQ --replicas 1

Send the command outputs and answers and I’ll identify why the agent stays sleeping and guide the next steps. , with interactive elements

➜ agent git:(main) ✗ lk agent get --id CA_gRhgg69YXnSQ Incorrect Usage: flag provided but not defined: -id flag provided but not defined: -id ➜ agent git:(main) ✗ lk agent status --id CA_gRhgg69YXnSQ --events Incorrect Usage: flag provided but not defined: -events flag provided but not defined: -events

Thanks — I see the CLI flagged the unsupported flags and your agent still shows Sleeping with 0/1 replicas. Let’s keep this focused and get the exact info I need to diagnose why a paid-plan agent isn’t staying warm. Please run these commands (no unsupported flags) and paste their outputs: 1. Confirm agent status (you already ran this, but paste the full output again if it changes): ◦

lk agent status --id CA_gRhgg69YXnSQ

1. List agents in the project (shows plan/labels and IDs): ◦

lk agent list

1. Fetch recent logs (after you attempt a session start if needed): ◦

lk agent logs --id CA_gRhgg69YXnSQ --lines 200

1. Show agent secrets/config (to check env vars): ◦

lk agent secrets --id CA_gRhgg69YXnSQ

Also answer these quick questions: • Which paid plan is shown on your Cloud billing/dashboard (Ship, Scale, or Enterprise)? • Did you recently change replica/autoscale settings or perform a rollout? If you want to immediately force a running replica while we investigate, run: •

lk agent scale --id CA_gRhgg69YXnSQ --replicas 1

Send the command outputs and answers and I’ll diagnose why cold-start prevention isn’t keeping the agent active. Sources: Deploy and scale agents on LiveKit Cloud | LiveKit | Deployment reliability on LiveKit Cloud | LiveKit | Where to find your Agent Logs | LiveKit | Deploy and scale agents on LiveKit Cloud | LiveKit, with interactive elements

I think I see the issue I am paying $50 a month for a ship plan, but this is only applying to the staging agent CA_c2QBpAyzaHK4, for prod I created another project, to be able to point to prod backend. Maybe my setup is wrong there?

Thanks — that explains it. Ship’s cold-start prevention applies per project, so if your $50/month Ship plan is only on the staging project, agents in your separate production project will still be on Build and will go to Sleeping (cold starts). What I recommend: • Confirm the production project (project name/ID and the API key/secret you use for prod). • Upgrade the production project to Ship (or higher) so cold-start prevention applies there. • After upgrading, confirm the agent shows a running replica with

lk agent status --id CA_gRhgg69YXnSQ

. If you want, share the production project ID and I’ll walk you through verifying the plan and the exact steps to upgrade and validate the agent. Sources: https://livekit.com/pricing.md| | Pricing | LiveKit | Pricing | LiveKit | Understand and Improve Agent Latency | LiveKit | Understand and Improve Agent Latency | LiveKit, with interactive elements

can I add the prod agent to the staging project and avoid the extra cost?

Short answer: yes — but with important trade-offs. Plans (and cold-start prevention) apply per LiveKit project. To avoid paying again, you can deploy the prod agent into the staging project that already has Ship: use the staging project’s API key/secret for the prod agent and redeploy it there. That will give the agent always-on behavior without an extra plan. Please note the trade-offs: • You lose environment isolation: staging and prod agents share the same project, keys, quota, and billing. • Risk of accidental interference between staging and prod (rooms, secrets, usage limits). • You’ll need to update your prod backend to use the staging project’s credentials and reconfigure any project-scoped settings. If you prefer isolation, upgrade the prod project to Ship (or higher) so cold-start prevention applies per project. Which approach do you want to take? If you choose to move prod into the staging project, tell me the prod agent deployment details and I’ll list the exact steps to redeploy safely. , with interactive elements

I want to move the prod agent into the staging project

Great — I’ll walk you through moving the prod agent into the staging project safely. Before you start, gather: • Staging project API key & secret (the project with Ship plan). • Prod agent code/repo and current deployment configuration (Dockerfile, lk agent manifest, env vars). Steps to move prod agent into the staging project 1. Back up current prod config ◦ Save the prod agent manifest, env vars, and any secrets/config files. ◦ Note the prod project’s API key/secret and current agent ID. 1. Prepare staging credentials ◦ Copy the staging project’s API key and API secret into a safe place for the deployment step. ◦ Ensure you have permission to deploy into the staging project. 1. Update agent configuration for staging ◦ In the prod agent’s deployment config, replace the prod API key/secret with the staging project’s API key/secret. ◦ Verify any project-scoped values (webhooks, callbacks, project-specific URLs) are updated if needed. 1. Redeploy the agent into the staging project ◦ From the prod agent repo, run your normal deploy but using staging credentials. Example CLI flow: ▪︎ Build/deploy as you normally do (e.g.,

lk agent deploy

) while the environment uses the staging API key/secret. ◦ Confirm the new agent appears in the staging project with

lk agent list

and note its agent ID. 1. Verify the agent is always-on ◦ Check status:

lk agent status --id <new-agent-id>

— confirm replicas show 1 and Status is Running (cold-start prevention active). ◦ Start a session to ensure the agent responds immediately and fetch logs:

lk agent logs --id <new-agent-id> --lines 200

. 1. Update prod backend to point to the agent in staging ◦ Replace the API key/secret in your prod backend with the staging project credentials you deployed under. ◦ Ensure tokens you mint use the staging API key/secret so clients join the agent deployed in staging. 1. Test end-to-end ◦ Run full prod workflows (token creation, client join, agent behavior) and verify latency and logs are correct. ◦ Monitor for conflicts with staging usage (rooms, naming collisions). 1. Clean up & mitigations ◦ If you want logical separation, prefix prod room names or use distinct room naming conventions to avoid collisions. ◦ Keep backups of the original prod project config in case you revert. ◦ Track usage in the staging project to ensure you don’t exceed quotas. Risks and notes (short) • You’ll lose strict environment isolation: staging and prod share keys, quotas, and logs. • Be careful with secrets and room names to avoid accidental cross-environment interference. If you want, I can: • Provide the exact commands for your repo/deploy flow (tell me how you currently run

lk agent deploy

), or • Draft the minimal env var changes you need to make in your prod backend. Which would you prefer? , with interactive elements

I run

lk agent deploy --config livekit.prod.toml

with the toml being:

[project]
  subdomain = "witney-ai-prod-dstbjmcc"

[agent]
  id = "CA_gRhgg69YXnSQ"

I don't have the answer you're looking for. You could also try asking your question: • in one of the other Slack channels or • to https://deepwiki.com/livekit/livekit_composite which is trained on all LiveKit source code If you find the answer, please post it here to help others!

ok, now that my prod agent is in the same project as my staging agent, I need to update the getToken to have the access token point to the right agent