DeepSeek v4 Pro via OpenCode Go: "reasoning_content in thinking mode must be passed back" errors in KinBot

[klausnitsche]

Summary

When using DeepSeek v4 Pro as a model for Kins with thinking enabled, connected via the OpenCode Go OpenAI-compatible endpoint, KinBot frequently returns the following provider error instead of a normal response:

⚠️ Error from provider (DeepSeek): The reasoning_content in the thinking mode must be passed back to the API.

This currently happens across many clients integrating DeepSeek, and it seems KinBot currently does not propagate reasoning_content from DeepSeek responses back into subsequent API calls as required by the DeepSeek API contract.

Expected behavior

• When using DeepSeek v4 Pro (or other DeepSeek reasoning models) with thinking enabled via OpenCode Go:
  • KinBot should correctly preserve and resend the reasoning_content field that DeepSeek returns in assistant messages when the next turn is sent to the provider.
  • End users should not see the low-level provider error; instead, the model should continue the conversation normally.

Actual behavior

• As soon as DeepSeek enters thinking mode:

  • DeepSeek responses include a reasoning_content field in the assistant message.

  • On the next turn, KinBot does not pass this reasoning_content back to DeepSeek.

  • DeepSeek (via OpenCode Go) rejects the call and returns:

    Error from provider (DeepSeek): The `reasoning_content` in the thinking mode must be passed back to the API.
    

• The error is surfaced directly to the user in the chat.

Impact

• DeepSeek v4 Pro is effectively unreliable in KinBot when thinking is enabled.
• The error occurs often enough that it makes the model hard to use in practice.
• This is especially painful when trying to standardize on DeepSeek v4 Pro as a primary model via OpenAI-compatible providers (specifically OpenCode Go) across different Kins.

Probable root cause

Based on DeepSeek's public behavior and similar issues in other clients:

• DeepSeek's reasoning models require that the client:

  1. Store the reasoning_content returned on assistant messages in thinking mode.
  2. Resend that same reasoning_content in subsequent API calls for that conversation.

• KinBot's provider adapter likely:

  • Either drops reasoning_content on read (when parsing provider responses), or
  • Does not include it when reconstructing the message list for the next call.

Suggested fix (high level)

In the DeepSeek (or generic OpenAI-compatible) provider adapter within KinBot:

1. Extend message schema handling

   • When parsing assistant messages from DeepSeek, detect and persist reasoning_content alongside content.
   • Ensure the internal representation of a message can hold both fields.

2. Propagate reasoning_content on subsequent calls

   • When building the request body for the next provider call, if the previous assistant turn for DeepSeek included reasoning_content, include it again in the corresponding message in the messages array.

3. Graceful degradation / config hook

   • Optionally add a provider-level or model-level flag like supports_reasoning_content so this behavior only applies where needed.

Workarounds

• Disable thinking mode for Kins that use DeepSeek v4 Pro via OpenCode Go.
  • This avoids the error but loses the benefits of DeepSeek's reasoning mode.
• Use a different provider/model (e.g. GPT/Claude) that does not require reasoning_content to be echoed back.

Environment

• KinBot: v0.36.1 (Docker)
• Host: Synology - linux 4.4.302+ (x64), RAM ~19.5 GB
• Model: DeepSeek v4 Pro via OpenCode Go (OpenAI-compatible endpoint)
• User: Self-hosted KinBot installation (single admin user)

Additional notes

• This issue is intentionally described in provider-agnostic terms (no secrets, no internal hostnames).
• If you need more detailed logs or sanitized request/response payloads, I can capture a short failing session and attach excerpts.

[MarlBurroW]

Thanks for the detailed report @klausnitsche!

I've analyzed the codebase and can confirm the root cause: when KinBot reconstructs message history for subsequent API calls (both within multi-step turns and across turns), the reasoning_content from DeepSeek's assistant messages is not included. KinBot correctly captures reasoning tokens for display purposes, but drops them when building the messages array sent back to the API.

Starting automated implementation. The fix will involve:

1. Including reasoning content in assistant messages pushed to messageHistory between steps
2. Reconstructing reasoning content from the DB when building message history for DeepSeek providers
3. Adding DeepSeek thinking support in buildThinkingProviderOptions