reasoning_content
A response field in DeepSeek thinking mode that stores the model's reasoning process separately from the regular content. It is used in multi-turn tool loops to maintain the reasoning-state context.
Timeline (last 90 days)
For reasoning models, Eino maps reasoning_content in the response to out.ReasoningContent, and inline <think> tags are kept in out.Content; the framework does not strip them.
When using tools, the reasoning_content of every assistant turn in the history must be passed back verbatim (including turns where no tool call was initiated), otherwise an HTTP 400 is returned; when tools are not used, this field is ignored.
The field name for thinking content has three forms in the ecosystem: reasoning, reasoning_content, and thinking; vLLM writes reasoning_content, while the reading side only looks for reasoning, causing a false empty response.
The most reliable way to fix the 400 error is to append the complete assistant message object (e.g., messages.append(resp.choices[0].message) in Python) rather than manually assembling a copy.
In DeepSeek thinking mode, the reasoning_content field stores the model's reasoning process before the final answer, and when the request carries tools, this field in historical assistant messages must be sent back verbatim.
Most client SDKs or in-house message serializers keep only the OpenAI-standard content and tool_calls fields and discard the non-standard extension field reasoning_content, which is the structural reason the 400 error keeps recurring in projects such as opencode, LangChain and claude-code-router.
On DeepSeek's own API, tool calls in thinking mode must send back the reasoning_content of the historical assistant message in every turn, otherwise a 400 is returned.
All Facts (7)
On DeepSeek's own API, tool calls in thinking mode must send back the reasoning_content of the historical assistant message in every turn, otherwise a 400 is returned.
60%UnverifiedFor reasoning models, Eino maps reasoning_content in the response to out.ReasoningContent, and inline <think> tags are kept in out.Content; the framework does not strip them.
50%UnverifiedWhen using tools, the reasoning_content of every assistant turn in the history must be passed back verbatim (including turns where no tool call was initiated), otherwise an HTTP 400 is returned; when tools are not used, this field is ignored.
50%UnverifiedThe field name for thinking content has three forms in the ecosystem: reasoning, reasoning_content, and thinking; vLLM writes reasoning_content, while the reading side only looks for reasoning, causing a false empty response.
50%UnverifiedThe most reliable way to fix the 400 error is to append the complete assistant message object (e.g., messages.append(resp.choices[0].message) in Python) rather than manually assembling a copy.
50%UnverifiedIn DeepSeek thinking mode, the reasoning_content field stores the model's reasoning process before the final answer, and when the request carries tools, this field in historical assistant messages must be sent back verbatim.
50%UnverifiedMost client SDKs or in-house message serializers keep only the OpenAI-standard content and tool_calls fields and discard the non-standard extension field reasoning_content, which is the structural reason the 400 error keeps recurring in projects such as opencode, LangChain and claude-code-router.
50%