opencode-go/deepseek-v4.1-flash randomly rejects requests with 400/403 #51434

Activity

1. github-actions

   assigned

   fwang

   on Sep 26, 2026
2. github-actions commented on Sep 26, 2026

   

   github-actionsBot

   on Sep 26, 2026 – with GitHub Actions

   Contributor

   More actions

   ---

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

   • provider: opencode-go 400 stub on long sessions varies per attempt (identical bytes replay 200/400/200) #51201: Intermittent 400s with the same {"model":"deepseek-v4.1-flash"} response; replaying the identical request alternated between 200 and 400.
   • provider: opencode-go route-dependent context limits cause unparseable HTTP 400 in long sessions #50761: Long-session, route-dependent 400s with the same model-only response stub on deepseek-v4.1-flash.
   • [Bug] OpenCode Go: deepseek-v4.1-flash 403 "Upstream response was not valid JSON" with large payload #50897: 403 errors on deepseek-v4.1-flash with large payloads and high reasoning effort.
3. chinarma commented on Sep 27, 2026

   

   chinarma

   on Sep 27, 2026

   More actions

   every 8-10 step happens 。

   👍React with 👍1Reacted by Yangguang Li
4. SamSpiri commented on Sep 29, 2026

   

   SamSpiri

   on Sep 29, 2026

   More actions

   Client-side workaround for the retry gap described here.

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

   It implements the second paragraph of the Expected Behavior above: a 400 whose body carries no error information is retried a couple of times instead of ending the turn. Structured 400s keep the built-in policy, so deterministic rejections are not retried pointlessly.

   Single file, no dependencies. Install by copying it into ~/.config/opencode/plugins/; it uses the V2 session.hook("retry") API, and OpenCode discovers files in that directory automatically, so there is no config to edit. It matches only: provider opencode-go + model deepseek-v4-flash / deepseek-v4.1-flash + status 400 + provider.invalid-request + an opaque message (the Provider request failed with HTTP 400 fallback, a bare Bad Request, or the raw {"model":"..."} body). Two extra attempts, 3 s then 9 s.

   Worth stating plainly:

   • This is a workaround for the client-side classification gap, not a fix for the gateway emitting the stub. The stray {"model":"..."} body is still unexplained and still unrecoverable client-side, which is the part that actually needs maintainer eyes — worth noting again here that the body is dropped when the error is persisted, so nothing after the fact can recover it.
   • It cannot help the deterministic classes that present as the same bare 400: the reasoning_content × reasoning_effort rejection (Console Go relay: HTTP 400 (empty body) when request combines reasoning_content echo-back with reasoning_effort on deepseek-v4-flash #48180) and requests past a smaller upstream's ceiling (provider: opencode-go route-dependent context limits cause unparseable HTTP 400 in long sessions #50761, compaction: 1M-context sessions never auto-compact before the provider returns HTTP 400, and the 400 is not treated as context overflow #50574). Matching on an opaque message excludes them, and retrying them would be a no-op rather than a fix.
   • The attempt count is a heuristic constant, not a measurement.

   I have not observed it fire on a live stub, since that can't be induced on demand. What I did verify: the matcher against the shapes an empty-body 400 can take, and that the surfaced message really is the client fallback rather than a gateway string — from the 2.0.19 provider-error path, where the status-derived Provider request failed with HTTP ${status} is used whenever the parsed body yields no message/code.

   If an upstream change is preferred over a plugin, the smallest version is #50574's item 1: propagate the provider response body into the classifier so isContextOverflowError can see it, and treat a 400 with no error information as retryable once.
5. SamSpiri commented on Oct 2, 2026

   

   SamSpiri

   on Oct 2, 2026

   More actions

   Correction to my earlier comment, with results.

   My first version of this did not fire, and the reason is worth recording: the message is not stable across versions. On 2.0.19 a bodyless 400 persisted as the bare Provider request failed with HTTP 400. On 2.0.21 it arrives as

   Provider request failed with HTTP 400: {"model":"deepseek-v4.1-flash"}
   

   — the raw body appended — and the stub is additionally persisted at error.response.body. A matcher anchored ^...$ on the bare form silently no-ops on the second shape. That is what happened on a machine of mine that hit this today, plugin loaded and active.

   Fixed, and now verified end to end rather than assumed. Pointing a throwaway provider at a local server that answers 400 with {"model":"deepseek-v4.1-flash"} for the first three requests:

   plugin	requests observed	outcome
   disabled	3, all 400, same second	turn fails: Provider request failed with HTTP 400
   enabled	4 — the three, then one 9.1 s later returning 200	turn completes

   Without it the turn dies exactly as reported here; with it the retry carries the turn through. That is a direct demonstration of the retryability claim in this issue, on a client that otherwise treats the 4xx as terminal.

   Two points that may help the actual fix:

   • On 2.0.21 the stub is retained, at error.response.body on the persisted assistant message. The client can therefore distinguish an empty-body 400 from a structured one without any gateway change — which is most of what this issue's Expected Behavior asks for.
   • Anything keying off the message text should not anchor on the bare fallback form, since it is version-dependent.

   Updated plugin: https://github.com/SamSpiri/opencode-go-stub-400-retry
6. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
7. thdxr

   closed this as not plannedon Oct 11, 2026