[bug] opencode provider: Muse Spark contributor-free fails with "Invalid upload request", other free models work #47237

Activity

1. github-actions

   assigned

   jlongster

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

   

   github-actionsbot

   on Sep 4, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Zen] muse-spark-1.3-contributor-free returns HTTP 500 via API key, while 1.2-contributor-free works #47192: muse-spark-1.3-contributor-free returns HTTP 500 via API key (same model, same symptom, different error code)
   • Muse Spark 1.3 Contributor 无响应 #47227: Muse Spark 1.3 Contributor no response via Go plan (same model failure)
   • muse-spark-1.2-contributor-free returns HTTP 500 Internal server error #45584: muse-spark-1.2-contributor-free returns HTTP 500 Internal server error (same pattern for 1.2)
   • Intermittent "Upstream request failed: Endpoint is unavailable." on free models (x-preview-f-free, muse-spark-1.2-contributor-free) #45076: Intermittent "Upstream request failed: Endpoint is unavailable." on free models including muse-spark (similar intermittent upstream failure)
3. bompus commented on Sep 11, 2026

   

   bompus

   on Sep 11, 2026

   More actions

   New data point on this exact error, same model, opencode CLI 1.18.30 (Linux), provider opencode → https://opencode.ai/zen/v1/responses → upstream Console:

   Correlation with image attachments. Session ses_f6df9ce0 streamed fine for 40+ turns on muse-spark-1.3-contributor-free, then started failing on every subsequent request — including a trivial two-word prompt — with the non-retryable 400:

   AI_APICallError: Error from provider (Console): Upstream request failed:
   [invalid_request_error] Invalid upload request.
   

   The onset lines up exactly with two MCP preview_snapshot tool results (includeImage:true) that embedded data:image/png;base64 attachments (~1.35MB and ~50KB) into the part history (opencode.db, part.state.attachments). Session part total went to ~2MB. Every later request replays that history, so the session is permanently bricked — retry can't help (isRetryable: false, statusCode: 400).

   Stripping the two attachments from the DB (2 parts, ~1.4MB removed, backup kept) is my workaround; will report back whether the session streams again after restart.

   Hypothesis: the Console upstream rejects inline base64 image data-URLs in Responses-API requests (or images over a size limit), while other models/providers accept them — consistent with mimo-v2.5-free working in the report above.

   Note: the reporter's brand-new-empty-session failures suggest there may be a second trigger (or the rejection covers more payload shapes than just screenshots), but inline image attachments are one confirmed trigger with a clean before/after in the DB.
4. yxr1995-maker commented on Sep 11, 2026

   

   yxr1995-maker

   on Sep 11, 2026

   More actions

   Independent data point for this exact 400, plus one correction to the "images brick the session" theory: the refusal is intermittent on an unchanged payload, so it is retryable.

   Setup: opencode-go plan (https://opencode.ai/zen/go/v1/responses), model muse-spark-1.3-contributor, reasoning_effort: xhigh, through a local proxy that logs every upstream attempt.

   Timeline from one conversation (2026-09-12, local time):

   time	result	context
   05:26:43	400 invalid_request_error: Invalid upload request.	after a tool result was appended
   05:27:05	200	same model, same conversation, same ~194KB inline image + same tool output
   05:27:42	400	same, in a forked child session
   05:31:56	200	same conversation again

   Both refusals completed in 1.3s and 3.4s and carried no Retry-After. The 200s that follow came from the identical request body, which is why I read this as a gateway flap rather than a payload verdict: a client that retries once recovers the turn.

   What I could NOT reproduce as a trigger (all served 200 against the same upstream, same model):

   • the exact 194KB data:image/png;base64,... inline image, alone and as part of the full 104-item replayed context (588KB body)
   • request bodies padded to ~1MB, ~2MB and ~4MB
   • stream: true and stream: false on the same context
   • reasoning_effort: high and xhigh, with and without the image

   One caveat worth separating out: reasoning_effort: max is a different, deterministic 400 on this model: reasoning_effort max requires an active Muse Code subscription for model muse-spark-1.3-contributor. That one is a real verdict and must not be retried. The upload refusal is not.

   Filed a client-side mitigation upstream (single byte-identical replay, 800ms apart, once per request, gated on status 400 plus this exact message): lidge-jun/opencodex#4310

   If it helps on your side: surfacing this as retryable, or returning Retry-After, would let every client handle it without a special case, since the underlying Console call succeeds seconds later.