Python/OpenAI-compatible: preserve and replay DeepSeek reasoning_content across tool-calling loops

[codex4010]

Summary

agent-framework-openai appears to lose or mis-handle provider-specific reasoning payloads in OpenAI-compatible tool-calling loops, which breaks DeepSeek thinking-mode requests with:

400 invalid_request_error: The `reasoning_content` in the thinking mode must be passed back to the API.

This shows up in Python agent/sub-agent flows that use tool calling. The root problem is that DeepSeek returns reasoning_content, while the current OpenAI chat completion path only natively works with reasoning_details.

Why this matters

DeepSeek's thinking/tool-calling protocol is stricter than the common OpenAI-compatible assumption:

• if a thinking-mode response includes tool calls, subsequent requests in the same reasoning flow must carry forward the prior reasoning_content
• if that payload is dropped or replayed incorrectly, the next request fails with 400

This is not just a product-specific quirk. Similar issues have appeared in other frameworks and OpenAI-compatible integrations when reasoning_content is ignored or not replayed.

Observed behavior

In Python agent-framework-openai tool loops:

1. provider returns assistant message with tool_calls plus reasoning_content
2. framework parses tool calls, but does not fully preserve/replay the provider-specific reasoning payload through the function invocation loop
3. after tool execution, the next model request is sent without the correct DeepSeek-style reasoning replay
4. DeepSeek rejects the request with:

The `reasoning_content` in the thinking mode must be passed back to the API.

Notes

This is especially easy to hit in:

• tool-calling loops
• sub-agent/tool delegation flows
• streaming reasoning chunk accumulation
• OpenAI-compatible gateways where the model/base URL does not obviously identify DeepSeek, but the provider still returns reasoning_content

Expected behavior

The framework should treat provider reasoning replay as a first-class compatibility concern in the OpenAI-compatible client layer:

• parse non-standard reasoning fields such as reasoning_content
• preserve them across tool-calling iterations
• accumulate streaming reasoning chunks correctly
• replay them in the provider-specific outbound shape on subsequent requests

Suggested direction

A robust fix probably belongs in agent-framework-openai, not in app-level code:

• map provider reasoning payloads into a stable internal representation
• preserve them through function invocation / tool loops
• emit reasoning_content for providers that use that protocol, instead of assuming reasoning_details
• avoid relying only on model/base URL heuristics when capability can be detected from observed responses

Environment

• package: agent-framework-openai==1.1.1
• package: agent-framework-core==1.1.1
• Python: 3.14
• provider: DeepSeek via OpenAI-compatible Chat Completions API

Related references

• DeepSeek thinking mode docs: https://api-docs.deepseek.com/guides/thinking_mode
• DeepSeek reasoning model docs: https://api-docs.deepseek.com/guides/reasoning_model
• Similar ecosystem reports:
  • [Bug]: ChatOpenAI silently drops 'reasoning_content' from OpenAI-compatible providers (vLLM/DeepSeek) langchain-ai/langchain#35059
  • DeepSeek Reasoner tool-use fails in n8n with 400 Missing reasoning_content (regression after DeepSeek V3.2) n8n-io/n8n#22579

[zy8008]

This issue also occurs in the .NET version
Libary version:

• Microsoft.Agents.AI 1.3.0
• Microsoft.Agents.AI.OpenAI 1.3.0