context_window_compression is forwarded but appears to have no effect for gemini-3.1-flash-live-preview (native audio run_live) - should ADK warn like it does for affective_dialog/proactivity?

[imazizongit]

Environment

• google-adk 2.5.0
• google-genai 2.10.0
• Model: gemini-3.1-flash-live-preview
• Auth: Gemini API key (not Vertex)
• Runner.run_live() bidi streaming, native audio, function tools enabled

Config used

RunConfig(
    context_window_compression=types.ContextWindowCompressionConfig(
        trigger_tokens=12000,
        sliding_window=types.SlidingWindow(target_tokens=8000),
    )
)

Verified the config reaches the Live API

ADK forwards context_window_compression unconditionally: src/google/adk/flows/llm_flows/basic.py sets llm_request.live_connect_config.context_window_compression = run_config.context_window_compression, and google_llm.py passes live_connect_config verbatim to client.aio.live.connect. A raw google-genai probe using the same config is accepted at setup and completes turns without error, so the config is reaching the Live API server correctly.

Observed (controlled A/B, same 12-turn scripted phone call, per-turn usage_metadata deltas summed)

• Compression ON: 236s, input 221,054 tokens (text_input 150,579 / audio_input 46,581), 15 usage events. Per-turn prompt deltas grew past the 12k trigger with no flattening — indistinguishable from the compression-OFF baseline.
• Compression OFF (baseline): 214s, input 201,363 tokens.
• No error at any point, no compression effect on billed tokens in either run.

Independent repro by another user

https://discuss.ai.google.dev/t/live-api-does-contextwindowcompression-target-tokens-affect-the-post-compression-window-for-audio-s2s-sessions/147228 — target_tokens 512 vs 8000 both converge to ~71k prompt tokens by turn 25, i.e. the target has no observable effect either.

Question

basic.py already nulls enable_affective_dialog and proactivity for Gemini 3.x live models (_is_gemini_3_x_live), but forwards context_window_compression unconditionally.

• (a) Is compression known to be unsupported/inert for 3.x native-audio live models? If so, should ADK null it (or warn) the same way it does for the other two fields?
• (b) If it's supposed to work, is this an ADK forwarding bug, or a Live API server-side issue that should be reported against the API itself rather than ADK?

Possibly-related reports

• ADK run_live() incompatible with gemini-3.1-flash-live-preview (5 breaking issues) #5075 (closed) — reported that context_window_compression caused a 1007 Request contains an invalid argument error specifically for gemini-3.1-flash-live-preview. That's a different symptom (hard connection error) from what we're seeing (silently accepted, no error, just no effect on billed tokens) — worth checking whether the two are the same underlying incompatibility surfacing differently across versions, or genuinely separate.
• Tool Hallucination when using ContextWindowCompression and BIDI Live #4231 — tool hallucination observed after ContextWindowCompression triggers on BIDI Live (gemini-live-2.5-flash via Vertex). Different symptom, same feature.
• WebSocket 1011 Error During Tool Execution with Gemini Live API #3918 — WebSocket 1011 errors during tool execution; reporter tried enabling context window compression as a mitigation and noted it "eliminates context overflow, but 1011 errors persist." Different root issue, but same observation that compression didn't behave as expected.

[surajksharma07]

@imazizongit compression skips the same is_gemini_3_x_live check that already nulls affective_dialog/proactivity in basic.py, so it's an oversight rather than intentional filtering.

Put together a patch that logs a warning instead of silently forwarding it — could you try it on your setup and confirm it fires as expected?

Still want to confirm with the Live API side whether compression is actually inert for 3.x native-audio before going further.