Upstream request failed: [server_error] Upstream response was not valid JSON #40194

Activity

1. github-actions

   assigned

   fwang

   on Aug 2, 2026
2. github-actions commented on Aug 2, 2026

   

   github-actionsBot

   on Aug 2, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Console Go: kimi-k3 and mimo-v2 fail with "Upstream request failed", minimax-m3 works #39627: Console Go: kimi-k3 and mimo-v2 fail with "Upstream request failed" (same symptoms with mimo-v2.5 and free models)
   • Console Go (zen/go/v1): mimo-v2-pro and mimo-v2-omni always fail with 'Upstream request failed' #39873: Console Go: mimo-v2-pro and mimo-v2-omni always fail with 'Upstream request failed' (mimo-v2 family failures on the same endpoint)
   • [BUG]: OpenCode Zen free models hy3-free and nemotron-3-ultra-free failing while deepseek-v4-flash-free works #38028: OpenCode Zen free models failing while other models work (free model availability issue)

   If your issue is the same, please add a reaction or comment there instead of opening a new report.
3. CasperOng commented on Sep 13, 2026

   

   CasperOng

   on Sep 13, 2026

   More actions

   Same issue, Luna
4. orionp13 commented on Sep 21, 2026

   

   orionp13

   on Sep 21, 2026

   Last edited by orionp13

   More actions

   OpenCode Go rejected your API key, so the model can't be reached. Update it in Settings → Providers, or run hermes setup in a terminal.
   
   Provider said: HTTP 403: Upstream request failed: [server_error] Upstream response was not valid JSON
   
   This turn did not complete. Some actions may already have run; verify their effects before resending.
   

   I have the same issue i code with hermes agent and opencode go

   I use Deepseek V4.1 Flash

   👍React with 👍1Reacted by A. Aurelions
5. aaurelions commented on Sep 22, 2026

   

   aaurelions

   on Sep 22, 2026

   More actions

   

   It seems to me that opencode v1 continued running after the error, but opencode v2 terminates the turn.
6. 4Liberty commented on Sep 23, 2026

   

   4Liberty

   on Sep 23, 2026

   More actions

   Confirming this on v2 with a measured client-side mechanism, in case it helps pin the fix.

   Environment: OpenCode Desktop 2.0.9 → 2.0.14 (bundled CLI), Windows; provider opencode-go, model deepseek-v4.1-flash.

   Stored error part:

   {"type":"provider.auth","message":"Upstream request failed: [server_error] Upstream response was not valid JSON","status":403}

   Where the text comes from: it is not in any client bundle (checked the 2.0.9/2.0.12/2.0.14 opencode-cli.exe, the desktop app.asar and OpenCode.exe). The client copies error.message from the HTTP response body, so the text is the relay's — consistent with the pointer at packages/console/app/src/routes/zen/util/handler.ts in the other thread.

   Why the turn dies instead of retrying: the 403 makes the provider layer classify the error as reason tag Authentication → provider.auth, and the retry predicate treats Authentication as non-retryable. In the 2.0.14 bundle the predicate reads x-should-retry first, then switches on the reason:

   case "RateLimit":
   case "ProviderInternal": return true;
   ...
   case "Authentication":
   case "QuotaExceeded":
   case "ContentPolicy":
   case "InvalidRequest":
   case "UnsupportedOperation":
   case "NoRoute": return false;

   So a body that self-identifies as server_error is never consulted once the status is 403. The message-pattern retryable list (which does match server_error) is not reached on this path.

   Measured impact (one install): 22 stored failures across 12 sessions, 2026-09-20 → 09-23. Failed steps completed in 0.9–7.5 s (median ~1.9 s) — no retry chain. Fresh subagent sessions failed on their very first call, which argues against session-sticky routing being the whole story; failures cluster in short windows (two reviewer attempts two minutes apart both failed) and the same requests succeed minutes later.

   The retry machinery itself is fine: stamping x-should-retry: true on exactly this 403 class makes the turn survive. Verified on a standalone 2.0.14 server with a local fault injection: inject the raw relay 403 → client retries seconds later → turn completes (exit 0). So the fix is the classification, not the retry loop.

   Suggested direction: when a 403's structured body says server_error / upstream_unavailable, treat it as transient (retryable) rather than Authentication. The discriminator has to be the body, not the status: this endpoint also answers genuine request-shape errors as [invalid_request_error] (e.g. the reasoning_content replay rule), and those must keep failing fast — retrying them would only burn the budget. Same conclusion another client reached for this relay: NousResearch/hermes-agent#117869.

   Happy to test a build or open a PR with a focused test if useful.
7. 4Liberty commented on Sep 23, 2026

   

   4Liberty

   on Sep 23, 2026

   More actions

   One more measurement for whoever implements the client-side fix — the retry budget, not just the classification, decides whether a sustained relay outage kills the turn.

   Timeline from a subagent turn on 2.0.14 (2026-09-23), with a local guard that stamped x-should-retry: true on exactly this 403 class:

   09:12:46.978 → 09:14:22.787: eleven consecutive retries roughly 3–12 s apart (the client's 2 s → 10 s schedule with jitter), each answered by another 403, then the budget ran out and the turn failed. So the header hint does make the client retry, but ~10 attempts × the fixed 2–10 s backoff is only about 100 s of tolerance — a longer outage still fails the turn.

   What fixed it locally: re-frame the same 403 body as 502 plus retry-after-ms. In the 2.0.14 bundle the classifier maps status >= 500 to ProviderInternal, which is retryable and honours retry-after-ms (15-minute cap), so the wait can escalate per attempt (3/10/20/40/60 s ≈ 7 minutes of coverage) and the error is reported as provider.internal instead of the misleading provider.auth. Measured on a standalone 2.0.14 server with injected blips: four consecutive 403s → waits 3 s, 10 s, 20 s, 40 s on one chain → turn completed (exit 0).

   One detail worth knowing if anyone takes this route: the retried request body grows as the failed attempt joins the history (133 KB → 152 KB → 161 KB in that capture), so the retry chain has to be keyed by the session, not by the payload.
8. 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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
9. thdxr

   closed this as not plannedon Oct 11, 2026