Add Reasoning Content support to OpenAiChatModel and related classes (For deepseek-reasoner)

[apappascs]

trafficstars

This PR resolves: https://github.com/spring-projects/spring-ai/issues/2283 by adding reasoning content support to OpenAiChatModel and related classes, following the approach of this https://github.com/spring-projects/spring-ai/commit/45421b1c93bbf19f5d7c5871f5064c9a4df8b067 .

Reasoning Content Details

reasoning_content : string / nullable  
For DeepSeek-Reasoner model only. Represents the reasoning contents of the assistant's message before the final answer.  

Refer to the DeepSeek API documentation for more details: API Docs.

Changes in This PR • Added reasoningContent field to metadata in OpenAiChatModel. • Updated ChatCompletionMessage to include reasoningContent.

With this implementation, we can build projects like DeepClaude, enabling the integration of DeepSeek R1’s logical reasoning capabilities with Anthropic Claude’s (or any other model’s) creative and coding prowess. This will provide a powerful, combined language model experience.

[markpollack]

I think the number of changes that are occuring to make the openai model compatible with other models is starting to go too far, divergence starts to seem inevitable. We should look to make it easy to extend the openai model support for different dedicated variations with minimal code, as compared to the current full blown cut and paste approach. Moving this to the RC1 release so that we can better support deepseek as it's own first class model.

[apappascs]

I think the number of changes that are occuring to make the openai model compatible with other models is starting to go too far, divergence starts to seem inevitable. We should look to make it easy to extend the openai model support for different dedicated variations with minimal code, as compared to the current full blown cut and paste approach. Moving this to the RC1 release so that we can better support deepseek as it's own first class model.

Hi @markpollack

Thanks for the feedback on the PR—makes total sense.

Just to make sure I fully understand your intention before moving forward—are you suggesting that instead of adapting the existing spring-ai-openai module for DeepSeek compatibility, we should treat DeepSeek as its own first-class model (like spring-ai-mistral-ai, spring-ai-moonshot, etc.) and place it under models/spring-ai-deepseek or something similar?

Let me know if that’s the direction you had in mind, or if you’d prefer another approach. Once confirmed, I’m happy to take the lead on the implementation.

Thanks again!

[LinkCaau]

When using OpenAI compatibility mode, some models may extend the protocol, and the rapid development of large models makes it difficult for frameworks like Spring AI to adapt quickly and flexibly. Is there a better way to achieve a permanent solution?
Examples:

1. DeepSeek added a reasoning_content field.
2. QianFan finish_reason field add a new type normal, but since the type is fixed as ChatCompletionFinishReason, it causes serialization failures.

[markpollack]

Hi @apappascs

yes, you understood me correctly.

Please take a look at the comment here - https://github.com/spring-projects/spring-ai/issues/2116#issuecomment-2813935853

and let me know how you want to proceed. As I'm going through the issues and doing triage, I see more and more of these deepseek issues that suggest it may take a bit of time to get the implementation stable in time for RC1 next May 13

I suggest first going into the spring-ai-community and then moving it over into spring-ai once it matures.

@mxsl-gr

[apappascs]

Hi @markpollack,

Thanks for confirming.

I’ll get started on it. I believe we can have the implementation ready directly in spring-ai before the RC1 deadline on May 13. The spring-ai-community route does seem like a safer fallback if needed, but the goal is to have it solid enough to go straight into the main project.

[markpollack]

@apappascs it seems like a community project to get active incubation and feedback would be the most effective route. I suspect we will eventually need a ReasoningClient as well - will be interesting to see how it turns out.

https://github.com/spring-ai-community/community/issues

[markpollack]

@mxsl-gr @apappascs There is now a deepseek model in spring ai to handle this without interfering with the OpenAiChatModel. Closing this as any changes should be in that part of the code base.

thanks!