docs(runtime): correct TypeScript claims in RunConfig streaming docs

[kazunori279]

The streaming sections of docs/runtime/runconfig.md tell TypeScript readers three things that are not true of the TypeScript SDK. Surfaced while reviewing #2076, where a contributor hit the same gap from the other direction.

All three were verified by running the documented code against @google/adk 1.6.0 (Node 25, gemini-2.5-flash over Vertex AI) and by reading google/adk-js at HEAD.

1. The BIDI bullet pointed at an entry point TypeScript does not have

It read: "For bidirectional streaming, use runner.run_live() instead." — on a page tagged for TypeScript. Runner exposes no runLive() (runner.ts has only a TODO) and LlmAgent.runLiveFlow throws Error: LlmAgent.runLiveFlow not implemented.

The bullet also omitted the behaviour that actually bites: passing BIDI does not error, does not warn, and does not stream. Measured on the same agent and prompt:

streamingMode	events yielded
SSE	6
omitted (default NONE)	1
BIDI	1, no error, no warning

A reader who reasons "bidi is a superset of sse" gets strictly worse behaviour than if they had asked for less. Now stated explicitly, with a warning admonition for the TypeScript case.

2. The TypeScript tab recommended supportCfc: true, which breaks the run

The snippet was copy-pasteable and produced no answer. With the documented config:

supportCfc=true:  events=1  text=""
   errorCode=UNKNOWN_ERROR  errorMessage="CFC is not yet supported in callLlmAsync"

supportCfc=false: events=2  text="Hello."

The throw is at llm_agent.ts in the callLlmAsync path and is surfaced as an error event, so a reader who does not check event.errorCode sees silence rather than a failure. Removed from the TypeScript snippet; the existing "Experimental" admonition now records the exact symptom.

3. "Configure live agents" claimed TypeScript support for a run_live()-only section

The section documents run_live() parameters and carried a TypeScript support tag plus a TypeScript snippet. The three fields the TypeScript RunConfig does declare — enableAffectiveDialog, proactivity, realtimeInputConfig — are assigned only into llmRequest.liveConnectConfig, which is consumed only by the live path that throws. They are typed but inert.

Removed the tag and the snippet, and added a note explaining why the fields exist and do nothing, so the next reader who finds them in the type does not have to work this out.

Checks

• mkdocs build --strict — clean
• New internal link ../live/index.md resolves
• No changes outside docs/runtime/runconfig.md

[netlify]

✅ Deploy Preview for adk-docs-preview ready!

Name	Link
🔨 Latest commit	6ad872b
🔍 Latest deploy log	https://app.netlify.com/projects/adk-docs-preview/deploys/6a7d1d368264ea00081a6906
😎 Deploy Preview	https://deploy-preview-2101--adk-docs-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[joefernandez]

@kazunori279 - please have a looks at these findings

Technical review report

Review: adk-docs#2101 — docs(runtime): correct TypeScript claims in RunConfig streaming docs

Verdict: 1 of 4 changes still verifies. The other 3 were correct when written (2026‑08‑10 against @google/adk 1.6.0) but have been invalidated by upstream adk-js commits that landed 3–8 days later. One of them now states the exact opposite of current behavior.

Verified against repo HEADs as of 2026‑08‑18:

Repo	HEAD
adk-js	48165a8
adk-python	dd998a7
adk-go	2325d1c
adk-java	527ff4e
adk-kotlin	998a002

---

The timing problem

The author's evidence was sound. At the main-v1.6.0 tag (72f89b0, 2026‑08‑05 — still latest on npm today), all three TypeScript claims hold:

• runner.ts#L580 — // TODO - b/425992518: Implement runLive and related methods.
• llm_agent.ts#L760 — throw new Error('LlmAgent.runLiveFlow not implemented');
• llm_agent.ts#L1092 — throw new Error('CFC is not yet supported in callLlmAsync');

Two upstream merges then moved the ground:

• adk-js#692 (merged 2026‑08‑13), closing adk-js#676 — "StreamingMode.BIDI is accepted but has no effect — silently degrades to NONE". BIDI now throws.
• adk-js#523 (merged 2026‑08‑18) — feat(core): implement Runner.runLive and LlmAgent live flow.

---

1. BIDI bullet — ❌ now wrong for TypeScript, imprecise for Go/Java/Kotlin

"Passing it does not enable streaming, and no error or warning is raised — the run behaves as if StreamingMode.NONE had been set."

TypeScript (HEAD): it throws. runAsync funnels through createRunConfig, which rejects BIDI:

• runner.ts#L257 — const runConfig = createRunConfig(params.runConfig);
• run_config.ts#L155-L161 — throw new Error('StreamingMode.BIDI is not supported; use StreamingMode.SSE.')

Python: the claim holds. base_llm_flow.py#L1648 gates streaming on == StreamingMode.SSE only, with no validation; the enum docstring at _streaming_mode.py#L139-L147 says as much.

Go: BIDI isn't reachable from the public API. The exported agent.RunConfig declares only NONE and SSE — agent/run_config.go#L20-L26. StreamingModeBidi lives only in internal/agent/runconfig/run_config.go#L28.

Kotlin: BIDI does not exist. The enum is NONE and SSE — RunConfig.kt#L29-L50.

Java: BIDI is not inert on the standard path. It changes function-call dispatch:

• BaseLlmFlow.java#L763-L766 — BIDI selects Functions.handleFunctionCallsLive instead of handleFunctionCalls
• BaseLlmFlow.java#L746-L747 — BIDI changes event-emission filtering

So "behaves as if NONE had been set" is accurate for exactly one of the five SDKs.

2. run_live() warning admonition — ❌ stale

"Runner exposes no runLive(), and the agent-level live path throws Error: LlmAgent.runLiveFlow not implemented."

Both are implemented at HEAD:

• runner.ts#L648 — async *runLive(params: {...})
• llm_agent.ts#L955-L989 — full runLiveFlow with reconnect/session-resumption
• 1,115 lines of coverage in core/test/runner/run_live_test.ts

Caveat in the PR's favor: npm latest is still 1.6.0 (published 2026‑08‑06), so the warning is true for anyone on the current release. But it's written as unversioned prose and will be false the moment 1.7.0 ships.

3. supportCfc removal from the TypeScript snippet — ✅ correct, still verifies

• Throw site: llm_agent.ts#L1821-L1825
• Surfaced as an event rather than propagating: llm_agent.ts#L1945-L2007 catches the Error, and with no JSON error payload to parse falls through to errorCode = 'UNKNOWN_ERROR' with errorMessage = modelError.message — exactly the errorCode/errorMessage pair quoted in the admonition.
• Scoping the note to TypeScript is right: Python implements CFC by routing to the live path (base_llm_flow.py#L1612-L1614, runners.py#L2320-L2331).

Keep this change.

4. "Configure live agents" — TS tag + snippet removal — ❌ stale

"…they only feed the live connection, which the TypeScript SDK does not implement yet."

The first half was and is true — the fields are written into liveConnectConfig at basic_llm_request_processor.ts#L65-L70. The second half no longer is: all three are in LIVE_KEYS (llm_agent.ts#L138-L147) and applied by the now-working live flow at llm_agent.ts#L989.

Separately, narrowing the tag to Python-only is too aggressive independent of the TS question: Java has Runner.runLive and implements one of the section's documented parameters, avatar_config (RunConfig.java#L74); Go drives a live path too (runner.go#L447).

5. Minor — the new naming parenthetical is wrong for 3 of 5 SDKs

"(streaming_mode in Python, Go, Java and Kotlin; streamingMode in TypeScript)"

SDK	Actual identifier	Source
Python	streaming_mode ✅	run_config.py#L102
TypeScript	streamingMode ✅	run_config.ts#L66
Go	StreamingMode ❌	agent/run_config.go#L31
Java	streamingMode() / setStreamingMode() ❌	RunConfig.java#L78, #L188
Kotlin	streamingMode ❌	RunConfig.kt#L61

The page's own Go and Java snippets (StreamingMode: agent.StreamingModeSSE, .streamingMode(StreamingMode.SSE)) already contradict the sentence added right above them.

Non-issues

../live/index.md resolves (docs/live/index.md). Diff is confined to docs/runtime/runconfig.md as stated.

---

Recommendation

Land §3 (the CFC changes) as-is — that's a real, still-current bug in the docs where the copy-pasteable snippet produces an error event and no answer. Ask the author to rebase the other three against adk-js HEAD:

1. Replace the generic BIDI paragraph with per-language behavior, since the five SDKs now do four different things (TS throws; Python silently degrades; Go/Kotlin have no BIDI in the public API; Java changes function-call dispatch).
2. Drop the run_live() warning, or rewrite it as version-scoped ("not available in @google/adk ≤ 1.6.0") — and note that Runner.runLive is documented as experimental at HEAD.
3. Restore the TypeScript tag and snippet under "Configure live agents", and drop the "typed but inert" note.

[joefernandez]

This needs some work.

Don't explicitly call out TS not supporting Live, it's distracting, unnecessary, and creates technical debt. (see comments)

[joefernandez]

Remove. The example code above shows the syntax for each language, so don't repeat it, here.

[joefernandez]

we need to more thoroughly disambiguate streamed text responses from the Live / voice functionality. Here's a new intro:

You can control how an agent responds in text mode, including 
word-by-word as generated or full responses, use the 
***Streaming Mode*** parameter, as described below:

[joefernandez]

remove.

mentioning this parameter is not yet implemented in TS just adds unnecessary detail to this note, and creates maintenance debt for us to clean up later.

[joefernandez]

change for clarity:

## Text response options

to avoid confusion with Live and voice functionality

[joefernandez]

remove this warning.

If a feature is not supported, don't need to mention it unless is strongly expected. If we mentioned everything the software didn't do, the documentation would be nothing but "it doesn't do this" statements.

[joefernandez]

Add "Java" tag

[joefernandez]

remove

If a feature is not supported, don't need to mention it unless is strongly expected. If we mentioned everything the software didn't do, the documentation would be nothing but "it doesn't do this" statements.

[joefernandez]

remove this bullet. don't list BIDI as a parallel option because that's not helpful and a bit misleading.

replace this with a new paragraph mentioning Live and pointing to that resource:

There is another setting for the ***Streaming Mode*** parameter which
enables bidirectional streaming of data, including voice input and output.
This feature requires additional configuration beyond simple agents. For
more information about this feature, see [Live and Voice Agents](/live/). 

[joefernandez]

Add this as the leading sentences of the intro for this section:

ADK agents can support [Live and Voice Agents](/live/) to create interactive
agent experiences. You configure agents that support this functionality 
using the `runner.run_live()` method. When using... 

[joefernandez]

recommend adding a Java RunConfig code example here