LiteLLM & ADK Agent latency issue

[ghassenTn]

I tested the same model (Ox Alpha) using both OpenCode and a custom agent I created with ADK and LiteLLM. I noticed that my agent's response time is much slower than OpenCode, even though both use the same provider (OpenRouter).

Could this latency difference be caused by overhead from LiteLLM or ADK?

[yrangana]

One thing worth ruling out first: does your agent set output_schema together with tools? If so you are likely making many more model calls per turn than you think. See #6954 — LiteLlm reports output_schema_and_tools=True for every model it wraps, so ADK sends response_schema alongside the tool declarations and the model loops on the tool instead of answering. I measured 4, 12, 18 and 19 tool calls across four runs of identical code where 2 was correct. It still returns valid output, so from the outside it just looks slow.

Quick check: count function_call parts per turn. Anything above one per tool you actually expect is this.

If that is not it, OpenRouter's Broadcast gives a breakdown that separates the layers without instrumenting anything. Turn it on under Settings → Observability, then compare per generation:

• openrouter_router_latency_ms — OpenRouter's own routing overhead
• openrouter_provider_time_to_first_token_ms — the upstream provider
• $ai_latency — total

For reference, on google/gemini-2.5-flash-lite through OpenRouter I see routing around 209 ms against roughly 1000 ms provider TTFT, so routing was a small fraction of wall time. If your numbers look similar but total turn time is much higher, the overhead is in ADK or LiteLLM rather than the network path, and the generation count is the thing to look at.

[ghassenTn]

Thanks for flagging #6954 super helpful. We checked and we don't currently set output_schema together with tools on that path, so we aren't hitting the output_schema_and_tools loop. We also added a quick count of function_call parts per turn as you suggested and it's stable at the expected count (vs the 4/12/18/19 in the repro), so that matches not being affected.

Appreciate the tip on OpenRouter Broadcast as well we'll use the routing vs provider TTFT breakdown to isolate if total latency stays high. And good to know the LiteLLM capability is hard-coded we'll keep the conservative output_schema_and_tools=False behavior until the upstream fix lands. Thanks again!