Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Provider compatibility] OpenCode Go DeepSeek V4.1 Flash returns reasoning_content 400 after WorkBuddy tool calls (2.86.0)

Closed
  • Is something wrong?
#7,118 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
22/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
api

Research direction

The failing path is the native openai-chat adapter handling tool-call continuation, with preserveReasoningContentModels as the config involved; the payload does not name specific files, so start by finding where that setting and the adapter's message serialization live. The open question is whether assistant tool-call history keeps a nonempty reasoning_content when the tool result is sent back. Done would mean a reproduction against deepseek-v4.1-flash that succeeds past tool execution, with the upstream 400 no longer returned.

Written by the indexing model from the issue text.

Description

provider provider-compatibility tools
Client or integration

Other — WorkBuddy configured as an OpenAI Compatible / Chat Completions client.

Provider or upstream service

OpenCode Go (opencode-go, openai-chat adapter; https://opencode.ai/zen/go/v1).

OpenCodex version

2.86.0

Endpoint or capability

/v1/chat/completions — DeepSeek V4.1 Flash thinking-mode tool-call continuation / reasoning_content replay.

Current behaviour

A fresh WorkBuddy conversation using opencode-go/deepseek-v4.1-flash initially works, but fails with HTTP 400 during tool-call continuation. A resumed conversation fails as well. The upstream rejects the request because reasoning_content in thinking mode was not passed back.

This occurs with requestedEffort: high and with no explicit reasoning effort. Adding deepseek-v4.1-flash to preserveReasoningContentModels did not resolve it.

Control: Switching only the model to opencode-go/deepseek-v4-flash allows tool calls to work in the same WorkBuddy → OpenCodex → OpenCode Go setup.

The error-summary trace shows native Chat → Chat routing (same-wire-native), not Responses-to-Chat translation. The available summary does not include the serialized messages, so the exact layer that drops or rejects reasoning history is not yet confirmed.

Expected behaviour

Tool-call continuation for deepseek-v4.1-flash should preserve or correctly relay the thinking metadata required by the upstream API, or clearly report an unsupported combination instead of failing after tool execution. Behaviour should be consistent with the working deepseek-v4-flash route where compatible.

Minimal redacted request or reproduction
1. OpenCodex 2.86.0, provider opencode-go:
   adapter: openai-chat
   baseUrl: https://opencode.ai/zen/go/v1
   preserveReasoningContentModels includes:
     deepseek-v4-flash, deepseek-v4.1-flash
2. Connect WorkBuddy through its OpenAI Compatible (Chat Completions) integration.
3. Start a NEW conversation with model opencode-go/deepseek-v4.1-flash.
4. Ask it to perform a task requiring a tool call and continue after the tool result.
5. Observe HTTP 400 requiring reasoning_content to be passed back.
6. Repeat with high reasoning effort and with no explicit reasoning effort: both fail.
7. Start another new conversation, changing only model to
   opencode-go/deepseek-v4-flash: tool calling succeeds.

Request summary on failing attempts:
  inboundProtocol: chat
  adapter: openai-chat
  protocolTrace.inbound: chat
  protocolTrace.upstream: chat
  protocolTrace.mode: native
  protocolTrace.reasonCodes: [same-wire-native]
  protocolTrace.featureEffects: request.tools = passthrough
  failureCause: payload-rejected
  resendPermission: refused-futile

Note: A raw HTTP request body is not available yet; this is a
client-level reproduction plus a redacted OpenCodex request summary.
Actual response or error
HTTP 400 invalid_request_error
Provider error 400: Upstream request failed:
[invalid_request_error] The `reasoning_content` in the thinking mode
must be passed back to the API.

failureStage: headers-only
failureCause: payload-rejected
attempts: 1
Upstream documentation

OpenCode Go service: https://opencode.ai/zen/go

No public OpenCode Go-specific specification for the required deepseek-v4.1-flash thinking/tool-call replay payload has been verified. The error itself explicitly requires returning reasoning_content in thinking-mode history.

Suggested mapping or implementation notes

Please inspect the native openai-chat tool-call continuation path and compare the inbound/outbound message structure for deepseek-v4.1-flash versus the working deepseek-v4-flash. In particular, check whether assistant tool-call history retains a nonempty reasoning_content when the tool result is submitted. This may be a client-history issue, proxy replay/serialization issue, or an upstream model-specific contract; current evidence does not establish which.

Additional context and attachments

Related historical issues: #950, #1193, #5421, #4632. Unlike the subagent/Responses cases, this reproduction is WorkBuddy over native Chat → Chat, and it also reproduces in a fresh conversation.

Environment: macOS (exact OS release not recorded).

Checks
  • I searched existing provider and compatibility issues.
  • The request and response were redacted.
  • The expected behaviour is based on an upstream specification or a concrete client requirement.
Dominant language
TypeScript
Stars
16.9k
Forks
1.3k
Avg merge
9h 16m
Merged PRs (30d)
623

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lidge-jun/opencodex

All issues in lidge-jun/opencodex

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.