Repository navigation
The request couldn’t be completed. #994
Description
Activity
Automated translation bookkeeping — detected language: unknown.
[GD] Research review
Claim: Claude Code against an OpenCode DeepSeek thinking model intermittently gets an upstream HTTP 400 stating that
reasoning_contentin thinking mode must be passed back to the API on tool-call continuations.
Checked against:dev@e44d234f0(release:v2.10.0=f9b9440c5)Field Finding Still an issue on latest development? unclear — partially mitigated, one gap remains unverified Exact issue Same upstream rejection as #950: an assistant turn carrying tool_callsis serialized without a non-emptyreasoning_contentfor apreserveReasoningContentModelsmodel. The difference is the client — this report is Claude Code (/v1/messages), not the Codex App (/v1/responses).Fixed on development? partly — PR #971 ( 55fdde98, merged 2026-08-04) addedsrc/responses/reasoning-replay-cache.tsand re-attach logic insrc/adapters/openai-chat.tsOpen PR covering this? none for the Claude path. #940and#1006are adjacent DeepSeek work (Responses item ids, bounded SSE JSON), not this wire.Duplicate of? not a duplicate — same upstream error as #950/#688, different entry pathSecurity relevance none — reasoning payload plumbing; the replay cache is memory-only and never logged or serialized Priority middle — real breakage on a primary path with a retry workaround, and partly mitigated already on devVerdict Needs fix on development Evidence
- Release timing:
git merge-base --is-ancestor 55fdde98 v2.10.0exits1, andgit tag --contains 55fdde98is empty. The#971fix merged 2026-08-04, afterv2.10.0shipped 2026-08-02. This report is on2.10.0, so it predates the fix entirely. - Shared path: Claude Code is translated to a Responses body and replayed through
handleResponses(src/server/claude-messages.ts), so it does reach the#971re-attach inmessagesToChatFormat(src/adapters/openai-chat.ts:328-352). - Divergent path:
src/claude/inbound.ts:333-335dropsthinking/redacted_thinkingon replay by documented v1 policy. For Codex, the client-side reasoning item is the primary source and the cache is the fallback; for Claude Code that primary source is absent, so every continuation depends on the in-process cache alone. The limitation#971records for itself — reasoning cannot be recovered for a call the proxy never saw in this process — therefore applies to the normal path here, not just an edge case. - Scope key: the cache is keyed on
parsed._clientThreadId, populated insrc/server/responses/core.ts:1321from thex-codex-parent-thread-idheader. That header is Codex-specific, so Claude Code entries fall back to the literal"global"scope. - Coverage:
peekReasoningForCall/rememberReasoningForCallappear only intests/deepseek-reasoning-replay-gaps.test.tsandtests/bridge-raw-reasoning-hidden.test.ts. No test exercises/v1/messagesagainst the replay cache.
Gaps
- Not reproduced live against
devwith a real Claude Code session — the reasoning above is from code reading only. - The report says provider "Console" and model "OpenCode models" without naming the registry entry.
opencode-goandopencode-freeboth setpreserveReasoningContentModels, butopencode-zensets none, so on Zen the re-attach gate never fires regardless of#971. - Whether the
"global"scope fallback actually collides in practice depends on real Claude Code call ids; unverified.
Recommended next
- @hamzasoussi53 — could you retest on
dev(or the next preview) rather than2.10.0, and say which OpenCode provider entry is configured (opencode-go,opencode-free, oropencode-zen) plus the exact model id? That separates "already fixed, just unreleased" from a genuine remaining gap. - If it still reproduces there, the remaining work is a Claude-specific reasoning round-trip rather than a re-run of
#971, plus a conversation scope key for the/v1/messagespath.
Keeping this open until the retest lands.
Reacted by sushmitxo- Release timing:
Status update, and a request for one specific thing.
The error you pasted —
The reasoning_content in the thinking mode must be passed back to the API— is a known shape. DeepSeek thinking mode requires the assistant's originalreasoning_contentto be replayed on tool-call continuations, and theopencode-zenprovider entry ondevcarries nopreserveReasoningContentModels, while the siblingopencode-freeroute pointing at the sameopencode.ai/zen/v1gateway does. So a DeepSeek thinking turn through Zen serializes a bare tool-call continuation and the gateway 400s it.A fix is in review: #1068, which adds the replay metadata for the Zen DeepSeek models. Its regression test builds a real translated continuation and would fail without the change. I have asked for two corrections before it lands — it currently replaces the text-only vision list instead of extending it, which would reopen a separate image bug for five other models, and it predates the per-model DeepSeek effort ladders that shipped in v2.10.2.
What would let us confirm this is your bug and not a lookalike. Your report says "OpenCode models" and the screenshots do not show the model id. Please confirm:
- the exact provider and model you had selected — specifically whether it was an
opencode-zenroute and whether the model was a DeepSeek one; - whether it reproduces on v2.10.2, which is current on npm.
If you were on a different provider, the 400 has the same text but a different cause, and #1068 will not help you — that is the distinction I do not want to get wrong on your behalf. Keeping this open either way.
- the exact provider and model you had selected — specifically whether it was an
Update: the fix for the DeepSeek half of this landed on
devtoday.PR #1068 (thanks to @justjxke) added the missing replay metadata to the
opencode-zenprovider. The cause was thatopencode-zenandopencode-freereach the sameopencode.ai/zen/v1gateway, but only the free tier carriedpreserveReasoningContentModels— so a DeepSeek thinking turn through the keyed tier serialized a bare tool-call continuation and the gateway answered exactly the 400 you pasted:The
reasoning_contentin the thinking mode must be passed back to the API.Merge commit
7d0c02dbe, verified as an ancestor oforigin/dev. It is not in a release yet — current npmlatestis 2.10.2, which predates it. I will not close this issue on a dev-only fix.Two things still open on your side:
- Which provider and model were you actually on? Your report says "OpenCode models" and the screenshots do not show the id. If you were on an
opencode-zenDeepSeek model, this is your bug and the next release should resolve it. If you were on a different provider, the same 400 text has other causes and fix(providers): replay DeepSeek reasoning for opencode-zen (#994) #1068 will not help you — that distinction is the one I do not want to get wrong on your behalf. - Please retest once the next release ships, or now if you build from
dev.
Keeping this open until you confirm. If it turns out you were on a different route, say so and I will reopen the investigation on that path rather than assume this fix covered you.
- Which provider and model were you actually on? Your report says "OpenCode models" and the screenshots do not show the id. If you were on an
- added a commit that references this issue
on Aug 6, 2026 Closing this for now because we still need the missing provider/model information to determine whether there is a remaining issue here.
#1068 already fixed the known
reasoning_contentreplay problem foropencode-zen, but the original report does not identify the exact OpenCode provider/model that produced the 400 response.If this is still reproducible, please provide:
- the exact provider/model used (
opencode-go,opencode-free,opencode-zen, etc.) - whether it still reproduces on the current
devbranch - ideally the relevant error/trace from the failed request
Once we have that information, we can reopen this issue and investigate the remaining path. Alternatively, the issue author can open a new issue with an up-to-date reproduction and the exact provider/model details.
- the exact provider/model used (
Client or integration
Claude Code
Area
Streaming
Summary
API Error: 400 Provider error 400: {"error":{"param":null,"type":"invalid_request_error","code":"invalid_request_error","message":"Error from provider (Console): Upstream request failed: [invalid_request_error] The
reasoning_contentin the thinking mode must be passed back to the API."}}Reproduction
Version
2.10.0
Operating system
Windows 11, MacOS
Provider and model
OpenCode models
Logs or error output
API Error: 400 Provider error 400: {"error":{"param":null,"type":"invalid_request_error","code":"invalid_request_error","message":"Error from provider (Console): Upstream request failed: [invalid_request_error] The `reasoning_content` in the thinking mode must be passed back to the API."}}Screenshots and supporting files
Redacted configuration
Checks