Droid BYOK drops reasoning_content for DeepSeek V4 Flash (tool-call turns → 400 error)

[RealNarcissus]

Summary of the error

When using DeepSeek V4 Flash via BYOK (generic-chat-completion-api provider), the second and subsequent turns in a tool-call conversation fail with:

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

DeepSeek V4 Flash with thinking mode enabled returns reasoning_content on assistant messages. When Droid replays the message history on the next API call, it strips this field. DeepSeek's API requires reasoning_content on every assistant message for tool-call turns, and rejects requests where it's missing.

Works: Single-turn queries, model responses without tool calls, models that don't generate reasoning_content (e.g. MiniMax, Kimi).

Fails: DeepSeek V4 Flash + tool calls + follow-up turn. V4 Pro also affected but intermittently.

Root Cause

In Droid's BYOK generic-chat-completion-api provider, when building the api_messages array for the next API request, the provider copies known fields (role, content, tool_calls) from stored messages but does not preserve reasoning_content. This is fine for most providers, but DeepSeek V4's thinking mode enforces a strict contract: reasoning_content from every assistant turn must be echoed back.

DeepSeek's own docs: https://api-docs.deepseek.com/guides/thinking_mode#tool-calls

"If your code does not correctly pass back reasoning_content, the API will return a 400 error."

Exact Fix (reference: Hermes Agent #16137, resolved)

Hermes Agent (NousResearch/hermes-agent) had this exact bug and fixed it with ~25 lines. The fix is in run_agent.py and consists of two parts:

Part 1: Detection (_needs_deepseek_tool_reasoning())

def _needs_deepseek_tool_reasoning(self) -> bool:
    provider = (self.provider or "").lower()
    model = (self.model or "").lower()
    return (
        provider == "deepseek"
        or "deepseek" in model
        or base_url_host_matches(self.base_url, "api.deepseek.com")
    )

For Droid's case, this should also check for OpenCode Go's endpoint since that's the proxy used by many users:

// Droid equivalent
function needsDeepseekToolReasoning(provider: string, model: string, baseUrl: string): boolean {
  return (
    provider === "deepseek" ||
    model.includes("deepseek") ||
    baseUrl.includes("api.deepseek.com") ||
    baseUrl.includes("opencode.ai/zen/go/v1") // OpenCode Go users
  );
}

Part 2: Preservation in message-building loop

The call site (Hermes Agent line ~10397):

api_messages = []
for msg in messages:
    api_msg = msg.copy()
    self._copy_reasoning_content_for_api(msg, api_msg)  # THIS IS THE KEY LINE
    # ... strip internal fields ...
    api_messages.append(api_msg)

Where _copy_reasoning_content_for_api (simplified):

def _copy_reasoning_content_for_api(self, source_msg, api_msg):
    if source_msg.get("role") != "assistant":
        return
    existing = source_msg.get("reasoning_content")
    if isinstance(existing, str):
        # Preserve verbatim (empty string → space to avoid rejection)
        api_msg["reasoning_content"] = existing or " "

Droid-specific fix location

In Droid's source, this needs to go wherever the BYOK generic-chat-completion-api provider builds the chat completion request body from stored messages. Likely in the buildRequestBody or convertToApiMessages function in the BYOK provider code path.

The fix is literally:

// In the message conversion loop, after copying msg to apiMsg:
+ if (needsDeepseekToolReasoning(provider, model, baseUrl) && msg.role === 'assistant' && msg.reasoning_content) {
+   apiMsg.reasoning_content = msg.reasoning_content;
+ }

Related Issues

• deepseek-v4-flash 400 error with thinking mode + tool calls #1018 — deepseek-v4-flash 400 error with thinking mode + tool calls
• BYOK DeepSeek-V4: 400 'reasoning_content must be passed back' with both anthropic and generic-chat-completion-api providers #1060 — BYOK DeepSeek-V4: 400 with both anthropic and generic-chat-completion-api providers

[zwen64657]

You can just add "anthropic" to the address and port.

[RealNarcissus]

You can just add "anthropic" to the address and port.

I think that only works with deepseek api key. I am trying with opencode's api.

[RealNarcissus]

Update after further investigation:

Tried the Anthropic-endpoint workaround suggested by another commenter (changing provider to anthropic and baseUrl to https://opencode.ai/zen/go/anthropic). Got a 404 — OpenCode GO's proxy does not expose an /anthropic sub-path. That workaround only applies when hitting DeepSeek's API directly at api.deepseek.com/anthropic.

Also confirmed: changing only provider to anthropic while keeping baseUrl as https://opencode.ai/zen/go/v1 gives the same original 400 error.

Root cause is in the proxy, not just Droid: OpenCode GO's zen/go/v1 proxy forwards to DeepSeek but does not echo reasoning_content back on subsequent turns. This means even if Droid's BYOK provider preserves reasoning_content in the message history, the proxy is likely stripping it before it reaches DeepSeek's API — or not injecting it on the outbound leg.

Two-layer fix needed:

1. Droid side: Preserve reasoning_content in the api_messages build loop for DeepSeek-identified endpoints (as described above). The detection should include opencode.ai/zen/go/v1 as a known DeepSeek proxy.
2. OpenCode GO side: Their proxy needs to handle the reasoning_content passthrough. Filed separately with them.

Workaround that works today: Use a direct DeepSeek API key with baseUrl: https://api.deepseek.com/anthropic and provider: anthropic. Bypasses both issues entirely. Not ideal for GO subscribers.

Why V4 Pro works intermittently: Likely because Pro's thinking budget is allocated differently and some requests don't produce reasoning_content at all (no thinking triggered), so the missing echo doesn't cause a 400 on those turns.

[fakhriaunur]

Same issue. I use opencode zen and go for DS.

Workaround using deepseek-v4-pro model ID aliased to Flash backend works (I use cliproxyapi, but any thin wrapper for model aliasing works imho) -- proves problem isn't BYOK path (pro works fine via BYOK too). Root cause: deepseek-v4-flash simply isn't in Factory's model registry. Pro is, so it gets native reasoning_content handling regardless of BYOK vs official. Flash doesn't.

So yeah, for permanent Fix: add deepseek-v4-flash to Factory's native model list.

[zwen64657]

同样的问题。我用OpenCode Zen，选择数据科学。

用模型ID锯齿到Flash后端的替代方案是可行的（我用cliproxyapi，但我觉得任何模型锯齿的薄包装都行）——证明问题不在BYOK路径（Pro通过BYOK也能正常使用）。根本原因：工厂的型号注册表里根本没有。优点是，所以无论BYOK还是官方，都能用原生reasoning_content处理。闪电侠没有。deepseek-v4-pro``deepseek-v4-flash

所以，是的，永久修复：添加到工厂原生模型列表。deepseek-v4-flash

Just connect directly to the official API.

[zwen64657]

同样的问题。我用OpenCode Zen，选择数据科学。
用模型ID锯齿到Flash后端的替代方案是可行的（我用cliproxyapi，但我觉得任何模型锯齿的薄包装都行）——证明问题不在BYOK路径（Pro通过BYOK也能正常使用）。 根本原因：工厂的型号注册表里根本没有。 优点是，所以无论BYOK还是官方，都能用原生reasoning_content处理。 闪电侠没有。 deepseek-v4-prodeepseek-v4-flash ``
所以，是的，永久修复：添加到工厂原生模型列表。deepseek-v4-flash

直接连接到官方API。

The official API is also very affordable—I can't imagine why one wouldn't use it, especially since there are no compatibility issues to worry about.