The request couldn’t be completed.

[hamzasoussi53]

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_content in 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

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[github-actions]

_{Automated translation bookkeeping — detected language: unknown.}

[Wibias]

[GD] Research review

Claim: Claude Code against an OpenCode DeepSeek thinking model intermittently gets an upstream HTTP 400 stating that reasoning_content in 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_calls is serialized without a non-empty reasoning_content for a preserveReasoningContentModels model. 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) added src/responses/reasoning-replay-cache.ts and re-attach logic in src/adapters/openai-chat.ts
Open PR covering this?	none for the Claude path. #940 and #1006 are 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 path
Security 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 dev
Verdict	Needs fix on development

Evidence

• Release timing: git merge-base --is-ancestor 55fdde98 v2.10.0 exits 1, and git tag --contains 55fdde98 is empty. The #971 fix merged 2026-08-04, after v2.10.0 shipped 2026-08-02. This report is on 2.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 #971 re-attach in messagesToChatFormat (src/adapters/openai-chat.ts:328-352).
• Divergent path: src/claude/inbound.ts:333-335 drops thinking / redacted_thinking on 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 #971 records 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 in src/server/responses/core.ts:1321 from the x-codex-parent-thread-id header. That header is Codex-specific, so Claude Code entries fall back to the literal "global" scope.
• Coverage: peekReasoningForCall / rememberReasoningForCall appear only in tests/deepseek-reasoning-replay-gaps.test.ts and tests/bridge-raw-reasoning-hidden.test.ts. No test exercises /v1/messages against the replay cache.

Gaps

• Not reproduced live against dev with 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-go and opencode-free both set preserveReasoningContentModels, but opencode-zen sets 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

1. @hamzasoussi53 — could you retest on dev (or the next preview) rather than 2.10.0, and say which OpenCode provider entry is configured (opencode-go, opencode-free, or opencode-zen) plus the exact model id? That separates "already fixed, just unreleased" from a genuine remaining gap.
2. 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/messages path.

Keeping this open until the retest lands.

[lidge-jun]

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 original reasoning_content to be replayed on tool-call continuations, and the opencode-zen provider entry on dev carries no preserveReasoningContentModels, while the sibling opencode-free route pointing at the same opencode.ai/zen/v1 gateway 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:

1. the exact provider and model you had selected — specifically whether it was an opencode-zen route and whether the model was a DeepSeek one;
2. 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.

[lidge-jun]

Update: the fix for the DeepSeek half of this landed on dev today.

PR #1068 (thanks to @justjxke) added the missing replay metadata to the opencode-zen provider. The cause was that opencode-zen and opencode-free reach the same opencode.ai/zen/v1 gateway, but only the free tier carried preserveReasoningContentModels — 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_content in the thinking mode must be passed back to the API.

Merge commit 7d0c02dbe, verified as an ancestor of origin/dev. It is not in a release yet — current npm latest is 2.10.2, which predates it. I will not close this issue on a dev-only fix.

Two things still open on your side:

1. 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-zen DeepSeek 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.
2. 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.

[Wibias]

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_content replay problem for opencode-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 dev branch
• 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.