cc @nabinchha

Priority Level

Medium

Task Summary

DataDesigner currently depends on LiteLLM to normalize reasoning-model responses into reasoning_content. This is not an immediate break today, but it will become a compatibility issue as we continue the LiteLLM removal work.

Specifically, vLLM >= 0.16.0 has moved toward message.reasoning as the canonical field and treats reasoning_content as deprecated/backward-compat. LiteLLM currently masks this for us by mapping reasoning back to reasoning_content. Once we bypass/remove LiteLLM, our direct adapters/parsers will miss reasoning traces unless we add native support for both field names.

Technical Details & Implementation Plan

Current DataDesigner code only reads reasoning_content in several core paths, including:

• packages/data-designer-engine/src/data_designer/engine/models/clients/parsing.py
• packages/data-designer-engine/src/data_designer/engine/models/facade.py
• packages/data-designer-engine/src/data_designer/engine/mcp/facade.py
• packages/data-designer-engine/src/data_designer/engine/column_generators/generators/llm_completion.py

This means the current behavior is:

• Today, with LiteLLM in the path: mostly OK
  • LiteLLM normalizes OpenAI-compatible reasoning -> reasoning_content
  • self-hosted vLLM reasoning models should continue to work through the current bridge
• After LiteLLM removal / direct provider handling: latent bug becomes real
  • NDD will silently drop reasoning traces for providers returning message.reasoning
  • {column_name}__reasoning_content extraction will become None
  • MCP/tool-use traces may lose reasoning propagation on assistant messages

Proposed fix

1. Introduce a small shared helper for assistant reasoning extraction that accepts:
   • reasoning_content
   • reasoning
   • optionally future content-block based reasoning if needed
2. Use that helper everywhere we currently read reasoning_content directly.
3. Keep NDD's internal canonical field as reasoning_content for now, so the public trace/output contract does not change.
4. Add tests covering:
   • non-streaming OpenAI-compatible response with message.reasoning only
   • streaming delta with delta.reasoning only
   • existing reasoning_content behavior remains unchanged

Why this is not urgent right now

This is not an immediate customer-facing break while LiteLLM remains in the serving path. LiteLLM currently standardizes reasoning responses to reasoning_content, so the existing DataDesigner code still works.

Why we should still do it soon

This becomes a real compatibility gap as part of LiteLLM removal. If we land direct vLLM/OpenAI-compatible parsing without this change, reasoning-model support will regress in a subtle way rather than failing loudly.

Dependencies

LiteLLM removal / direct provider adapter work