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.