DeepSeek V4: reasoning_content lost on second interleaved pass (regression from #24146)

[claudianus]

Bug Description

PR #24146 fixed empty reasoning_content for DeepSeek V4 by unconditionally setting providerOptions[sdk][field] = reasoningText in the interleaved transform. However, this introduced a regression: on the second pass through the transform (after DB storage), content parts no longer have reasoning blocks (already extracted in first pass), so reasoningText is empty. The unconditional set overwrites the previously correct providerOptions.reasoning_content, causing DeepSeek 400:

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

Steps to Reproduce

1. Configure DeepSeek V4 Pro (deepseek/deepseek-v4-pro) with thinking mode
2. Run a multi-turn conversation with tool calls (e.g., Sisyphus agent making multiple delegate_task calls)
3. After the first tool-result → assistant response round-trip, the second request to DeepSeek will fail with 400

Root Cause

The interleaved transform runs on every request:

• First pass: Content has reasoning parts → extracts reasoning → stores in providerOptions → removes from content ✅
• Second pass (after DB round-trip): Content has no reasoning parts → reasoningText = "" → unconditionally overwrites providerOptions.reasoning_content → reasoning lost ❌

Expected Behavior

On the second pass, when reasoningText is empty, fall back to the existing providerOptions[sdk][field] value instead of overwriting with empty string.

Related

• fix: preserve empty reasoning_content for DeepSeek V4 thinking mode #24146 — initial fix for empty reasoning_content
• Bug: DeepSeek reasoning_content not passed back in multi-turn conversations #24261 — original bug report for missing reasoning_content in multi-turn
• fix(provider): complete DeepSeek reasoning_content round-trip for multi-turn conversations #24250 — alternative PR addressing similar issue
• [DeepSeek V4] reasoning_content not round-tripped — 400 error on multi-turn tool calls #24190 — same 400 error on multi-turn tool calls

Environment

• DeepSeek V4 Pro (deepseek-v4-pro)
• OpenCode dev branch
• models.dev provider (@ai-sdk/openai-compatible)

[edulml98]

the issue is on openrouter side: OpenRouterTeam/ai-sdk-provider#487
already merged, waiting for the release: #24435

[claudianus]

Not an OpenRouter issue — we reproduced the exact same 400 error using DeepSeek's official API (api.deepseek.com/v1), not OpenRouter.

Repro steps with official API:

• Direct curl to https://api.deepseek.com/v1/chat/completions with deepseek-reasoner (V4 Pro) thinking mode
• First turn: model returns reasoning_content in response — ✅
• Second turn: we pass history back WITHOUT reasoning_content in the assistant message → 400: "The reasoning_content in the thinking mode must be passed back to the API"

Root cause: OpenCode's interleaved transform (in provider.ts) unconditionally overwrites providerOptions.reasoning_content on the second pass. First pass extracts reasoning from content parts → stores in providerOptions ✅. After DB round-trip, content has no reasoning parts → reasoningText = "" → unconditionally overwrites existing providerOptions.reasoning_content → reasoning lost → 400 ❌

This is a provider-layer bug in OpenCode, not specific to OpenRouter. The interleaved transform needs to fall back to existing providerOptions[sdk][field] when reasoningText is empty on subsequent passes.

(We also tested OpenRouter as a control — same 400, plus OpenRouter has an additional bug where it strips empty reasoning: "" strings before forwarding to DeepSeek.)

[edulml98]

I have use Opencode v1.14.25 using deepseek official api with a 14m tokens sessions and i didnt encounter any issue. Using deepseek v4 pro max effort

deepseek-reasoner routes to deepseek-v4-flash as you can see in their docs: https://api-docs.deepseek.com/quick_start/pricing "* The model names deepseek-chat and deepseek-reasoner will be deprecated in the future. For compatibility, they correspond to the non-thinking mode and thinking mode of deepseek-v4-flash, respectively."

[claudianus]

Reproduced with DeepSeek official API + correct model ID deepseek-v4-pro.

@edulml98 — the 400 does NOT occur in simple text multi-turn, but DOES occur with tool calls, which is the exact OpenCode bug scenario:

Reproduction (official API, deepseek-v4-pro)

Turn 1: tool call triggered → reasoning_content returned, content empty ✅
Turn 2: assistant msg passed WITHOUT reasoning_content + tool_result → 400: The reasoning_content in the thinking mode must be passed back to the API.

Why simple text works but tool calls don't

When there's no tool call, Turn 1 content is non-empty, and DeepSeek may not strictly validate reasoning_content in history. But with tool calls, content is empty and the API REQUIRES reasoning_content to be preserved in subsequent turns.

Conclusion

This is NOT an OpenRouter-only issue. The bug is in OpenCode's interleaved transform dropping reasoning_content on the second pass — fix needed in provider.ts, not just an SDK bump.

[knefenk]

Reproduced and confirmed this regression.

Trace:

Pass 1 (raw API response): Content has reasoning parts -> transform extracts reasoningText -> sets providerOptions.reasoning_content -> strips reasoning from content ✓

Pass 2 (after DB round-trip): Content has NO reasoning parts (stripped in pass 1) -> reasoningText = "" -> unconditionally overwrites existing providerOptions.reasoning_content -> empty string sent to DeepSeek -> 400 ✗

Wrote standalone reproduction testing all three code paths (upstream dev post-#24146, PR #24250, fixed version). Results:

• Upstream dev (post-fix: preserve empty reasoning_content for DeepSeek V4 thinking mode #24146): ✗ DeepSeek block re-adds empty reasoning parts, interleaved extracts empty -> overwrites
• PR fix(provider): complete DeepSeek reasoning_content round-trip for multi-turn conversations #24250 (knefenk): ✗ same bug — unconditional [field]: reasoningText overwrites
• Fixed (swap spread order): ✓ preserved — existing providerOptions values take priority

Fix pushed to PR #24250: sets [field]: reasoningText first, then spreads existing providerOptions[sdk] over it. This is equivalent to the reasoningText || existingField || "" approach in #24443 but using JS spread semantics. Either PR works — maintainer just needs to merge one.

[claudianus]

@knefenk — thanks for the independent reproduction and trace. Your analysis matches ours exactly:

Pass 1 extracts reasoningText → sets providerOptions → strips from content ✓
Pass 2 content has no reasoning parts → reasoningText = "" → unconditionally overwrites → 400 ✗

The fix in PR #24443 (swap spread order: set [field]: reasoningText first, then spread existing providerOptions[sdk] over it) covers the same ground as your #24250 fix. Either approach works — the key insight is that existing providerOptions values must take priority over the (potentially empty) re-extracted reasoningText.

cc @edulml98 — this confirms the bug is in OpenCode's provider layer (not OpenRouter-specific), reproducible with official DeepSeek API + deepseek-v4-pro + tool calls.

[kipropbrian]

There is definitely a bug in openrouter too, this bug affects all other coding agents too if you check their recent issue logs, as rekram stated in #24190 he spoke to the open router guys and they fixed the issue on their side too. So lets wait for him to do the release.

[claudianus]

@kipropbrian — respectfully, this is not primarily an OpenRouter issue. Heres why:

1. Reproduced with DeepSeek official API (api.deepseek.com/v1, model deepseek-v4-pro)

The 400 error was reproduced with DeepSeeks official API endpoint — no OpenRouter involved:

• Turn 1: tool call triggered → reasoning_content returned, content empty ✅
• Turn 2: assistant msg passed WITHOUT reasoning_content + tool_result → 400: The reasoning_content in the thinking mode must be passed back to the API.

2. Why simple text chats dont trigger it

When content is non-empty (no tool calls), DeepSeek may not strictly validate reasoning_content in history — explaining why 14M-token sessions work fine. But with tool calls (content is empty), the API requires reasoning_content to be preserved in subsequent turns.

3. Two separate bugs exist

• OpenRouter bug (fix: preserve empty reasoning_details arrays in multi-turn conversations OpenRouterTeam/ai-sdk-provider#487): OpenRouter strips empty reasoning: "" strings before forwarding to DeepSeek — this is what rekram discussed and they fixed.
• OpenCode provider-layer bug (this issue): OpenCodes interleaved transform in provider.ts unconditionally overwrites providerOptions.reasoning_content on the second pass with an empty string. After DB round-trip, content has no reasoning parts → reasoningText = "" → overwrites existing providerOptions.reasoning_content → 400.

4. Fixing OpenRouter alone is insufficient

Even after OpenRouter releases their fix, users on DeepSeeks official API will still hit this bug. The OpenCode provider-layer fix (PR #24443 or #24250) is needed regardless.

5. Independent confirmation

@knefenk independently reproduced and traced the exact bug path in OpenCodes provider.ts, confirming the unconditional overwrite on pass 2.

---

Bottom line: Two bugs, two fixes. OpenRouters release fixes their side; OpenCode needs its own fix for the provider layer. Waiting for OpenRouter alone leaves official API users broken.

[runnig]

When is the release for the fixes?

[claudianus]

Hey @runnig — good question.

There are two fixes in play:

1. OpenRouter SDK fix (fix: preserve empty reasoning_details arrays in multi-turn conversations OpenRouterTeam/ai-sdk-provider#487): Already merged by OpenRouter team. Waiting for their release cycle. This fixes the OpenRouter-specific bug where empty reasoning: "" strings were stripped before forwarding.

2. OpenCode provider-layer fix (PR fix(provider): preserve reasoning_content on second interleaved pass (#24146 follow-up) #24443, also PR fix(provider): complete DeepSeek reasoning_content round-trip for multi-turn conversations #24250 by @knefenk): Open and ready for review. Both PRs fix the same core issue — the interleaved transform in provider.ts unconditionally overwrites providerOptions.reasoning_content on the second pass. This affects users on DeepSeek official API as well as OpenRouter.

Timeline: The OpenCode fix needs a maintainer (@rekram or team) to review and merge one of the two PRs. I do not have visibility into their release schedule. Once merged, it would go out in the next OpenCode release.

In the meantime:

• If you are on OpenRouter: their upcoming release should mitigate the issue for non-tool-call scenarios
• If you are on DeepSeek official API or use heavy tool calls: the OpenCode provider fix is required regardless

Hope that helps clarify!