Repository navigation
[Bug] DeepSeek V4 Flash Responses multi-tool continuation fails with reasoning_text 400 on 2.12.0 #1534
Description
Client or integration
Codex App
Provider or upstream service
Official DeepSeek API (https://api.deepseek.com)
OpenCodex version
2.12.0
Endpoint or capability
DeepSeek native Responses route (/responses), thinking/reasoning metadata replay, and multi-tool continuation for deepseek/deepseek-v4-flash.
Current behaviour
DeepSeek V4 Flash routed through the native Responses adapter completes plain-text turns and a simple single-tool continuation, but a controlled multi-tool continuation fails with:
The `reasoning_text` in the thinking mode must be passed back to the API.
The upstream failure is exposed to Codex App as HTTP 400, so the turn fails immediately without retrying.
The same controlled task completes successfully with DeepSeek V4 Pro.
Controlled comparison, all read-only with thinking effort high:
| Task shape | V4 Flash | V4 Pro |
|---|---|---|
| Plain-text response, no tools | Success | Success |
| Read one file using one tool, then answer | Success | Success |
| Read a local health endpoint and one file, then synthesize the result | HTTP 400 reasoning_text, turn failed |
Success |
Flash failure sequence in one conversation:
- Initial request: HTTP 200
- Tool continuation request: HTTP 200
- Later continuation request: HTTP 400 in 137 ms
Redacted request IDs:
ocx-msq223nj-7e: HTTP 200ocx-msq227gx-7p: HTTP 200ocx-msq229y1-7q: HTTP 400, 137 ms
Pro control for the same multi-tool task:
ocx-msq225tn-7l: HTTP 200ocx-msq22c1t-7r: HTTP 200- Final answer completed
Expected behaviour
Every reasoning item returned before tool calls should be preserved and replayed in the subsequent stateless DeepSeek Responses request. This must continue to hold for later continuations involving multiple tool calls/results.
The multi-tool Flash turn should complete in the same way as the plain-text, single-tool, and Pro controls.
Minimal redacted request or reproduction
# Environment:
# - Windows
# - Codex App
# - OpenCodeX 2.12.0
# - official DeepSeek provider
# - model: deepseek/deepseek-v4-flash
# - thinking effort: high
# - no explicit providers.deepseek.modelAdapters override
# In a new Codex App task, ask Flash to:
# 1. Read the local OpenCodeX health endpoint using a read-only tool:
# http://127.0.0.1:10100/healthz
# 2. Read the first line of an existing local text file using another read-only tool.
# 3. Synthesize both results in the final answer.
# Controls:
# A. Plain-text answer without tools: succeeds.
# B. Read one file with one tool, then answer: succeeds.
# C. The multi-tool sequence above: later continuation fails with HTTP 400.
# D. Repeat C using deepseek/deepseek-v4-pro: succeeds.Actual response or error
HTTP 400
{
"error": {
"message": "The `reasoning_text` in the thinking mode must be passed back to the API.",
"type": "invalid_request_error",
"param": null,
"code": "invalid_request_error"
}
}The Codex turn is marked failed and no automatic retry occurs.
Upstream documentation
- DeepSeek thinking-mode tool-call replay requirement:
https://api-docs.deepseek.com/guides/thinking_mode#tool-calls - DeepSeek Responses API compatibility:
https://api-docs.deepseek.com/guides/responses_api
The expected behaviour is also a concrete client/provider requirement: DeepSeek rejects a thinking-mode continuation when prior reasoning is not passed back.
Suggested mapping or implementation notes
Please preserve and replay the complete plaintext reasoning item for DeepSeek's stateless Responses continuation, including later continuations after multiple tool results.
OpenCodeX 2.11.1 and 2.12.0 both contain the Flash Responses registry default, so this is not caused by 2.12.0 introducing the route. OpenCodeX 2.12.0 also includes requiresAdjacentResponsesToolResults for DeepSeek, but this controlled reproduction still fails.
The persisted provider configuration uses openai-chat as its provider adapter and has no explicit modelAdapters override; Flash uses the registry default openai-responses route for Responses inbound.
Additional context and attachments
This appears related to, but is not identical to, #875:
- [Bug] DeepSeek V4 Flash Responses route stalls after tool calls #875 described a stall after tool calls with HTTP 200 and no follow-up
function_call_output. - This reproduction sends follow-up requests, but a later continuation receives an explicit HTTP 400.
Related upstream/client issue:
No secrets, raw request bodies, complete logs, configuration files, account details, or credentials are attached.
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.
Activity
github-actions commentedon Aug 12, 2026
Issue reopened
The report now contains the information required by the automated check. Thanks for updating it.
Hzzz7 commentedon Aug 12, 2026
Additional reproduction: a text-only user question became a two-tool continuation
I reproduced the same
reasoning_textHTTP 400 in another fresh Codex App task. This adds an important boundary condition to the original report: the user prompt itself did not request tools, but the agent autonomously chose to inspect local context with two read-only shell calls.User prompt, translated/summarized:
This could have been answered as a text-only strategy question. However, the Flash turn decided to inspect the current project directory and local memory/context before answering.
Actual event sequence
The official DeepSeek Flash request used:
deepseek/deepseek-v4-flashopenai-responsesresponsesmaxmodelAdaptersoverrideFirst official Flash request:
ocx-msq2rii7-1jshell_commandfunction callsBoth corresponding
function_call_outputitems were recorded by Codex App. The immediate continuation then failed:ocx-msq2ry33-1lThe reasoning_text in the thinking mode must be passed back to the API.No assistant answer was displayed.
Separate preceding failure
The same task initially attempted
amd-radeon/DeepSeek-V4-Flashand received HTTP 429 (rate_limit_exceeded). That was a separate provider/adapter path and is not thereasoning_textfailure. The reproduction above occurred afterward on the official DeepSeek provider with a new turn, where the first official Flash request returned HTTP 200 and only its tool continuation returned HTTP 400.Why this matters
The risk is not limited to prompts that explicitly request multi-tool work. A seemingly text-only prompt can enter the failing path when the Codex agent autonomously calls multiple tools to inspect workspace or memory context.
A more precise trigger boundary is therefore:
All IDs above are local non-secret request identifiers. No raw request bodies, reasoning text, tool outputs, file contents, configuration, account information, or credentials are included.
Hzzz7 commentedon Aug 12, 2026
Successful control: Web Search completed inside one Responses request
A new fresh Codex App task using the same official
deepseek/deepseek-v4-flashmodel and thinking effortmaxcompleted successfully. This successful control helps narrow the failing boundary.The user asked the same lawyer-livestream strategy question. In this run, Flash chose Web Search and produced the final answer successfully.
OpenCodeX request record
Only one official Flash request exists for the entire completed turn:
ocx-msq3509u-24deepseek/deepseek-v4-flashopenai-responsesresponsesCodex App recorded this event sequence within that turn:
There was no second OpenCodeX/DeepSeek HTTP request for a client-side tool-result continuation.
Contrast with the failing reproduction
The failing reproduction recorded:
This suggests that the defect is probably not all tool use in general. The stronger boundary is likely a client-managed tool-result continuation that requires a new stateless DeepSeek Responses request and replay of the previous reasoning item.
A Web Search that completes within one Responses request can succeed, while local shell/file tools that require Codex to submit
function_call_outputin a subsequent request can hit the replay defect.AMD 429 is not required
The earlier real-world failing task did have a separate preceding
amd-radeon/DeepSeek-V4-FlashHTTP 429, and that attempt shared the same OpenCodeX conversation identifier with the later official-DeepSeek turn. However:reasoning_text400 without any preceding AMD request;No search results, final-answer content, internal reasoning text, raw request bodies, local file contents, configuration, account information, or credentials are included here.
Wibias commentedon Aug 12, 2026
Hey @Hzzz7 please update to our latest version and report again! Thanks!
Hzzz7 commentedon Aug 12, 2026
Retest on OpenCodeX 2.13.0: original failure path now passes twice
Per the maintainer request, I updated from OpenCodeX 2.12.0 to the latest stable release, 2.13.0, and reran the original client-managed continuation path.
Upgrade validation
/healthz:status=ok, version2.13.0ocx ready: readyocx config validate: validproviders.deepseek.modelAdaptersoverrideocx doctorconfirmed the in-memory app-server catalog matches the on-disk catalogThe 2.13.0 release notes include relevant fixes such as preserving parallel reasoning replay and binding reasoning replay to route identity.
Retest A
Fresh Codex App task, official
deepseek/deepseek-v4-flash, thinking efforthigh.Required sequence:
shell_command: readhttp://127.0.0.1:10100/healthzshell_command: read the first line of an existing local text filefunction_call_outputitems, synthesize a final answerThe task completed successfully. OpenCodeX recorded three requests in the same conversation, all through
openai-responses:ocx-msqbz8nu-c: HTTP 200ocx-msqbzbqi-e: HTTP 200ocx-msqbzcxa-f: HTTP 200For all three records, requested, selected, and actual model were
deepseek-v4-flash. No recovery attempt and noreasoning_texterror occurred.Retest B
A second fresh task reversed the two local-tool operations while keeping them sequential and separate:
/healthzIt also completed successfully, again with three official Flash Responses requests in one conversation:
ocx-msqc01hy-j: HTTP 200ocx-msqc0448-l: HTTP 200ocx-msqc05ug-m: HTTP 200Again, requested, selected, and actual model were all
deepseek-v4-flash, adapteropenai-responses, with no recovery and no HTTP 400.Current result
The exact class of failure that reproduced on 2.12.0 — multiple local tool calls followed by client-managed
function_call_outputcontinuations — did not reproduce in either of two fresh 2.13.0 tests.On this Windows/Codex App environment, the 2.13.0 reasoning-replay fixes appear effective for the reported case. I will continue normal use and report again if the 400 reappears under a different continuation shape.
No raw request bodies, internal reasoning text, tool output contents, full logs, configuration, account data, or credentials are included here.
Ingwannu commentedon Aug 13, 2026
Thanks for the detailed retest. Your two fresh 2.13.0 controls exercised the original client-managed multi-tool continuation path with three Responses requests each, and all six requests completed without the
reasoning_text400. That matches the reasoning replay and route-identity fixes shipped after 2.12.0.I am closing this as resolved in 2.13.0. If it recurs on a current release, please open a new report with the exact version and the smallest redacted continuation sequence so we can distinguish a new replay shape from this fixed case.