Repository navigation
go: mimo-v2.6-flash and mimo-v2.5 advertise image input but the Go endpoint rejects every image (400) #55785
Description
Description
opencode-go/mimo-v2.6-flash is advertised as image-capable (attachment: true, modalities.input: [text, image, audio, video]), so clients attach images and send them. The Go endpoint then rejects every request that contains an image:
{"error":{"param":"","type":"server_error","message":"Upstream request failed: [400] Invalid request parameters"}}
In the OpenCode client the same rejection surfaces as Upstream request failed: [unsupported_media] This model reads text only; remove images and video from the messages.
Text-only requests to the same model return 200. The identical body with deepseek-v4.1-flash or glm-5.3-flash returns 200 and the model describes the image. Same 400 for mimo-v2.6-pro and mimo-v2.5. Reproducible with plain curl, no OpenCode client involved.
So either the deployment behind the endpoint is text-only (and the published metadata is stale) or the gateway's per-model image flag is off. Related: #50823 has mimo-v2.6-flash vision working through opencode-go on Sept 23, so this looks like a change since then; #40642 covers mimo-v2.5 audio/video being silently dropped rather than rejected.
Steps to reproduce
- POST to
https://opencode.ai/zen/go/v1/chat/completionswith an OpenCode Go key, any freshx-opencode-sessionheader, and this body (valid 1x1 PNG):
{
"model": "mimo-v2.6-flash",
"max_tokens": 32,
"stream": false,
"messages": [
{
"role": "user",
"content": [
{ "type": "text", "text": "Reply with the single word OK." },
{ "type": "image_url", "image_url": { "url": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mP8z8DwHwAFAAH/q842iQAAAABJRU5ErkJggg==" } }
]
}
]
}mimo-v2.6-flashreturns HTTP 400 with the error above.mimo-v2.6-proandmimo-v2.5return the same.- Change
modeltodeepseek-v4.1-flashand send the same body. HTTP 200, and it answers "The user attached a 1x1 white pixel image...".
Expected: the image reaches the model, or the model metadata stops advertising image input.
Screenshot and/or share link
N/A - API level, reproducible with plain curl.
Operating System
Windows 11 (10.0.26220)
Terminal
n/a
Plugins
First hit from OpenChamber 2.3.2 (desktop) driving OpenCode 2.0.28. The steps above use no client.
OpenCode version
2.0.28
Activity
opencode-agent commentedon Oct 15, 2026
Thanks for the detailed report and the curl reproduction.
I checked the published model metadata.
opencode-go/mimo-v2.6-flash,mimo-v2.6-proandmimo-v2.5do all listimage(plus audio and video) inmodalities.input, so clients will send images to them as you describe. I couldn't test the endpoint's actual response, though, because that needs a real OpenCode Go key and this sandbox doesn't have one. The error text also doesn't come from the OpenCode client code, which fits your read that this is on the gateway or upstream side, or the published metadata is stale.A maintainer with Go access will need to confirm this and decide whether to re-enable image input for these models or correct the metadata. Related issues:
micahgerges commentedon Oct 15, 2026
Confirmed with a real OpenCode Go key from a server deployment (opencode serve 2.0.29, Linux/Docker) — running the endpoint test noted above as blocked. Controlled 2×2, fresh sessions, identical 300KB PNG as image_url data URI:
Two extra data points: (1) long-lived sessions fail intermittently — V2 resends full history each turn, so a session with one old image in it showed interleaved pass/fail (dozens of 200s before failures began), while fresh single-shot requests always failed — fits a multi-replica/flag theory where some backends accept. (2) Reproduced on 2.0.29 as well. Client impact pairs with #55309/#52042: every later turn in that session dies until the image leaves history. Happy to run further curl bisection with the Go key.
sogeisetsu commentedon Oct 15, 2026
Extra data on the endpoint-only path, in case it helps the bisection.
Same repro:
POST https://opencode.ai/zen/go/v1/chat/completions, freshx-opencode-sessionper request, one 1x1 PNG as animage_urldata URI, no client involved (OpenCode 2.0.28 on Windows).mimo-v2.6-flash: text-only 200, text + image 400. Three fresh single-shot requests, all three 400.mimo-v2.6-proandmimo-v2.5.deepseek-v4.1-flash: 200 with the same body, and it answered about the image ("a 1x1 white pixel image").glm-5.3-flash: 200 with the same image part.One thing that may matter for the routing theory: the gateway's error body for the identical model and payload is not stable. I saw all of these:
Upstream request failed: [400] Invalid request parametersUpstream request failed: [400] Provider returned errorUpstream request failed: [unsupported_media] This model reads text only; remove images and video from the messages.(what the client surfaces)My sample is small - fresh single-shots were 3/3 failures here, so I can't confirm that some backends still accept images. If a failure rate over N calls helps your bisection, say the word and I'll run it.
One more: the catalog has not moved.
opencode-go/mimo-v2.6-flashstill listsattachment: trueandmodalities.input: [text, image, audio, video], and https://opencode.ai/data/xiaomi/mimo-v2-6-flash (updated 2026-10-12) still lists text, image, audio, video. So only the serving side rejects.micahgerges commentedon Oct 16, 2026
Follow-up from the same real-key server deployment (opencode serve 2.0.29): the behavior shifted overnight — re-running the exact bisection on 2026-10-16, same 300KB PNG as an image_url data URI:
So the deterministic failure from yesterday is no longer reproducible from our side — consistent with your unstable-error-body observation: looks like backend state that changed between 2026-10-15 and 2026-10-16 rather than a static per-model flag. If the team confirms what changed, great; otherwise happy to rerun any N on request. Would suggest leaving this open until serving matches the catalog on all replicas, or closing once confirmed if the fix is meant to stick.
Note: to be transparent this was written by my agent but it seems to check out, hope this helps and I would like to know if any more testing on your side tells a different story.
sogeisetsu commentedon Oct 17, 2026
Retested today (2026-10-17, Windows, plain curl against
/zen/go/v1/chat/completions, no client):mimo-v2.6-flash, text onlymimo-v2.6-flash, text + a real 64x64 PNG as a data URImimo-v2.6-flash,stream: trueThe 1x1 PNG from my original repro is now rejected by every model on the endpoint, including
deepseek-v4.1-flash, so that probe no longer discriminates between models — a real image does. Image input looks fixed, closing this one. Thanks @micahgerges for the server-side 11/11 check.