OpenCode Go DeepSeek V4.1 Flash intermittently returns HTTP 400 with only model name #51990

Activity

1. github-actions commented on Sep 29, 2026

   

   github-actionsBot

   on Sep 29, 2026 – with GitHub Actions

   Contributor

   More actions

   ---

   This issue might be a duplicate of existing issues. Please check:

   • opencode-go/deepseek-v4.1-flash randomly rejects requests with 400/403 #51434: Same OpenCode Go / DeepSeek V4.1 Flash intermittent 400/403 with the opaque model-only error body after tool turns.
   • opencode-go / deepseek-v4.1-flash: repeated AI_APICallError: Bad Request mid-session (opaque 400) #51477: Same provider and model with recurring mid-session opaque 400 errors.
   • provider: opencode-go 400 stub on long sessions varies per attempt (identical bytes replay 200/400/200) #51201: Same intermittent 400 with the exact model-only response body {"model":"deepseek-v4.1-flash"}.
   • provider: opencode-go route-dependent context limits cause unparseable HTTP 400 in long sessions #50761: Same model and opaque 400 response, investigated as route-dependent context limits during long sessions.
2. SamSpiri commented on Sep 29, 2026

   

   SamSpiri

   on Sep 29, 2026

   More actions

   Your side of this is Codex → LiteLLM → forwarder rather than OpenCode, so the OpenCode plugin below will not apply to you directly — but the retry policy it encodes is the general shape, and invites testers from the OpenCode side:

   https://github.com/SamSpiri/opencode-go-stub-400-retry

   Treat the bare-body rejection (status 400, JSON object containing only model, no error/message) as transient and retry it a couple of times with backoff; keep any 400 that carries a real reason terminal. That is a mirror of the guard you already have working, and your ledger is the best evidence in this thread that the classification is worth flipping.

   One observation relevant to triage here: your daily counts (1, 4, 9, 4, 2) with successes immediately before and after, and nothing matching in the Console Inference log, look like a flaky-route/replica signature rather than a verdict on the payload — consistent with #51201's byte-identical 200/400/200 replay. That suggests the per-request outcome is not determined by your prompt, which is also why a client-side retry should recover it.

   If you do test the equivalent in LiteLLM, a note here on whether it recovers would help — it would be a second stack confirming the retryability claim.
3. Bigbrotha12 commented on Sep 30, 2026

   

   Bigbrotha12

   on Sep 30, 2026

   More actions

   Adding another datapoint — same symptom on opencode v2.0.18 with the default OpenCode Go provider using opencode-go/deepseek-v4.1-flash.

   • Failures are sporadic, roughly 1 in 5–10 requests, and seem random — subsequent requests in the same session succeed.
   • Account limits/status confirmed fine, so it's not quota.
   • Not specific to very long sessions either — we see it on ordinary mid-session turns (after tool calls).

   The server log shows the failure surfaces while draining the session (i.e., sending the compiled request back to the provider), as AI.Error.InvalidRequest with no provider body:

   level=ERROR message="Failed to drain Session" cause="AI.Error: Provider request failed with HTTP 400
     at h5 (/$bunfs/root/chunk-3dv1eb1d.js:17:3523)
     at <anonymous> (/$bunfs/root/chunk-3dv1eb1d.js:17:3216)
     at SessionStep.attempt (/$bunfs/root/chunk-61ch0ng5.js:377:3586)
     at SessionRunner.runStep (/$bunfs/root/chunk-61ch0ng5.js:377:2625)
     at SessionRunner.drain (/$bunfs/root/chunk-tmnwny93.js:24:2279)
     at ServerProcess.start (/$bunfs/root/chunk-9h6dnfvq.js:2:6473)
   {
     [cause]: AI.Error.InvalidRequest: Provider request failed with HTTP 400
         at Fa (/$bunfs/root/chunk-3dv1eb1d.js:17:1117)
         at h5 (/$bunfs/root/chunk-3dv1eb1d.js:17:3534)
   }"
   role=server
   

   The recurring theme across the related issues (#51530, #50446, #51201, #50761) is that opencode-go returns an opaque 400 and opencode surfaces only the status code — so it's impossible to tell whether this is an upstream DeepSeek rejection, a context-limit edge case, or a gateway bug. Passing through the provider's response body (even raw) would help a lot in triaging.

   Environment: opencode v2.0.18, Fedora 43 x86_64 (Linux 7.2.7-100.fc43), alacritty/truecolor, latest channel, no plugins.
4. neriousy commented on Oct 20, 2026

   

   neriousy

   on Oct 20, 2026

   Member

   More actions

   Thanks for the report. We're tracking this same intermittent DeepSeek V4.1 Flash HTTP 400 response containing only the model name in #51201, so I'm closing this as a duplicate. Please follow that issue for updates.
5. neriousy

   closed this as a duplicateof provider: opencode-go 400 stub on long sessions varies per attempt (identical bytes replay 200/400/200) #51201 on Oct 20, 2026