Description

When using DeepSeek V4 models through a proxy provider like OpenCode Zen (opencode-native endpoint class), the agent gets stuck on tool calls. The root cause is that reasoning_content from the assistant's response is not preserved in follow-up requests after tool execution.

Root Cause

The DeepSeek V4 API requires reasoning_content to be echoed back in the assistant message when continuing the conversation after tool calls. If missing, it returns a 500 error.

Code Analysis

In openai-transport-stream.ts, shouldPreserveReasoningContentReplay() checks three conditions:

1. compat.requiresReasoningContentOnAssistantMessages — set when isDeepSeek or isXiaomi in compat detection
2. compat.thinkingFormat === "deepseek" — same
3. Model ID in REASONING_CONTENT_REPLAY_MODEL_IDS set

Problem 1: isDeepSeek checks endpointClass === "deepseek-native" — but when DeepSeek models are accessed through a proxy like OpenCode Zen, the endpoint class is "opencode-native", not "deepseek-native". So conditions 1 and 2 both fail.

Problem 2: The REASONING_CONTENT_REPLAY_MODEL_IDS set lists deepseek-v4-flash but not deepseek-v4-flash-free or big-pickle (also DeepSeek-based models).

Problem 3: In getCompat(), requiresReasoningContentOnAssistantMessages is hardcoded to auto-detected only, not allowing model compat override.

Suggested Fix

1. Add deepseek-v4-flash-free and big-pickle to REASONING_CONTENT_REPLAY_MODEL_IDS
2. OR extend isDeepSeek detection to recognize DeepSeek models through proxy endpoints

Steps to Reproduce

1. Configure OpenCode Zen provider with deepseek-v4-flash-free model
2. Send a message requiring tool use
3. Agent gets stuck after executing tools — API returns 500 about missing reasoning_content