Skip to content

fix(google): default tool_behavior to NON_BLOCKING on Gemini 3.8 Live - #7329

Merged
longcw merged 1 commit into
mainfrom
longc/gemini-live-38-non-blocking
Sep 18, 2026
Merged

longcw merged 1 commit into
mainfrom
longc/gemini-live-38-non-blocking

Conversation

@longcw

@longcw longcw commented Sep 18, 2026

Copy link
Copy Markdown
Contributor

Problem: Gemini 3.8 Live declares tools NON_BLOCKING unless the client sends a behavior field, and the plugin sends none while tool_behavior is unset. The server then runs tools async while supports_silent_scheduling reads the unset option and stays False, so a result with reply_required=False goes out without scheduling: SILENT and the model answers it anyway.

Fix: RealtimeModel.__init__ resolves tool_behavior to NON_BLOCKING for 3.8 models and stores it in _opts, so the tool declaration and the scheduling decision read one value. Models without the tag still send no behavior, and an explicit tool_behavior still wins.

Addresses the first item of #7302.

Context for reviewing and coding agents

Is the Gemini 3.8 Live default measured?

No. The claim comes from the model page quoted in #7302. The warning counts reported there (15/15 with the default, 10/10 with BLOCKING, 0/15 with NON_BLOCKING) restate supports_silent_scheduling, which reads no server field, so they are not evidence about the server. One live call settles it: call a tool that sleeps for three seconds with tool_behavior unset. Speech during the sleep means the server ran the tool async. Silence means the server declared it BLOCKING, and this change must not land.

How to see the failure

A tool that returns None sets reply_required=False (generation.py:1202), and that is the only input which reaches the silent path. On gemini-3.8-live without this change, the warning at realtime_api.py:718 fires for such a call and the model speaks after the result. A tool that returns a value keeps reply_required=True and never reaches the path, so it cannot show the failure.

Blast radius

_opts.tool_behavior has two readers: the tool declaration built in create_tools_config (realtime_api.py:1254) and supports_silent_scheduling (realtime_api.py:710). Resolving the default once in the constructor keeps them consistent, instead of adding a second derivation at each reader. update_options already restarts the session when the value changes (realtime_api.py:602), and Vertex keeps its own guard, because it accepts the declaration but drops scheduling.

What this does not fix

Every tool on 3.8 is now declared NON_BLOCKING, a hangup tool included, which the model can talk over. Per-tool behavior needs a field on FunctionToolInfo and is the second item of #7302. The wait that holds a tool result until playout ends lives in core (agent_activity.py:4667) and is #6741.

Gemini 3.8 Live declares tools NON_BLOCKING unless the client says
otherwise. The plugin sent no `behavior` when `tool_behavior` was unset,
so the server ran tools async while `supports_silent_scheduling` still
read the unset option and stayed False. A tool result with
`reply_required=False` then went out without `scheduling: SILENT`, the
model answered it anyway, and the warning fired on every call.

Resolve the default in `RealtimeModel.__init__` and store it in
`_opts`, so the declaration and the scheduling decision read one value.
Models without the tag keep sending no `behavior`, and an explicit
`tool_behavior` still wins.
@longcw
longcw marked this pull request as ready for review September 18, 2026 03:27
@longcw
longcw requested a review from a team as a code owner September 18, 2026 03:27

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔍 Devin Review: 1 flag

Not posted on this PR by your GitHub settings — view it in Devin Review. (Configure)

Devin Review

@davidzhao davidzhao left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants