On conversation-flow agents, an LLM generation intermittently never returns: logs show “llm input token length calculated” and then nothing — no latency line, no tool call, no retry. The agent goes silent and the call dies on inactivity. Reproduced with gemini-3.0-flash (with and without high_priority and tool_call_strict_mode) AND with a claude-4.5-haiku node-level override, at 16k–27k input tokens. Most often on the turn that generates large function-call args. Example calls: call_2ca06dbdae2d94758621ed7873a, call_44c9c0a92250f9b58f8ef006c4f, call_f906f7f56f64d9ca497c30f5197, call_638c1662b0960a2c31fecf3f33c. Please add a generation timeout/retry — one lost turn currently kills the whole call and costs us booked jobs.
Hello @redlinepro70 I have escalated the Call IDs to the team for a review. Thanks
Hello @redlinepro70 Thanks for the detailed repro and the four call IDs — we pulled them and have a clear picture.
What we observed on all 4 calls:
- All 4 stall on the same kind of turn — the final wrap-up right after the caller confirms the booking (“Is that correct?” → “Yes”).
- The upstream LLM call actually returned successfully on each one (HTTP 200, with output tokens in the 71–109 range). The
llm input token length calculatedline you’re seeing is the last log our LLM layer emits for a turn — it fires in the finally block after the stream has ended. So from the LLM client’s view the turn completed; nothing downstream rendered audio. - This matches what you’re describing: no latency line, no tool result, no hedge — because the hedge intentionally disarms once the first content chunk arrives (including the opening fragment of a tool-call args JSON), and there is no aggregate generation timeout covering the post-stream consumer path. A turn that returns successfully but produces nothing the agent can speak currently has no safety net, and mid-stream errors on that path are caught without a retry.
So the gap you’re flagging — “one lost turn kills the whole call, please add a timeout/retry” — is a real architectural gap on our side, not a flaky upstream. We’ll write this up for engineering as a generation-level watchdog plus a retry path on the empty-effective-output case; we can’t promise scope or timing from here.
One follow-up that would help us scope: in the four IDs you sent, every failing turn ran on gemini-3.0-flash — none exercised the claude-4.5-haiku node override. If you have a call ID where the same silence reproduced under claude-4.5-haiku, please send it over so we can confirm the cross-model behavior with a concrete trace.
Thank You
We run a Conversation Flow agent (agent_61b33932021bb1b4b7755a2350, flow conversation_flow_ce3adde29be5) and have twice captured a failure where the runtime transitions into a conversation node and then never generates that node’s first utterance - no LLM request appears in the call log, no error, no retry, no reminder - leaving the caller in total silence until they hang up.
Call 1: call_8f29db53276d2ba90fa81cb515a (2026-07-15, agent v6)
Public log timeline:
- 16:17:49.357 - llm input token length calculated (tokenLength: 2593)
- 16:17:50.152 - Transitioning from node_meeting_offer to node_schedule
- 16:18:44.313 - Ending call (caller gave up and hung up)
54 seconds between the transition and the hangup with zero log entries: no generation attempt for the schedule node’s opening turn, no error, no retry. The agent had reminder_trigger_ms: 8000, reminder_max_count: 3 configured - no reminder fired either (we understand reminders cover a silent user after agent speech; here the agent owed the turn, so there appears to be no configurable safety net at all for this state).
Call 2: call_48ea27908d119d4a14437f4bfa4 (2026-07-14, agent v3)
Same shape, ~60 seconds: after a tool result returned to node_schedule (19:55:54.309 transition), one LLM first-token timeout was logged (19:55:58.820 - “Streaming LLM response attempt 1 failed: 4500ms timeout reached for first token”), the agent spoke twice more, and then the log goes silent from 19:56:30 to 19:57:30 with the caller asking “are you still there?” into dead air.
Why we believe this is the known generation-gap issue
Community thread 3068 (“LLM turn silently lost mid-call, no retry, reproducible across models”) contains a staff acknowledgment that a turn can return successfully with no speakable output and that “a turn that returns successfully but produces nothing the agent can speak currently has no safety net,” with a generation-level watchdog described as planned. Our calls appear to be exactly this gap on the conversation-flow engine (claude-4.5-haiku, cascading, high_priority).
Asks
- Confirm whether the generation-level watchdog + retry path from thread 3068 has shipped, and if not, a timeline.
- Confirm there is genuinely no agent-side setting today that re-engages an agent that owes a turn (reminder_* documented semantics only cover user silence).
- Review the two call IDs above server-side — if this is a different root cause than thread 3068, we’d like to know what it is.
This is the single remaining blocker for moving this agent from our staging line to a production number; everything else in the flow now passes our simulation-test suite.
Hello @cgonzalez I have escalated the Call IDs to the team for review. Thank you for providing the details.
Hello @cgonzalez Team pulled both Call IDs server-side.
Answering your three questions directly:
- Same root cause as thread 3068. Both calls hit the same defect: an LLM turn completes without producing anything further speakable or a tool call, and the current response-generator path logs it and exits without re-invocation. Call 1 hits it on entry to
node_schedule; call 2 hits it after a first-token timeout on the retry path back intonode_schedule— same class, same node, same silent-until-hangup outcome. Node config is not the cause:node_schedule’s outgoing edges (exit, slot_picked, elsecheck_availability) are all well-formed. - Generation-level watchdog + retry: not shipped yet. I can’t commit a timeline from support — I’ll attach these two call IDs to engineering as additional repros on top of thread 3068.
- No agent-side knob today.
reminder_trigger_ms/reminder_max_countonly cover user silence after an agent turn; there is no configurable safety net for an agent that owes the turn.
Mitigations you can apply on this flow while the platform fix is pending — these reduce probability, not certainty:
- Trim
node_schedule’s instruction; it’s the largest node in the flow. - Pin
node_scheduleto a single (non-cascading) model to remove the empty-completion fallback path. - Move the relative-date reasoning either into a smaller helper node or into
check_availability’s tool logic, sonode_schedulehas less to reason about on entry.
Send new call IDs after any of these and I’ll compare against the same signature.
Regards
Thank you, this is exactly the kind of answer I was hoping for. I applied two of your three mitigations the same day:
-
node_schedule’s instruction is now less than half its previous size (it was the largest node in the flow, as you noted).
-
The relative-date reasoning moved out of the node entirely, into the check_availability tool logic. The tool contract now tells the model to pass the day exactly as the caller said it (“tomorrow”, “thursday”, “next friday”) and my backend resolves it to a concrete date. The model does no date arithmetic at all anymore.
Two findings back for you:
-
Your third suggestion is not possible through the public API. POST /create-conversation-flow rejects any model_choice.type other than “cascading” with: “request/body/model_choice/type must be equal to one of the allowed values: cascading”. If a single-model pin exists, it is not exposed to API users. Happy to test it if there’s a supported way to set it.
-
Possibly related to the same generator path: in simulation test runs (Tests API) against this flow, I have captured BOTH claude-4.5-haiku and claude-4.6-sonnet emitting literal reasoning blocks into speakable output. One reached a live caller’s ear on call_596233e3c528d6d555e9e7db175 (2026-07-15, agent v5, the 4.6-sonnet turn into node_schedule). I have added a prompt-level ban, but reasoning-tag stripping seems like it belongs on the platform side of the same response-generator work as the watchdog.
The flow is now on version 16 with these mitigations live on our staging number. I will send fresh call IDs if the silent-turn signature recurs. Please do attach my two calls to the engineering issue, and I would appreciate hearing when the watchdog ships.
Chris Gonzalez
Hey @cgonzalez thanks for the fast turnaround on the mitigations and for the extra findings. Confirming both back to you:
On finding #3 (single-model pin not reachable via API). You’re right, and I verified against our current OpenAPI schema: model_choice.type is a oneOf with only cascading today — there is no non-cascading variant exposed to API consumers. So the third mitigation from my previous message isn’t self-servable at the moment. Apologies for suggesting it as a lever without checking the API surface first. I’ll route this internally as a gap so a single-model pin option gets considered when the response-generator work lands; if it’s already tracked, I’ll link the ticket back here.
On finding #4 (literal reasoning tags reaching TTS). Confirmed on call_596233e3c528d6d555e9e7db175 (agent v5, 2026-07-15): response 9 on entry to node_fn_check_availability speaks "<thinking>\nThe user is asking about availability tomorrow." and then, after the tool result returns, emits a full closed </thinking> block back into TTS on the return to node_schedule. That turn ran on cascading haiku→sonnet high_priority, and the words have real audio timings — so yes, it landed in the caller’s ear, not just in the transcript. This is a good repro; I’m attaching it to the same engineering thread as the two silent-turn repros, tagged as “reasoning-content leaking past the streaming filter into speakable output.” Your prompt-level ban is a reasonable belt-and-suspenders, but I agree the durable fix belongs on the platform side of the response generator — same code neighborhood as the watchdog.
Watchdog status. No shipped-date update yet; I’m not going to give you a speculative ETA. What I can do is keep this Pylon ticket linked to the engineering tracker so you get notified the moment the generation-level watchdog + retry lands — call IDs already attached: call_8f29db53276d2ba90fa81cb515a (fresh node entry), call_48ea27908d119d4a14437f4bfa4 (retry-after-first-token-timeout), and now call_596233e3c528d6d555e9e7db175 (reasoning-leak variant).
Thank You
Adding another data point, with two details that may narrow this further.
Config: conversation flow, cascading, gpt-5.6-terra, high_priority: false.
Subagent node. Agent agent_2d1de6113f74bde82fe134b300 v147, flow
conversation_flow_11f49d8025d5 v147.
Call ID: call_65922d3c31f27f2a54190b97999 (2026-08-03 16:45:50 UTC)
Ordinary conversation, no booking, no transfer. The agent asked a screening
question at t=85.8s, the caller answered at t=93.0s, and the agent then produced
nothing for 84.2 seconds until the caller hung up.
llm_token_usage: 10 requests, avg 17,615, range 17,449–17,754 — squarely
in the 16k–27k band described above, on every turn of the call- LLM latency p50 873ms, p90 1,750ms, max 3,578ms — the model was not
slow, the turn was empty disconnection_reason: user_hangup
Two things that may be useful:
1. No tool call was involved — at all. tool_calls is empty for the entire
call. The reproductions above emphasise turns generating large function-call
arguments; this one never called a tool. That suggests the empty-effective-output
path is not specific to function-call generation, only to input size.
2. Reminders do not fire during the dead turn. This agent has
reminder_trigger_ms: 10000 and reminder_max_count: 2. In an 84-second silence
both should have triggered. Neither produced audio. If the reminder path is armed
by the same response-generator that exits early, the inactivity nudge may be lost
with the turn — which would mean the one mechanism that could paper over this is
disabled by the same bug.
Two more, same flow, after a successful create_appointment (matching the
“most common after callers confirm bookings” pattern):
call_f7d4fc362fc9949419b3cbc65b9 (peak 17,704 tokens) and
call_c09d685d194ae2c74858bbe0e96 (peak 17,413). Both went silent mid-call and
required the caller to say “hello?” repeatedly before any further audio.
We’re following workaround 1 — our largest node instruction is ~13.1k tokens and
we’re cutting it — but flagging that with the watchdog unshipped, the reminder
path appears not to provide a fallback either.