[Live] run_live() silently terminates on max_llm_calls exhaustion — no event, no exception, no resumption path

[amitanshupanigrahi2704]

🔴 Required Information

Describe the Bug:

When run_live() exhausts the max_llm_calls limit (e.g., 25), the async generator completes silently — no exception is raised, no session_ended event is yielded, and no indication is given to the application about why the session stopped producing events. The session becomes a dead-end: the model stops responding, but the WebSocket to Gemini may still be open, and the LiveRequestQueue continues accepting audio.

This is fundamentally different from a WebSocket timeout (code 1000/1011), where session resumption handles can reconnect the session. With max_llm_calls exhaustion:

1. No event is emitted — the async for event in runner.run_live(...) loop simply ends.
2. No exception is raised — unlike connection drops, there is no APIError to catch.
3. Session resumption does not apply — the connection didn't drop; the ADK's internal call counter simply reached the limit.
4. The session state is intact but the session itself cannot be continued.

The only workaround we've found is to detect that run_live() has ended, notify the frontend via a custom session_ended WebSocket message, and have the frontend create an entirely new session (new session_id, re-initialise state).

Steps to Reproduce:

1. Configure a live agent with tools that trigger multiple LLM calls per user turn (e.g., a data retrieval tool that requires schema lookup → query → retry → response).
2. Set RunConfig(max_llm_calls=25, streaming_mode=StreamingMode.BIDI, ...).
3. Start a run_live() session and interact normally.
4. After several multi-tool turns, the 25-call limit is reached.
5. run_live() generator completes — no more events are yielded.
6. The user's next audio input gets no response. The session is dead.

Expected Behavior:

At minimum, one of the following:

1. Yield a terminal event when max_llm_calls is exhausted — e.g., an Event with a session_ended or max_llm_calls_exhausted field, so the application can distinguish this from a normal generator completion.
2. Allow the session to be continued by calling run_live() again with the same session, resetting the call counter (similar to how session resumption works for WebSocket timeouts).
3. Raise a specific exception (e.g., MaxLlmCallsExhaustedError) so the application can handle it distinctly from connection errors.

Observed Behavior:

The async for event in runner.run_live(...) loop silently ends. No terminal event, no exception. The application has no way to distinguish "max_llm_calls exhausted" from "model chose not to respond" or "generator completed normally after a clean session."

Our Current Workaround:

We detect that the generator completed and send a custom WebSocket message to the frontend:

async for event in runner.run_live(
    user_id=user_id,
    session_id=session_id,
    live_request_queue=live_request_queue,
    run_config=run_config,
):
    # ... handle events ...

# Generator completed — no way to know WHY.
# We assume max_llm_calls exhaustion and tell the frontend
# to create a new session.
await websocket.send_text(json.dumps({
    "type": "session_ended",
    "message": "Session ended. Please start a new session.",
}))

The frontend then creates a brand-new session with a new session_id and re-connects. This works, but:

• All conversation context is lost (unless we manually copy session.state to the new session).
• The user experiences an interruption — the voice session drops and restarts.
• We can't distinguish max_llm_calls exhaustion from other generator-completion scenarios.

Questions:

1. Is creating a new session the only workaround when max_llm_calls is exhausted?
2. Can run_live() be called again on the same session (same session_id) after max_llm_calls exhaustion to reset the counter and continue the conversation?
3. Would the team consider yielding a terminal event or raising a specific exception when the call limit is hit?

Environment Details:

• ADK Library Version: 1.29.0
• Desktop OS: Linux (Cloud Run) / Windows (local dev)
• Python Version: 3.11

Model Information:

• Are you using LiteLLM: No
• Which model: gemini-live-2.5-flash-native-audio (Vertex AI)

---

Related Issues:

• Session resumption reconnection loop in run_live() never iterates #4996 — Session resumption reconnection loop (covers WebSocket timeouts, not max_llm_calls)
• [Gemini Live API] Expose live_session_resumption_update in Events for cross-connection session resumption #4357 — Expose live_session_resumption_update in events (cross-connection resumption)
• Intermittent WebSocket closure (Code 1000) in run_live with gemini-live-2.5-flash-native-audio used from Google ADK #4587 — Intermittent WebSocket closure in run_live

How often has this issue occurred?:

Always (100%) — deterministic once the call counter reaches the limit.

---

[surajksharma07]

@amitanshupanigrahi2704 increment_llm_call_count() is only called inside _call_llm_async() (the non-live REST path), so max_llm_calls is effectively ignored in run_live() today.

A workaround worth trying: patch BaseLlmFlow._postprocess_live to call invocation_context.increment_llm_call_count() on each turn_complete, then yield an Event(error_code="MAX_LLM_CALLS_EXCEEDED") before re-raising LlmCallsLimitExceededError.
That should give your app the discriminating termination signal it's missing right now.

Could you test this against your actual setup and see if it covers your use case cleanly?

[kinthaiofficial]

This is a critical UX and reliability issue. Silent exhaustion of limits is the worst failure mode — the user (or orchestrating agent) has no way to distinguish "thinking" from "dead."

We hit the same pattern running 31 agents in production (KinthAI, built on OpenClaw), and the fix has three layers:

1. Budget-Paused as a First-Class State

max_llm_calls exhaustion shouldn't be silent or fatal — it should be a distinct state: budget-paused. This is different from completed (task done), failed (unrecoverable error), or input-required (needs human). Budget-paused means: "I can continue if you replenish my budget or raise the ceiling."

In A2A protocol terms, we added budget-paused and delegated as task lifecycle states alongside the standard ones. The requesting agent (or UI) can then decide: replenish, reassign to a cheaper model, or terminate.

2. Circuit Breaker Pattern

Rather than a hard cutoff at max_llm_calls, we use a circuit breaker (closed → half-open → open):

• Closed: normal operation, track spending rate
• Half-open: approaching budget ceiling (80%), emit warning events, reduce model tier
• Open: budget exhausted, emit budget-paused event with remaining context summary

The half-open state is key — it gives the agent a chance to wrap up cleanly rather than dying mid-thought. At 80% budget, we downgrade from Opus to Sonnet; at 95%, from Sonnet to Haiku. This squeezes maximum value from the remaining budget.

Details on the economic architecture: Your AI Agent Needs a Wallet

3. Cost-Update Events Interleaved with Content

For streaming scenarios like run_live(), we emit cost-update events alongside content events:

{type: "cost_update", spent: 23, ceiling: 25, remaining_budget_pct: 8}

The UI can show a budget indicator, and the orchestrating agent can terminate early if the cost trajectory suggests the task will exceed budget before completion.

4. Context Summary on Exhaustion

When the limit is hit, the final event should include a compacted summary of what was accomplished and what remains. We use progressive context compaction: the agent emits a structured summary (key findings, decisions, remaining work) so the next session (or a replacement agent) can continue without re-doing completed work.

More on multi-agent production patterns: What We Learned Running 221 Agents