Hi team, We are facing interruption handling issues with LiveKit Agents and wanted to understand the recommended architecture here. Setup: • Self-hosted LiveKit server on AWS Mumbai (

ap-south-1

) • Using LiveKit Cloud credentials (Build Plan) • Initially using

vad

interruption handling Issue: With normal

vad

mode, the agent occasionally got stuck during conversations even after configuring:

resume_false_interruption = 0.8

So we switched to

adaptive

interruption handling. However, after testing adaptive mode, we observed: 1. Genuine interruptions are sometimes missed, especially in noisy environments 2. Frequent timeout/fallback errors:

adaptive interruption inference timed out after 0.7s
fallback to VAD
status_code=408

From logs, it seems adaptive inference is happening on:

agent-gateway.livekit.cloud

So the flow becomes: Mumbai Server → LiveKit Cloud (US/EU) → Mumbai This cross-region round trip appears to exceed the strict

0.7s

timeout budget under slight latency/noise conditions. 3. Additionally, it seenms When adaptive inference times out and fallback to VAD happens, the fallback VAD does not appear to properly respect/load

min_interruption_duration

. As a result: • interruption detection becomes unstable • short/noisy audio chunks trigger inconsistent states • the agent sometimes gets stuck in an unusable state ("state 0" behavior on our side) This makes the fallback path unreliable in production. Questions: 1. Is this a known limitation/bug with adaptive → VAD fallback handling. Is there any workaround/recommended configuration for stable fallback behavior? 2. Is there any way to self-host the adaptive interruption inference/VAD model on our own infrastructure? 3. Since we already have LiveKit Cloud Build Plan credentials, is there a recommended low-latency setup for hybrid deployments (self-hosted LiveKit + cloud adaptive inference)? Currently, local

vad

mode feels more stable than adaptive mode due to these timeout/fallback issues. Would appreciate guidance on the recommended production architecture and whether this fallback behavior is a known issue.

Hi Harleen Kaur Hora, ⚠️ This channel will be deleted soon ⚠️ Please use our new community at https://community.livekit.io for technical discussions and to post technical questions. The Slack community is not going away, but we are migrating technical questions to our new forum. Please see full details here.

This looks more like a latency and fallback architecture issue than just VAD tuning. Since adaptive interruption inference is routed through LiveKit Cloud, the Mumbai → cloud → Mumbai round trip is likely exceeding the strict 0.7s timeout window, which explains the 408s and unstable fallback behavior. From my experience, local/self-hosted VAD is currently more stable for production unless the inference endpoint is geographically close. The fallback not consistently respecting min_interruption_duration after timeout also sounds like an edge-case/state handling issue rather than only configuration. I’d recommend keeping interruption-critical processing local as much as possible and minimizing dependency on cloud adaptive inference for noisy environments. I can also help tune the interruption pipeline and fallback handling to make the agent more production-stable. @some-memory-62374

Thanks, this aligns with what we observed during testing. If we decide to stay with local

vad

for production stability, what would be the recommended tuning strategy to reduce: • false barge-ins • interruption misses • agent getting stuck after noisy interruptions Our current configuration is:

LIVEKIT_MIN_INTERRUPTION_DURATION=0.5
LIVEKIT_RESUME_FALSE_INTERRUPTION=true
LIVEKIT_FALSE_INTERRUPTION_TIMEOUT=0.8

Observed behavior: • Lower interruption duration improves responsiveness but increases false interruptions in noisy environments • Increasing it reduces false barge-ins but sometimes misses genuine user interruptions • Occasionally the agent still enters a stuck/interrupted state after noise-triggered interruptions Are there recommended production-safe ranges or additional parameters we should tune for: • noisy environments • telephony-like audio • real-time conversational agents Also, is there a recommended strategy for handling interruption state recovery beyond

RESUME_FALSE_INTERRUPTION

? @polite-rain-22350

You’re already in the right direction with local VAD, stability comes more from balance than pushing one parameter. In noisy/telephony environments, MIN_INTERRUPTION_DURATION usually performs better slightly higher than 0.5, because lower values tend to treat noise bursts as speech. If you raise it too much, you’ll start missing real interruptions, so the key is keeping it moderate and relying on noise suppression/cleaner input rather than tightening VAD too aggressively. For the “stuck state” issue, RESUME_FALSE_INTERRUPTION alone is often not enough. In production, teams usually add a lightweight recovery rule that forces a state reset if no valid speech resumes within a short window after an interruption, which prevents the agent from staying frozen after noise-triggered cuts. Overall, the stable setup is usually a balanced VAD threshold + noise handling + explicit state recovery, rather than extreme tuning of a single parameter. If you want, I can help you fine-tune exact thresholds based on your audio samples and call logs so it behaves consistently in real conditions. @some-memory-62374

This is very helpful, thanks. A few follow-up questions: 1. Is there a recommended “state recovery” implementation pattern for LiveKit agents after false/noise-triggered interruptions? • For example, should we explicitly reset interruption state if: no STT transcript arrives within X ms no speech confidence crosses threshold 2. Are there any other internal/recommended timeout values for? in telephony/noisy production setups? 3. Are there any known race conditions/state-machine edge cases in current LiveKit agent interruption handling that teams should defensively handle themselves? @polite-rain-22350

For state recovery, the most reliable approach is to treat interruption as a temporary state and auto-reset it if no valid STT result or speech activity is confirmed within a short window (usually a few hundred ms). That prevents the agent from staying stuck due to noise-triggered interruptions. In production, most stability issues come from timing mismatches between VAD, STT, and interruption handling rather than a single parameter, so keeping those transitions tightly aligned is key. Common edge cases to defensively handle are late STT transcripts arriving after an interruption reset, rapid interrupt/resume loops, and out-of-order events caused by network jitter typically solved with a simple state lock or sequence guard. If you want, I can help you design a clean state machine flow that eliminates most of these issues in production. @some-memory-62374

sure. would appreciate guidance for clean state machine flow

Connect with me in DM @some-memory-62374