OpenCode Go: Xiaomi MiMo rejects list-type tool message content (400 text is not set) #32613

Activity

1. github-actions

   assigned

   fwang

   on Jun 16, 2026
2. lexlian commented on Jun 19, 2026

   

   lexlian

   on Jun 19, 2026

   Last edited by lexlian

   More actions

   @Cdddo @fwang , I fixed the issue with PR #32966.

   Root cause: MiMo/GLM-5.2/Xiaomi require tool role messages to have content as a plain string, not ContentPart[] array. The AI SDK sends tool results as [{type: "tool-result", output: {type: "text", value: "..." }}], which these providers reject with 400 errors.

   Fix: Added provider-specific transform that flattens single-part tool results to plain strings for affected providers. Multi-part content is preserved as array (providers that don't support it will error, which signals the limitation clearly.
3. nagdeepanjan commented on Jul 22, 2026

   

   nagdeepanjan

   on Jul 22, 2026

   More actions

   +1 — still affecting OpenCode Go users

   I'm running OpenCode Go with Xiaomi MiMo v2.5 as my primary model (via Hermes Agent on a Raspberry Pi). This issue causes intermittent 400 errors whenever a tool result includes image content (vision analysis, browser screenshots, etc.), forcing fallback to non-vision models and breaking my entire image verification workflow.

   What I've tried:

   • Routing through OpenRouter instead of OpenCode Go's native relay (works, but adds latency and loses some features)
   • Keeping the fallback chain as a band-aid (all fallback models lack vision, so the system becomes unusable for visual tasks)

   PR #32966 by @lexlian looked like the right fix (flatten single-part tool results to plain strings for affected providers), but it was closed by automated cleanup before being reviewed. The fix was tested and passing all 277 tests.

   Request: Could this be prioritized? The Xiaomi API isn't going to change this behavior — their docs explicitly require string content for tool messages. The relay is the right place to handle this translation.

   Happy to help test if a new PR is opened.
4. Nandoca95 commented on Jul 26, 2026

   

   Nandoca95

   on Jul 26, 2026

   More actions

   Current reproduction through OpenCode Go / MiMo v2.5

   I am adding current evidence to this existing issue rather than opening a duplicate.

   Effective route

   • Hermes main commit: fe3dd9106a1c9d2327fb3795e55b09742c43bafd
   • Provider: opencode-go
   • Model: mimo-v2.5
   • Base URL: https://opencode.ai/zen/go/v1

   Reproduction

   Using a fresh temporary Hermes home, without changing the permanent configuration:

   opencode-go/mimo-v2.5
   → browser_navigate completed
   → browser_vision completed
   → next request through opencode-go/mimo-v2.5
   → HTTP 400
   

   The returned error was:

   Error from provider (Xiaomi): Param Incorrect
   param: `text` is not set
   

   The request did not switch to Xiaomi as the selected Hermes provider. The effective provider remained OpenCode Go throughout the tested route. Hermes also did not silently switch to another model after the 400.

   The same failure pattern was previously observed in Hermes sessions using opencode-go/mimo-v2.5 directly and after a real fallback to that route.

   Question for OpenCode Go

   Could you confirm how the OpenCode Go relay/adaptor maps the request state associated with browser_vision into the request sent to MiMo v2.5?

   In particular:

   • Is a plain text field required for tool messages on this route?
   • Does the relay normalize list/part-based tool content before forwarding it?
   • Is text is not set expected for this request shape, or should the relay return a more specific compatibility response?

   Scope and limitations

   • This is not a direct Xiaomi-provider test; the effective provider was opencode-go.
   • Xiaomi is mentioned only because it appears as the upstream source in the returned error.
   • The exact wire payload was not captured.
   • I am not asserting that OpenCode Go alone is the root cause; the defect may involve Hermes request construction, relay transformation, or the downstream adapter boundary.
   • The historical introducing change has not been identified.

   Related Hermes reproduction: NousResearch/hermes-agent#49388
5. Wallacy

   added a commit that references this issue on Aug 3, 2026

   fix(mimo): flatten list-type tool message content to string (upstream…

   ...

   3c5df1e
6. FrancoMeneses commented on Sep 22, 2026

   

   FrancoMeneses

   on Sep 22, 2026

   More actions

   Adding current evidence for the third-party OpenAI-compatible client path, plus one gap that the earlier fix does not cover.

   Reproduction as of today:

   • Provider opencode-go, model mimo-v2.5, base URL https://opencode.ai/zen/go/v1
   • Client: Hermes Agent (plain OpenAI-compatible chat completions)
   • A tool result that carries an image is sent as multi-part content on role: "tool":
     [{"type":"text","text":"..."},{"type":"image_url","image_url":{...}}]
   • Xiaomi rejects the request: 400, param: "text" is not set

   The part worth flagging: the transform in #32966 only handles single-part tool results. It flattens a lone text/error part to a string and explicitly leaves multi-part content as an array. Multi-part is exactly the shape this bug is about, so even with that transform merged, a tool result carrying an image would still 400.

   What would actually close it for these providers, either way:

   • hoist media out of the tool result into a normal user message — this is the existing behavior for @ai-sdk/openai-compatible in the CLI (supportsMediaInToolResult returns false for it, so the image is extracted and re-injected as a user message), and it is the same approach PR fix(opencode): hoist Bedrock tool images except Claude, Nova, and Llama 4 #50272 just merged for Bedrock; or
   • for role: "tool" messages specifically, emit plain-string content and move the media part to an adjacent user message.

   Worth noting the asymmetry: the opencode CLI itself does not hit this, because it already hoists media out of tool results for OpenAI-compatible SDKs. It only bites clients that talk to /zen/go/v1/chat/completions directly and treat "OpenAI-compatible" literally. Since Go is advertised as an OpenAI-compatible endpoint, closing that gap on the relay side would fix every third-party client at once instead of each one shipping its own workaround.

   Happy to test a fix or provide a minimal request payload if useful.
7. opencodejr commented on Oct 29, 2026

   

   opencodejrBot

   on Oct 29, 2026

   More actions

   Thanks for the detailed write-up and the links to the reports in other clients!

   To restate the request: when the OpenCode Go /v1/chat/completions endpoint routes to Xiaomi MiMo, you'd like the relay to flatten list-type role: "tool" message content (text + image_url parts) into a string, or at least document that MiMo does not support multimodal tool results. Without that, clients that send tool results this way get 400 "text is not set".

   For context, the OpenCode app itself sends tool results to OpenAI-compatible endpoints as plain text, with any images in a separate user message, so it shouldn't hit this error. It mainly affects other clients that call the Go endpoint directly. That makes this a request for the relay to normalize content for each model, and maintainers will consider it.

   Related issues:

   • go: /v1/chat/completions returns 400 for reasoning_effort=max|minimal on mimo-v2.6-flash (low/medium/high succeed) #50818: another MiMo-specific 400 from the Go endpoint (reasoning_effort values)
   • Responses image parts omit detail, 400 on strict upstreams #59404: image parts in requests causing 400s on strict upstreams