Skip to content

The request couldn’t be completed. #994

Closed
Closed
The request couldn’t be completed.#994
Labels
bugSomething isn't workingneeds-infoWaiting on reporter for a concrete spec or reproductionstreamingSSE, WebSocket, terminal stream frames

Description

@hamzasoussi53
hamzasoussi53
opened on Aug 4, 2026

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

Image Image

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

Image

Redacted configuration



Checks


    

  •  I searched existing issues and documentation.
    • 

  •  I removed secrets, tokens, account details, request credentials, and personal data.
    • 

Activity
  1. hamzasoussi53
    added 
    bugSomething isn't working
     on Aug 4, 2026
  2. github-actions commented on Aug 4, 2026 
    @github-actions
    github-actionsbot
    on Aug 4, 2026 – with GitHub Actions
    Contributor
    


    Automated translation bookkeeping — detected language: unknown.
  3. github-actions
    added 
    streamingSSE, WebSocket, terminal stream frames
     on Aug 4, 2026
  4. Wibias commented on Aug 4, 2026 
    @Wibias
    Wibias
    on Aug 4, 2026
    Contributor
    [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. 

    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.
      3. 

    

    Keeping this open until the retest lands.
  5. lidge-jun commented on Aug 6, 2026 
    @lidge-jun
    lidge-jun
    on Aug 6, 2026
    Owner
    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. 

    2. whether it reproduces on v2.10.2, which is current on npm.
      3. 

    

    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.
  6. Wibias
    added 3 commits that reference this issue on Aug 6, 2026
    fix(providers): replay DeepSeek reasoning for opencode-zen (lidge-jun…
    393c556
    fix(providers): replay DeepSeek reasoning for opencode-zen (lidge-jun…
    96ae39b
    Merge pull request #1068 from justjxke/fix/opencode-zen-reasoning-replay
    7d0c02d
  7. lidge-jun commented on Aug 6, 2026 
    @lidge-jun
    lidge-jun
    on Aug 6, 2026
    Owner
    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. 

    2. Please retest once the next release ships, or now if you build from dev.
      3. 

    

    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.
  8. lidge-jun
    added a commit that references this issue on Aug 6, 2026
    docs(devlog): re-review ledger, and two PRs that stay with their authors
    8221c00
  9. Wibias
    added 
    needs-infoWaiting on reporter for a concrete spec or reproduction
     on Aug 6, 2026
  10. Wibias commented on Aug 7, 2026 
    @Wibias
    Wibias
    on Aug 7, 2026
    Contributor
    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.
  11. Wibias
    closed this as completedon Aug 7, 2026
  12. agentHits
    added 2 commits that reference this issue on Sep 17, 2026
    fix(providers): replay DeepSeek reasoning for opencode-zen (lidge-jun…
    f40654f
    Merge pull request lidge-jun#1068 from justjxke/fix/opencode-zen-reas…
    84645df
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Metadata
Metadata
Assignees
No one assigned
    Labels
    bugSomething isn't workingneeds-infoWaiting on reporter for a concrete spec or reproductionstreamingSSE, WebSocket, terminal stream frames
    Projects
    No projects
      Milestone
      No milestone
      Relationships
      None yet
      Development
      No branches or pull requests
      Issue actions