ADK LiteLlm adapter drops LiteLLM reasoning content

[mikkokirvesoja]

Summary

When using ADK with LiteLLM-backed models that emit separate reasoning / "thinking" content (for example via reasoning_content or reasoning fields on messages and deltas), the current LiteLlm adapter in ADK silently discards that reasoning.

As a result, ADK callers cannot access or surface model reasoning even though it is available in the underlying LiteLLM responses.

This behavior has been observed with:

• ADK (google-adk) 1.19.0
• LiteLLM 1.79.3 (Local models from LM Studio and another model via OpenAI compatible endpoint)

Current Behavior

The ADK side behaves roughly as follows:

• LiteLlm:
  • Aggregates assistant content and tool call information from LiteLLM responses.
  • Does not read or propagate any reasoning_content / reasoning fields from LiteLLM.
• LlmResponse:
  • Does not define a field for reasoning, so there is nowhere to store it.
• Event:
  • Inherits from LlmResponse and is what flows emit to callers.
  • Since LlmResponse has no reasoning field and LiteLlm does not populate one, Event never exposes reasoning either.

In practice, this means:

• Downstream consumers using ADK only see final assistant content and tool calls.
• Any reasoning content provided by LiteLLM-backed models is silently dropped and unavailable.

Expected Behavior

For LiteLLM-backed models that emit reasoning fields (e.g. reasoning_content / reasoning):

• ADK's LiteLlm adapter should:
  • Map those reasoning fields into an explicit reasoning field on LlmResponse.
  • Do this consistently for both non-streaming and streaming responses.
• LlmResponse / Event should:
  • Expose this reasoning field so that callers can choose to display or process it.

For models/providers that do not emit any reasoning fields:

• Behavior should remain unchanged.
• The reasoning field should simply be absent / None and not appear in serialized output when using exclude_none=True.

Impact

• ADK currently cannot surface model reasoning even when it is available through LiteLLM.
• This limits the ability of downstream applications to provide transparency/debugging views or UX patterns that distinguish between "thinking" and final answers.
• The problem is purely on the ADK integration side: LiteLLM already exposes the necessary fields.

Proposed Directions

1. Extend LlmResponse with an optional reasoning field

   • Add reasoning: Optional[str] = None to google.adk.models.llm_response.LlmResponse.
   • This becomes the canonical place to store reasoning/thinking content within ADK.
   • Because Event inherits from LlmResponse, Event will also gain this field automatically.

2. Map LiteLLM reasoning into LlmResponse.reasoning in the LiteLlm adapter

   In google.adk.models.lite_llm.LiteLlm:

   • Non-streaming path (_model_response_to_generate_content_response):

     • After building LlmResponse from the main assistant message, inspect choices[0].message from the LiteLLM ModelResponse.
     • If the message (whether dict-style or Pydantic-style) contains reasoning_content or reasoning, copy that string into llm_response.reasoning.

   • Streaming path (generate_content_async(..., stream=True)):

     • Maintain a reasoning_text accumulator alongside the existing text buffer.
     • For each streaming chunk, inspect choices[0].delta from the LiteLLM ModelResponseStream.
     • If the delta (dict or object) contains reasoning_content or reasoning, append it to reasoning_text.
     • When yielding partial/final LlmResponse instances, pass reasoning=reasoning_text or None.

3. Rely on existing flow behavior to propagate reasoning to events

   • BaseLlmFlow._finalize_model_response_event already merges LlmResponse into Event via something like:

     model_response_event = Event.model_validate({
         **model_response_event.model_dump(exclude_none=True),
         **llm_response.model_dump(exclude_none=True),
     })

   • Once LlmResponse.reasoning is populated, this merge will automatically carry it into Event.reasoning.

   • No changes should be required in flows or runners.

Local patch & verification

I have tested this approach locally by patching ADK 1.19.0 as follows:

• google.adk.models.llm_response.LlmResponse

  • Added an optional reasoning: Optional[str] field to hold model reasoning / thinking content.

• google.adk.models.lite_llm.LiteLlm

  • Non-streaming path: in _model_response_to_generate_content_response, read reasoning_content / reasoning from choices[0].message (supporting both dict- and object-style messages) and assign it to llm_response.reasoning when present.
  • Streaming path: in generate_content_async(..., stream=True), accumulate reasoning_content / reasoning from choices[0].delta across chunks into a reasoning_text buffer and pass it as reasoning when yielding partial and final LlmResponse objects.

With this local patch applied, events emitted by ADK now expose a reasoning field whenever the underlying LiteLLM response includes reasoning, and downstream consumers are able to display the model's reasoning traces as expected.

This was verified both in an application consuming ADK and directly via adk web, where the patched ADK shows a reasoning field in the event payload, while the unpatched 1.19.0 build does not.

[kushalbhabra]

+1 Facing same issue.

[surajksharma07]

@mikkokirvesoja Thanks for the comprehensive analysis and local patch verification!
You're absolutely right - ADK needs a reasoning: Optional[str] field in LlmResponse to expose the reasoning_content that LiteLLM already provides.
Your proposed solution (adding the field to LlmResponse and populating it in both streaming/non-streaming paths of the LiteLlm adapter) is exactly the right approach.
We'll look more into it and really appreciate the detailed investigation and working patch you've provided!

[surajksharma07]

@wyf7107 Please have a look into it.

[mikkokirvesoja]

@surajksharma07 @wyf7107 Did some testing today and forked repo and tested against main branch -> test passed!
Did some digging and found out that this -> 31cfa3b fixes problem.

So my original test was with 1.19.0 not current main branch with updates. Sorry for hassle but this is going to be fixed soon with next release.

If nothing, I can confirm with my tests that commit 31cfa3b fixes this.

Though still not working with LM Studio v1 API with streaming on but that's not ADK issue.

[mikkokirvesoja]

Update: Additional Testing with LM Studio

I've conducted further testing to verify reasoning content support across different providers and discovered an important detail about LM Studio's implementation.

Testing Setup

Tested LM Studio's native API (/api/v0/chat/completions) with model openai/gpt-oss-20b to compare reasoning field behavior in both streaming and non-streaming modes.

Key Findings

LM Studio uses reasoning field instead of reasoning_content:

Non-Streaming Response

{
  "choices": [{
    "message": {
      "role": "assistant",
      "content": "...",
      "reasoning": "We need to answer with step-by-step reasoning...",
      "tool_calls": []
    }
  }]
}

Streaming Response

LM Studio does send reasoning in streaming chunks via the reasoning field in deltas:

{
  "choices": [{
    "delta": {
      "reasoning": "...",
      "content": "...",
      "role": "assistant"
    }
  }]
}

Impact on ADK

The current ADK implementation (as of commit 31cfa3b8) only checks for reasoning_content:

def _extract_reasoning_value(message: Message | Dict[str, Any]) -> Any:
  """Fetches the reasoning payload from a LiteLLM message or dict."""
  if message is None:
    return None
  if hasattr(message, "reasoning_content"):
    return getattr(message, "reasoning_content")
  if isinstance(message, dict):
    return message.get("reasoning_content")
  return None

This means:

• ✅ Providers using reasoning_content - Works with current ADK
• ❌ LM Studio (uses reasoning) - Does NOT work with current ADK

Proposed Fix

Update _extract_reasoning_value() in src/google/adk/models/lite_llm.py to check for both field names:

def _extract_reasoning_value(message: Message | Dict[str, Any]) -> Any:
  """Fetches the reasoning payload from a LiteLLM message or dict."""
  if message is None:
    return None
  
  # Check reasoning_content (some OpenAI-compatible providers)
  if hasattr(message, "reasoning_content"):
    return getattr(message, "reasoning_content")
  
  # Check reasoning (LM Studio and other OpenAI-compatible providers)
  if hasattr(message, "reasoning"):
    return getattr(message, "reasoning")
  
  if isinstance(message, dict):
    # Check both field names in dict
    return message.get("reasoning_content") or message.get("reasoning")
  
  return None

Provider Compatibility

Provider Type	Field Name	Current ADK Support
OpenAI-compatible (using reasoning_content)	reasoning_content	✅ Supported
LM Studio	reasoning	❌ Not supported
Other OpenAI-compatible providers	Varies	⚠️ May vary

Recommendation

To maximize compatibility with different LiteLLM providers, ADK should check for both reasoning_content and reasoning fields. This minimal change would enable reasoning support for LM Studio and potentially other providers that follow similar patterns.

Test Results

Full test results available showing:

• LM Studio v0 API responses with reasoning field
• Confirmation that reasoning appears in both streaming and non-streaming modes
• Comparison with other OpenAI-compatible providers using reasoning_content

The fix is straightforward and maintains backward compatibility while extending support to additional providers.

[surajksharma07]

@mikkokirvesoja Great catch on the LM Studio difference,You're right that checking both reasoning_content and reasoning fields would maximize provider compatibility.
The implementation you proposed looks solid - checking both field names is a clean way to support different provider conventions.
Thanks for the thorough testing and clear code example - this will help ensure reasoning works across more LiteLLM providers!
we are looking more into it.

[mikkokirvesoja]

After researching the OpenAI-compatible API ecosystem, it appears there is no single official standard for reasoning field names. Different providers use different conventions, though reasoning_content is the most widely adopted.

Provider	Field Name	Source
LiteLLM (Standard)	reasoning_content	Official LiteLLM spec
Microsoft Azure/Foundry	reasoning_content	Microsoft docs
vLLM	reasoning	vLLM docs
LM Studio	reasoning	My testing
Ollama (via LiteLLM)	reasoning_content	My testing shows that LiteLLM extracts from <think> tags
Ollama (direct)	None	Embedded in content with <think> tags

I'll defer to the ADK team on the best approach here. The question is: should this be considered a provider-side issue (providers should standardize on reasoning_content), or should ADK be more flexible to support both conventions?

Happy to open a PR with the dual-field check if that aligns with ADK's compatibility goals. Let me know what you decide!

[surajksharma07]

@mikkokirvesoja Thanks for the comprehensive ecosystem research.
Given the provider fragmentation you've documented, supporting both field names makes sense from a pragmatic standpoint - it maximizes compatibility at minimal cost.
We'd absolutely welcome a PR with the dual-field check you proposed.