# LLM turn silently lost mid-call, no retry — reproducible across models **URL:** \ **Category:** Support Help\ **Tags:** bug\ **Created:** [June 11, 2026, 1:03pm UTC](https://community.retellai.com/t/llm-turn-silently-lost-mid-call-no-retry-reproducible-across-models/3068 "2026-06-11T13:03:54Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![redlinepro70](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/redlinepro70/32/727_2.png) [@redlinepro70](https://community.retellai.com/u/redlinepro70)\ **Post date:** [June 11, 2026, 1:03pm UTC](https://community.retellai.com/t/llm-turn-silently-lost-mid-call-no-retry-reproducible-across-models/3068/1 "2026-06-11T13:03:54Z")
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. ---
**Author:** ![mark1](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/mark1/32/2524_2.png) [@mark1](https://community.retellai.com/u/mark1)\ **Post date:** [June 11, 2026, 1:05pm UTC](https://community.retellai.com/t/llm-turn-silently-lost-mid-call-no-retry-reproducible-across-models/3068/2 "2026-06-11T13:05:46Z")
Hello @redlinepro70 I have escalated the Call IDs to the team for a review. Thanks ---
**Author:** ![mark1](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/mark1/32/2524_2.png) [@mark1](https://community.retellai.com/u/mark1)\ **Post date:** [June 11, 2026, 5:26pm UTC](https://community.retellai.com/t/llm-turn-silently-lost-mid-call-no-retry-reproducible-across-models/3068/3 "2026-06-11T17:26:25Z")
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 calculated` line 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 ---
**Author:** ![cgonzalez](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/cgonzalez/32/741_2.png) [@cgonzalez](https://community.retellai.com/u/cgonzalez)\ **Post date:** [July 15, 2026, 5:02pm UTC](https://community.retellai.com/t/llm-turn-silently-lost-mid-call-no-retry-reproducible-across-models/3068/4 "2026-07-15T17:02:58Z")
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 1. Confirm whether the generation-level watchdog + retry path from thread 3068 has shipped, and if not, a timeline. 2. 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). 3. 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. ---
**Author:** ![mark1](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/mark1/32/2524_2.png) [@mark1](https://community.retellai.com/u/mark1)\ **Post date:** [July 15, 2026, 5:21pm UTC](https://community.retellai.com/t/llm-turn-silently-lost-mid-call-no-retry-reproducible-across-models/3068/5 "2026-07-15T17:21:22Z")
Hello @cgonzalez I have escalated the Call IDs to the team for review. Thank you for providing the details. ---
**Author:** ![mark1](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/mark1/32/2524_2.png) [@mark1](https://community.retellai.com/u/mark1)\ **Post date:** [July 15, 2026, 6:08pm UTC](https://community.retellai.com/t/llm-turn-silently-lost-mid-call-no-retry-reproducible-across-models/3068/6 "2026-07-15T18:08:52Z")
Hello @cgonzalez Team pulled both Call IDs server-side. Answering your three questions directly: 1. 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 into `node_schedule` — same class, same node, same silent-until-hangup outcome. Node config is not the cause: `node_schedule`’s outgoing edges (exit, slot\_picked, else`check_availability`) are all well-formed. 2. 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. 3. No agent-side knob today. `reminder_trigger_ms` / `reminder_max_count` only 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_schedule` to 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, so `node_schedule` has less to reason about on entry. Send new call IDs after any of these and I’ll compare against the same signature. Regards ---
**Author:** ![cgonzalez](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/cgonzalez/32/741_2.png) [@cgonzalez](https://community.retellai.com/u/cgonzalez)\ **Post date:** [July 15, 2026, 7:41pm UTC](https://community.retellai.com/t/llm-turn-silently-lost-mid-call-no-retry-reproducible-across-models/3068/7 "2026-07-15T19:41:55Z")
Thank you, this is exactly the kind of answer I was hoping for. I applied two of your three mitigations the same day: 1. node\_schedule’s instruction is now less than half its previous size (it was the largest node in the flow, as you noted). 2. 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: 1. 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. 2. 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 ---
**Author:** ![mark1](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/mark1/32/2524_2.png) [@mark1](https://community.retellai.com/u/mark1)\ **Post date:** [July 15, 2026, 8:52pm UTC](https://community.retellai.com/t/llm-turn-silently-lost-mid-call-no-retry-reproducible-across-models/3068/8 "2026-07-15T20:52:52Z")
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 `"\nThe user is asking about availability tomorrow."` and then, after the tool result returns, emits a full closed `` 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 ---
**Author:** ![trevor](https://yyz2.discourse-cdn.com/flex008/user_avatar/community.retellai.com/trevor/32/466_2.png) [@trevor](https://community.retellai.com/u/trevor)\ **Post date:** [August 3, 2026, 5:04pm UTC](https://community.retellai.com/t/llm-turn-silently-lost-mid-call-no-retry-reproducible-across-models/3068/9 "2026-08-03T17:04:12Z")
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.