OpenAI-compatible providers: image_url content type fails deserialization when sending images

[LifetimeVip]

Description

When using DeepSeek V4 Flash (or other OpenAI-compatible providers) via a custom provider configuration with modalities: { input: ["text", "image"] }, attempting to paste/send an image attachment causes OpenCode to crash with a JSON deserialization error.

Error message

Failed to deserialize the JSON body into the target type: messages[196]: unknown variant `image_url`, expected `text` at line 1 column 764958

Root cause analysis

OpenCode's internal message content schema (used for validating request bodies) only recognizes text, image, and audio as valid type variants in message content parts. However, when building the actual HTTP API request for OpenAI-compatible providers, image file parts are correctly converted to the OpenAI image_url format (e.g. { type: "image_url", image_url: { url: "data:..." } }). This converted format then fails schema validation because image_url is not a recognized variant in the internal schema.

The conversion from file parts to image_url happens correctly in the provider layer, but the request body is subsequently validated against a schema that was designed for the MCP-style { type: "image", data: ..., mimeType: ... } format.

Steps to reproduce

1. Configure an OpenAI-compatible provider (e.g., DeepSeek) with image modality enabled:

   {
     "provider": {
       "deepseek": {
         "models": {
           "deepseek-v4-flash": {
             "modalities": {
               "input": ["text", "image"],
               "output": ["text"]
             }
           }
         }
       }
     }
   }

2. Start a new chat session with this model
3. Paste an image (Ctrl+V) or attach an image file to the message
4. The application crashes with the deserialization error shown above

Expected behavior

OpenCode should properly handle image attachments by either:
a) Supporting image_url as a valid content variant alongside text, image, and audio in the request validation schema, OR
b) Converting image content to the MCP-compatible image format before validation

Environment

• OpenCode version: 1.14.39
• Provider: DeepSeek V4 Flash (OpenAI-compatible API)
• OS: Windows 11
• Modalities configured: text + image

Related issues

• Custom OpenAI-compatible providers: image file attachments do not reach vision-capable models correctly #20802: Custom OpenAI-compatible providers: image file attachments do not reach vision-capable models correctly
• Failed to read images using Kimi 2.5 with Customer provider #23427: Failed to read images using Kimi 2.5 with Customer provider
• Image detail parameter missing in OpenAI-compatible provider image payloads #24242: Image detail parameter missing in OpenAI-compatible provider image payloads

[LifetimeVip]

Quick follow-up: I have done additional code analysis and identified the exact locations that need changes.

The root cause is in the message content schema validation. The internal schema uses discriminatedUnion("type", [TextContentSchema, ImageContentSchema, AudioContentSchema]) where ImageContentSchema expects type: "image" with data + mimeType fields. However, the OpenAI-compatible provider converter correctly converts image file parts to { type: "image_url", image_url: { url: "..." } } format, which then fails validation.

The fix would involve adding an ImageUrlContentSchema variant to the relevant discriminatedUnion, or alternatively converting the image_url format back to MCP-compatible image format before validation.

Happy to provide more details or test a fix if someone picks this up.