[BUG] qwen3.7-max returns 500 'Internal server error' on image inputs via OpenCode Go (/zen/go/v1/messages) #29653

Description

Environment

• OpenCode version: 1.15.10 (TUI client) + @ai-sdk/openai-compatible provider plugin
• Provider: opencode-go (https://opencode.ai/zen/go/v1/messages)
• Model: qwen3.7-max
• Request format: Anthropic /v1/messages (Claude-shape, as required for qwen3.x — see Use a single rust LSP server instance for entire cargo workspace #2292 / "Model qwen3.x-* is not supported for format oa-compat")

Bug

Sending an image attachment to qwen3.7-max via opencode-go consistently returns HTTP 500 with the generic body:

{"type":"error","error":{"type":"error","message":"Internal server error"}}

Text-only requests to the same model on the same endpoint succeed normally. Removing the image block from the same payload makes the request succeed (model replies fine). Only adding a single image triggers the 500.

Direct test confirms the upstream model itself does not process images

I also tested qwen3.7-max directly via the OpenCode TUI pointed at the official opencode-go endpoint (no intermediate proxy). Once the model finally responded (after the retry loop), it replied verbatim:

"Não consigo visualizar imagens — o modelo atual (qwen3.7-max) não suporta input de imagem."

So the underlying Bailian model does not currently support image inputs, but the opencode-go proxy returns an opaque 500 Internal server error instead of a clean 400 with a meaningful message like "Model qwen3.7-max does not support image inputs", which is what e.g. oa-compat returns for the format-mismatch case.

Reproduction

Send a request to POST https://opencode.ai/zen/go/v1/messages with body:

{
  "model": "qwen3.7-max",
  "stream": true,
  "max_tokens": 32000,
  "messages": [
    {
      "role": "user",
      "content": [
        { "type": "text", "text": "what do you see?" },
        {
          "type": "image",
          "source": {
            "type": "base64",
            "media_type": "image/png",
            "data": "<any valid base64 PNG ~120KB>"
          }
        }
      ]
    }
  ]
}

Headers (Bearer auth via Authorization or x-api-key, anthropic-version: 2023-06-01).

Response: HTTP 500, body {"type":"error","error":{"type":"error","message":"Internal server error"}}.

The same client/proxy/payload shape with kimi-k2.6 works fine — image is correctly delivered and the model describes it.

Request shape (verified correct)

The outgoing body uses the canonical Anthropic image block:

{
  "type": "image",
  "source": { "type": "base64", "media_type": "image/png", "data": "..." }
}

No image_url blocks are sent. media_type is correct. Total body size ~210KB (image is ~120KB base64 = ~90KB raw). This is far below normal limits.

Suggested fix — pick one

1. Preferred: Update the opencode-go proxy so qwen3.7-max (and qwen3.6-plus, qwen3.5-plus) either:
   • Return 400 "Model X does not support image inputs" when an image block is present, or
   • Strip image blocks server-side and proceed text-only.
2. Registry workaround: Mark these models with "attachment": false in ~/.cache/opencode/models.json so the TUI never attaches images for them. (Same shape as Bug: qwen3.6-plus model in alibaba-coding-plan-cn provider has attachment: false, preventing image input #28690 for qwen3.6-plus in alibaba-coding-plan-cn.)

Either prevents the silent retry loop where the TUI keeps re-sending the same image-bearing request and getting 500s back-to-back ("retrying 1s attempt #3" in the UI).

Related

• Bug: qwen3.6-plus model in alibaba-coding-plan-cn provider has attachment: false, preventing image input #28690 — qwen3.6-plus attachment:false in alibaba-coding-plan-cn
• Qwen3.5 Plus and Qwen3.6 Plus not available in OpenCode Go despite being listed in documentation #22677 — Qwen3.5/3.6 Plus availability on OpenCode Go