https://livekit.io logo
Join Slack
Powered by
I want to understand the interruption handling par...
# ask-ai
s
I want to understand the interruption handling parameters and how it's getting used in voice agent pipeline.
✅ 1
t
Thanks for reaching out, Abhi. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — I’ll explain the interruption handling parameters and how they’re used in the voice agent pipeline, and ask one quick clarifying question so I tailor it to your needs. Quick question: are you asking about interruption behavior for a LiveKit agent deployed to LiveKit Cloud (adaptive mode enabled by default) or for a custom/local deployment where you want configuration details? Below is the concise overview while I wait for your answer. What interruption handling does • Lets a user interrupt (barge-in) while the agent is speaking: playback is stopped, queued audio canceled, conversation state truncated, and the agent begins listening. • Distinguishes true interruptions from false positives (backchanneling like “mm-hmm”, coughs). Key configuration (under AgentSession.turn_handling.interruption) • enabled (boolean): allow interruptions at all. • mode (string): 
"adaptive"
(default) or 
"vad"
. ◦ `"adaptive"`: ML model analyzes acoustic features to decide if speech is a real interruption. Recommended for natural behavior and enabled on LiveKit Cloud. ◦ `"vad"`: simple voice-activity-detection-only; any voice activity may trigger interruption. • discard_audio_if_uninterruptible (boolean): if true, drop buffered audio while agent speaks when interruptions are disabled. • min_duration (float, seconds): minimum speech length to count as interruption (applies to 
vad
mode). • min_words (int): minimum recognized words required to trigger interruption (requires STT). • false_interruption_timeout (seconds / ms): time of silence after detected interruption before emitting an 
agent_false_interruption
event. • resume_false_interruption (boolean): if true, resume agent speech after a false interruption if no more user speech follows. Behavior & events • On valid interruption: TTS stops immediately, queued speech canceled, agent switches to listen; 
user_interruption_detected
event fires. • If interruption has no transcript: 
agent_false_interruption
fires; if 
resume_false_interruption
is true the agent can resume speaking. • You can also programmatically trigger interruptions with 
session.interrupt()
/ 
handle.interrupt()
. Requirements & limitations • Adaptive mode requires LiveKit Agents SDK v1.5.0+ (Python) or v1.2.0+ (Node). • Adaptive mode is not available when using a realtime LLM with server-side turn detection; server-side VAD will handle decisions and many interruption options are ignored (except 
discard_audio_if_uninterruptible
for buffering). • Adaptive handling needs aligned transcripts (supported by LiveKit Inference STT models and some plugins). • LiveKit Cloud provides adaptive interruption by default (with free inference quota for dev use). If you want, I can: • Show example config/code for your chosen SDK (Python or Node). • Recommend parameter values for specific use cases (e.g., short prompts, noisy environments, call-center style). • Explain how interruption events integrate with your conversation history handling. Which follow-up would you like? Sources: Turns overview | LiveKit Documentation | Solving unwanted interruptions with Adaptive Interruption Handling | LiveKi... | Adaptive interruption handling | LiveKit Documentation, with interactive elements
s
How coversation state is getting set for the cases interruption happened ?
t
Thanks — I’ll explain how conversation state is updated when an interruption occurs, and how you can observe or control that behavior. How conversation state is set on interruption • When a valid user interruption is detected, the agent immediately stops TTS playback and cancels any queued speech. • The agent truncates the current response state so history reflects only content produced before the interruption; any partially-produced response that was interrupted is discarded. • The agent switches to a listening state and begins a new user turn. Conversation context that remains available for the next turn includes prior turns up to the truncation point (i.e., what was committed before the interrupted reply). • If the interruption is later deemed a false interruption (no transcript), an 
agent_false_interruption
event is emitted. If 
resume_false_interruption
is true, the agent may resume the interrupted speech and state will be restored to continue that response; otherwise the interrupted response stays discarded. Events and flags you can use • `user_interruption_detected`: indicates a valid interruption and that the agent has truncated the current response and entered listening mode. Use this to update UI or persist truncated state. • `agent_false_interruption`: indicates an interruption with no useful transcript. If you want to restore the interrupted reply, listen for this and check 
resume_false_interruption
behavior. • Programmatic interrupt: calling 
session.interrupt()
/ 
handle.interrupt()
triggers the same truncation/listen transition. Practical notes • Truncation is automatic—you don’t need to manually delete partial responses unless you have custom buffering logic. • If you rely on STT transcripts to decide whether to keep an interrupted utterance, listen to the STT result and 
agent_false_interruption
event before committing conversational state. • With realtime LLMs that do server-side turn detection, interruption decisions may be handled server-side; buffering behavior still follows 
discard_audio_if_uninterruptible
. If you’d like, I can: • Show the specific event handlers/code snippets for Python or Node to observe/truncate state. • Recommend a pattern to persist conversation history across interruptions for your use case. Which would you prefer?, with interactive elements
s
For the interruption case, what happen to LLM calls if interruption detected during the LLM calls.
t
Thanks — I’ll explain what happens to LLM calls when an interruption is detected during generation, and offer practical controls you can use. What happens when interruption occurs during LLM work • Preemptive LLM generation: the speculative LLM request is canceled and its partial output is discarded. The agent stops TTS, clears queued speech, and restarts listening for the new user input. • Tool execution (LLM-initiated external calls): by default the tool and its result are removed from history and ignored if interrupted. Irreversible side effects may therefore be lost unless explicitly protected. • Realtime LLMs with server-side turn detection: the model itself decides interruptions; client-side interruption options are largely ignored and the model’s internal turn-detection and buffering control behavior. Controls to protect important work 1. Prevent cancellation inside a tool: ◦ Call 
run_ctx.disallow_interruptions()
at the start of the tool to prevent it being removed during interruption. 1. Ensure audio/playout completes before continuing: ◦ Use 
await context.wait_for_playout()
(or the equivalent) to finish speaking before proceeding. 1. Use conservative interruption settings for critical flows: ◦ Disable adaptive interruption or increase safeguards (e.g., require 
min_words
, longer 
min_duration
) if you need fewer preemptions. 1. For realtime-model flows: ◦ Tune model-side turn-detection parameters (e.g., threshold/silence/eagerness) because server-side detection governs interruption behavior. State and event signals to watch • On interruption the agent emits 
user_interruption_detected
and truncates the in-progress response from history. • If no transcript follows, 
agent_false_interruption
fires; use 
resume_false_interruption
to optionally resume the interrupted response. If you want, I can: • Show code examples (Python or Node) for canceling/guarding tools and handling those events. • Recommend concrete interruption parameter values for your use case (call center, short prompts, noisy environment). Which would you prefer? Sources: Turn-taking tuning | LiveKit Documentation | Function tool definition | LiveKit Documentation | Sequential Pipeline Architecture for Voice Agents | LiveKit | Turns overview | LiveKit Documentation, with interactive elements
4 Views
Open in Slack
PreviousNext
Powered by