Thanks — good question. You're asking how hosting your server in US West (Hillsboro, OR) will affect latency for a LiveKit voice agent. Here’s what matters and what you can do. Short answer • Hosting the agent in US West will give low network latency for users and services nearby. • End-to-end voice latency is driven most by where your AI models (STT, LLM, TTS) run. If those models are co-located in the same region, you can hit sub‑second conversational turn times. If models are remote, each model call adds round-trip time and increases total latency. Key points and recommendations • Agent ↔️ Model placement is critical: Co-locate your agent and all model providers in US West to minimize round-trip time between STT → LLM → TTS. • User ↔️ Agent latency: LiveKit’s real‑time network is optimized, so user connections to an Oregon-hosted agent will be low-latency for West Coast users. • Target: Aim for under 1 second from user stop → agent start by using streaming STT, a fast LLM (low time-to-first-token), and streaming TTS all in-region. • Deploy guidance: Use the region flag when creating agents (for example,

--region us-west

) and verify model providers support a US West endpoint or host your own models in the same region. • Measure bottlenecks: Monitor per-turn metrics (e.g., e2e_latency, llm_node_ttft, tts_node_ttfb) via the Agent Observability dashboard to find whether STT, LLM, or TTS is the dominant delay. If you’d like, tell me: • Which STT/LLM/TTS providers you plan to use (or if you’ll self-host models), and • Your primary user regions I’ll suggest a concrete deployment and expected latency profile. Sources: Building Performant Voice Agents in India | LiveKit | Voice Agent Architecture: STT, LLM, and TTS Pipelines Explained | LiveKit | Voice Agent Architecture: STT, LLM, and TTS Pipelines Explained | LiveKit | Understand and Improve Agent Latency | LiveKit | Understand and Improve Agent Latency | LiveKit, with interactive elements