Description
Using the Live API (bidi streaming / WebSocket) with gemini-3.1-flash-live-preview, thinking_config enabled (thinking_level="low", include_thoughts=True), and function calling (a handful of tools registered), we intermittently observe the model:
- Deciding to call a specific function and composing its exact arguments — visible verbatim in the returned
thought parts (e.g. "I'll be using the check_availability tool to find the exact time slot... I'm ready to use the tools to finalize the appointment.")
- Never emitting the function call at all, and instead speaking synthesized/fabricated data in the same turn as if a tool had already returned a result — with no disclaimer, no error, nothing to indicate the data wasn't real.
Why we're confident this isn't a client-side/SDK issue
We captured every raw Live API server message before any client-side (ADK) processing — i.e. logging directly at the point our client library receives each message off the wire, before any filtering, dispatch, or turn-taking logic runs. Grepping the full raw capture for an affected call (6,000+ raw messages) for a non-null tool_call/functionCall field returns zero matches for the entire call, including every message in the turn where the model spoke the fabricated data. The function call structure was never present on the wire — not dropped by a client bug, not filtered, never sent by the server.
We also found the model's own thought text, ~2 seconds after it had already spoken the fabricated/ungrounded claim, saying (paraphrased) "my next step is to call [the tool]" — i.e. it appears to plan the tool call chronologically after already having spoken the content that call should have grounded. This looks like a turn-ordering/sequencing issue in generation, not a transport loss.
Reproduction rate
Roughly 20-35% in our test conditions (multi-turn conversations that include at least one tool-calling decision, thinking enabled). We have not isolated the exact trigger — it reproduces on both simple single-tool turns and multi-turn conversations, doesn't correlate with any argument value we've been able to identify, and reproduces with both audio and text-simulated caller input.
Related prior art
Ask
Is this a known/expected failure mode for native-audio Live + function calling on this model version? We have detailed captured-thinking + raw-wire evidence (composed args in thought, zero wire-level function call, self-corrective thought after the fact) that's more specific than what we found in existing reports, and are happy to share a redacted reproduction script or full raw capture excerpt if useful for triage.
Environment
- google-genai 2.10.0, google-adk 2.5.0 (ADK's Live client wraps this library; confirmed via raw wire capture that ADK is not involved in the drop)
- Model: gemini-3.1-flash-live-preview
- thinking_config: thinking_level="low", include_thoughts=True
Description
Using the Live API (bidi streaming / WebSocket) with
gemini-3.1-flash-live-preview,thinking_configenabled (thinking_level="low",include_thoughts=True), and function calling (a handful of tools registered), we intermittently observe the model:thoughtparts (e.g. "I'll be using thecheck_availabilitytool to find the exact time slot... I'm ready to use the tools to finalize the appointment.")Why we're confident this isn't a client-side/SDK issue
We captured every raw Live API server message before any client-side (ADK) processing — i.e. logging directly at the point our client library receives each message off the wire, before any filtering, dispatch, or turn-taking logic runs. Grepping the full raw capture for an affected call (6,000+ raw messages) for a non-null
tool_call/functionCallfield returns zero matches for the entire call, including every message in the turn where the model spoke the fabricated data. The function call structure was never present on the wire — not dropped by a client bug, not filtered, never sent by the server.We also found the model's own thought text, ~2 seconds after it had already spoken the fabricated/ungrounded claim, saying (paraphrased) "my next step is to call [the tool]" — i.e. it appears to plan the tool call chronologically after already having spoken the content that call should have grounded. This looks like a turn-ordering/sequencing issue in generation, not a transport loss.
Reproduction rate
Roughly 20-35% in our test conditions (multi-turn conversations that include at least one tool-calling decision, thinking enabled). We have not isolated the exact trigger — it reproduces on both simple single-tool turns and multi-turn conversations, doesn't correlate with any argument value we've been able to identify, and reproduces with both audio and text-simulated caller input.
Related prior art
gemini-2.5-flashnative-audio in 2025; acknowledged by Google and improved in a later preview build for that model generation. We haven't found an equivalent report against3.1-flash-live-preview.Ask
Is this a known/expected failure mode for native-audio Live + function calling on this model version? We have detailed captured-thinking + raw-wire evidence (composed args in thought, zero wire-level function call, self-corrective thought after the fact) that's more specific than what we found in existing reports, and are happy to share a redacted reproduction script or full raw capture excerpt if useful for triage.
Environment