Feature Request: commit_user_turn() without automatic response generation

[bml1g12]

Feature Type

Would make my life easier

Feature Description

This is a feature request for https://community.livekit.io/t/how-to-commit-user-turn-without-generating-a-response/433

• We are using manual turn taking (https://docs.livekit.io/agents/logic/turns/#manual)
• We are using cascaded models (STT/LLM/TTS)
• Currently when commit_user_turn() is called it always triggers a response from the model automatically

We need to force the user to give up their turn and get the agent to “say” something specific - so in this case, we do not want to trigger the agent to say anything automatically when we end the user turn and call commit_user_turn().

We need to call commit_user_turn() though because we need to commit the user's latest speech from the STT (i.e. buffered transcript) into the livekit local state so the LLM is aware of it before the user next ends their turn. i.e. we do not wish to discard the users latest speech whenever the agent interrupts their turn.

Ideally we could do something like commit_user_turn(skip_reply=False)

Workarounds / Alternatives

We could manually commit it to local state i.e. consume the transcript creation event and manually add it to the local context maybe like

@self._session.on("user_input_transcribed")
         ...
        agent = session.current_agent
        agent._chat_ctx.items.append(chat_msg)
        session._conversation_item_added(chat_msg)

like this, but the problem would be I do not know how to “flush” the STT to get the latest available transcript as input to this.

Another idea would be to do

commit_user_turn()
session.interupt()
generate agent speech

But as it says here Search | DeepWiki I think that would not be bulletproof either as its possible to interrupt before the LLM request starts making the interrupt a no-op

Additional Context

No response

[longcw]

does the on_user_turn_completed callback work for you (doc), you can raise a StopResponse there to skip the agent response for this turn, for example.

[davidzhao]

commit_user_turn(generate_reply=False) seems like a sensible option, by default generate_reply would be True

[bml1g12]

@longcw thats an interesting idea, I will try it

@davidzhao indeed that would be simpler and easier for devs to understand I think

[weiguangli-io]

Technical Analysis: commit_user_turn(generate_reply=False) feasibility

I dug into the implementation to evaluate the two proposed approaches. Here's what I found.

The use case is legitimate and currently underserved

The scenario — proactively interrupting the user to inject an agent utterance while preserving the user's buffered STT transcript — is a real gap. Today you can either:

1. commit_user_turn() → always triggers a reply, or
2. clear_user_turn() → discards the transcript entirely

There's no way to say "flush the transcript into chat context, but I'll handle the reply myself."

Implementation analysis: StopResponse vs generate_reply=False

Option A: StopResponse in on_user_turn_completed

This already works today (as @longcw pointed out). The flow is:

commit_user_turn() → _run_eou_detection() → on_end_of_turn() 
  → _user_turn_completed_task() → on_user_turn_completed() → raise StopResponse

When StopResponse is raised at line 1563 of agent_activity.py, it returns before scheduling any speech. The user message has already been created (line 1511-1515) but is not appended to the chat context — the return at line 1564 skips both the _agent._chat_ctx.items.append() and generate_reply() calls.

This is a problem for the use case. The whole point is to commit the transcript to context without generating a reply. With StopResponse, you'd need to manually append the message to chat_ctx inside on_user_turn_completed before raising the exception, which is fragile and duplicates internal logic.

Option B: commit_user_turn(generate_reply=False) (or skip_reply=True)

Interestingly, the internal plumbing already partially supports this. The audio_recognition.py commit_user_turn() method already accepts skip_reply: bool = False (line 258), and it propagates through _run_eou_detection() → _EndOfTurnInfo.skip_reply → on_end_of_turn().

However, the skip_reply flag is currently only respected in the realtime model path (lines 1522-1527 in agent_activity.py). For cascaded STT/LLM/TTS pipelines, skip_reply is never checked — the flow always proceeds to on_user_turn_completed() → generate_reply().

The fix would be straightforward: in _user_turn_completed_task(), after creating user_message and before the interruption/generation logic, check info.skip_reply for cascaded models the same way it's already done for realtime models:

# After line 1529 in agent_activity.py, add similar handling for cascaded models:
if info.skip_reply:
    if info.new_transcript != "":
        self._agent._chat_ctx.items.append(user_message)
        self._session._conversation_item_added(user_message)
    return

Then expose it through AgentSession.commit_user_turn():

def commit_user_turn(
    self, *, 
    transcript_timeout: float = 2.0, 
    stt_flush_duration: float = 2.0,
    generate_reply: bool = True,  # new parameter
) -> None:

STT buffer flush concern

The STT flush mechanism in _commit_user_turn() (audio_recognition.py lines 263-327) is critical here. It pushes silence frames to force the STT to emit a final transcript, then waits up to transcript_timeout for it. This must still execute regardless of generate_reply — the transcript needs to be finalized and committed to context even when no reply is generated. The current skip_reply plumbing already handles this correctly: the flush happens before _run_eou_detection() is called, so it's unaffected by skip_reply.

Race condition considerations

The commit_user_turn() → interrupt() → say() workaround mentioned in the issue is indeed fragile. There's a timing window between commit_user_turn() (which spawns an async task) and when the LLM generation actually starts. If interrupt() fires before the generation task is scheduled, it's a no-op. Even with await asyncio.sleep(0) hacks, this is fundamentally racy.

With generate_reply=False, the race disappears entirely — no generation is ever started, so there's nothing to interrupt.

Recommendation

I'd advocate for Option B (generate_reply=False) because:

1. The internal scaffolding already exists — skip_reply flows through the entire pipeline, it just needs to be checked for cascaded models and exposed at the public API level
2. It's semantically clear — "commit the transcript but don't reply" is exactly what the parameter name communicates
3. It avoids race conditions — unlike commit + interrupt + say, there's no timing window
4. It preserves the transcript — unlike StopResponse, it naturally commits the user message to chat context
5. It's consistent — mirrors the behavior already implemented for realtime models

The StopResponse approach remains useful for conditional reply suppression (e.g., "skip reply if the user said less than N words"), but for the explicit "I know I don't want a reply" case, a parameter is the right API.

[bml1g12]

Thanks!