I'm using a python server with livekit. Sometimes It throws the next warning: {"message": "input speech hasn't started yet, skipping silence padding, recording may be inaccurate until the speech starts", "level": "WARNING", "name": "livekit.agents", "room": "voice_assistant_room_3658", "pid": 57698, "job_id": "AJ_FBBRUZPeW2Qw", "room_id": "RM_yLjLHdCKnDTL", "timestamp": "2026-03-12T120855.159083+00:00"}

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

How can I deactivate that VAD, I'm not passing any speech from my client only text

Thanks — this is straightforward to fix. If your client is only sending text (no audio), simply stop providing a VAD instance and tell the AgentSession not to expect audio input. That will prevent VAD from running and eliminate the warning. Quick steps 1. Do not load or pass any VAD plugin to your session. ◦ Remove calls like

silero.VAD.load(...)

or any

vad=

parameter when creating the

AgentSession

. 1. Disable audio input in the room options when starting the session:

from livekit.agents import AgentSession
from livekit.agents.voice import room_io

session = AgentSession(
    stt=None,   # or your chosen text-only config
    llm=...,    # your LLM plugin
    tts=None,   # optional
    # no vad parameter here
)

await session.start(
    agent=MyAgent(),
    room=ctx.room,
    room_options=room_io.RoomOptions(
        audio_input=False,  # disable expecting client audio
        audio_output=False  # set True only if you need TTS audio
    )
)

Key points • VAD only runs if you include a VAD instance in the session. Not passing one disables it. • Setting

audio_input=False

ensures the agent does not expect or process incoming audio. • With those two changes, you won’t see the “input speech hasn’t started yet…” warning since no VAD will be active. If you want, tell me: • Which version of the agents SDK you’re using, or • Paste the snippet where you create the

AgentSession

and call

start

, and I’ll point out exactly what to change. Sources: Turns overview | LiveKit Documentation | How to build an agent with speech-to-text input and text-only output | Live...

Oaky thanks, now I allowed this server into an aws instance. This intance runs on a 2cpu core and 2Gb of ram. Sometimes it shows the next warning: 1|sophia-s | {"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.8387114000000002, "threshold": 0.7, "timestamp": "2026-03-12T094604.766304+00:00"} 1|sophia-s | {"message": "worker is below capacity, marking as available", "level": "INFO", "name": "livekit.agents", "load": 0.06880000000000011, "threshold": 0.7, "timestamp": "2026-03-12T094609.768947+00:00"} 1|sophia-s | {"message": "worker is at full capacity, marking as unavailable", "level": "INFO", "name": "livekit.agents", "load": 0.8915608, "threshold": 0.7, "timestamp": "2026-03-12T094917.331044+00:00"} 1|sophia-s | {"message": "worker is below capacity, marking as available", "level": "INFO", "name": "livekit.agents", "load": 0.6747221999999999, "threshold": 0.7, "timestamp": "2026-03-12T094932.334913+00:00"}

Thanks — I see the capacity warnings you pasted. I’ll explain what they mean and give clear, practical steps you can take on your AWS instance (2 vCPU, 2 GB RAM) to stop the worker from oscillating between available/unavailable. What the logs mean • The agent measures a “load” value (CPU-based by default) and compares it to

load_threshold

(default 0.7). • When load > threshold the worker is marked unavailable and stops taking new jobs; when load drops below it becomes available again. • Your logs show the worker repeatedly crossing the threshold, so job assignment can be interrupted and latency/failed assignments can occur. Why this is happening on your instance • A 2 vCPU / 2 GB RAM instance is underpowered for typical voice/AI workloads the agent may run. LiveKit recommends larger instances (starting around 4 vCPU and more RAM) for stable performance. • Burstable instance types (t3/t4) can also throttle CPU when credits deplete, causing spikes or inconsistent CPU availability. Recommended actions (pick what fits your situation) • Short-term: increase the threshold (quick tweak) a. Increase

load_threshold

so the worker tolerates higher CPU before marking unavailable.

from livekit.agents import AgentServer
     server = AgentServer(load_threshold=0.9)

1. Note: This reduces churn but doesn’t add real capacity — you may still see slowdowns under sustained load. • Better: scale up the instance (recommended) ◦ Move to a non-burstable instance with more vCPUs and RAM (e.g., m5.large or c5.large, 4+ vCPU, 8 GB RAM recommended). ◦ This reduces CPU spikes and prevents throttling that causes the availability flips. • Alternative: change how load is measured ◦ Use a custom

load_fnc

that measures concurrency (active jobs) rather than CPU, if that better matches your capacity model:

def compute_load(server: AgentServer) -> float:
        return min(len(server.active_jobs) / 10.0, 1.0)  # scale to [0,1]
    server.load_fnc = compute_load

• This avoids short CPU bursts marking you unavailable but requires you to pick sensible scaling factors. • Long-term / robust solution: horizontal scaling ◦ Run multiple agent workers under the same

agent_name

so jobs distribute across instances. ◦ This gives resilience: when one worker is busy the scheduler can route work to others. • Operational tuning (additional) ◦ Avoid burstable instance types (t3/t4) for steady loads; prefer consistent CPU types. ◦ Monitor CPU and memory with a metrics tool to see whether spikes are CPU or memory bound. ◦ If you run heavy plugins (STT, TTS, or model inference), consider separating those onto dedicated workers or using larger instances for those tasks. Quick checklist to act now • If you need an immediate quick fix: raise

load_threshold

to 0.9. • For stability and production: provision a larger non-burstable instance (≥4 vCPU, more RAM). • For capacity/HA: add more workers and/or use a custom load function. If you want, I can: • Suggest a target AWS instance type based on expected concurrent sessions (tell me how many simultaneous sessions you expect). • Show exactly where to change

load_threshold

or add a

load_fnc

in your current server code (paste your server startup snippet). • Help you plan a multi-worker deployment for redundancy. Which would you prefer? Sources: Server options | LiveKit Documentation | Self-hosted deployments | LiveKit Documentation | Troubleshooting Latency and Timeout Errors with Turn Detection on AWS | Agents Framework | livekit/livekit_composite | DeepWiki

Thanks, but i'm not using currently any LLM or STT, only the TTS. Should I still increase the machine requeriments?

Thanks — that’s a helpful clarification. Because you’re only running TTS (no LLM or STT), your resource needs are lower than a full voice-AI stack, but you can still hit CPU/memory limits depending on the TTS engine and concurrency. Here’s how to decide and what to do next. Short answer • Possibly not: if your TTS is lightweight and you expect very few concurrent syntheses, your 2 vCPU / 2 GB instance may be sufficient. • Upgrade or tune: if you see the capacity warnings or poor latency under normal load, increase resources or adjust the load logic. What affects TTS resource use • TTS engine type: native or lightweight TTS (cloud TTS or small local engines) uses much less CPU/RAM than large neural on-device models. • Concurrency: multiple simultaneous TTS requests are the main driver of CPU spikes. • Latency tolerance: with tight latency requirements, you’ll want extra headroom to avoid queuing. • Background overhead: the agent process, network, and other plugins still consume some memory/CPU. Practical guidance • Monitor first: ◦ Watch CPU, memory, and the agent load metric over a representative period (including peak times). ◦ If CPU regularly crosses your load threshold (~0.7) and you see the “worker at full capacity” messages, that’s a sign you need more capacity or tuning. • Quick tuning options (if you prefer not to upgrade immediately): ◦ Increase

load_threshold

(e.g., 0.85–0.9) to reduce churn if spikes are brief and you can tolerate higher utilization. ◦ Use a custom

load_fnc

based on concurrent TTS jobs instead of CPU, so short CPU bursts don’t mark the worker unavailable. • Upgrade when needed: ◦ If your TTS is a neural model running locally or you expect multiple concurrent syntheses, move to a larger instance (4 vCPU, more RAM). This gives more consistent performance and avoids throttling. ◦ Avoid burstable instance families (t3/t4) for sustained or bursty TTS loads. Suggested next steps 1. Tell me the TTS engine you’re using (cloud service vs local model) and the expected concurrent TTS requests. 2. I can recommend: ◦ Whether your current instance is likely sufficient, ◦ Specific

load_threshold

or

load_fnc

settings, or ◦ A target AWS instance type if you want to scale. Which detail should we start with — your TTS engine or expected concurrency?