Thanks — I’m responding to your question about making STT start up faster, especially for the first utterance. Short answer: yes. Here are practical ways to reduce first-utterance latency and what I’d recommend trying first. • Pre-warm the STT client at agent startup Initialize your STT client or plugin when your agent/process starts (not only when the first user speaks). That avoids cold-start overhead. • Use streaming recognition Streaming STT returns partial transcripts as audio arrives, so the perceived time-to-first-word is much smaller than batch processing. • Keep long-lived connections Reuse an open connection to the STT provider instead of recreating it per session to avoid handshake/setup delays on the first utterance. • Co-locate/choose regionally close inference Host your agent infrastructure in the same region as your STT provider (or use a regional endpoint) to reduce network RTT. • Pick a low-latency provider and tune frame size Some providers are faster in practice. Also send smaller audio frames (e.g., ~20ms) for quicker partial results. If you want, tell me: • which STT provider you’re using (Deepgram, Google, etc.), and • whether you’re using LiveKit Agents or a custom integration, and I’ll give concrete, provider-specific steps you can implement. Sources: Voice Agent Architecture: STT, LLM, and TTS Pipelines Explained | LiveKit | Live conversations with AI using ChatGPT and WebRTC | LiveKit | Sequential Pipeline Architecture for Voice Agents | LiveKit | Understand and Improve Agent Latency | LiveKit | Voice Agent Architecture: STT, LLM, and TTS Pipelines Explained | LiveKit, with interactive elements