Bug: MiMo V2.5 (mimo-v2.5) advertises video/audio support but video input is never received by the model

[a88741704-collab]

Description

Summary

The OpenCode Go model mimo-v2.5 advertises text, image, audio, video input capabilities (visible in /models and the model picker), but video input is never actually received by the model. The model responds "没收到" (didn't receive) regardless of format.

Tested formats (all failed)

All tested against https://opencode.ai/zen/go/v1/chat/completions with model mimo-v2.5:

1. {"type": "video_url", "video_url": "data:video/mp4;base64,..."} → model replies it didn't receive any video
2. {"type": "input_video", "video_url": {"url": "data:..."}} → HTTP 503 "Endpoint is unavailable"
3. {"type": "input_video", "video_url": "data:..."} → model replies it didn't receive any video
4. {"type": "video", "video": {...}} and {"type": "video", "video": "data:..."} → model replies it didn't receive any video
5. Public HTTPS video URLs (e.g. MDN/W3Schools test videos) with video_url → model replies it didn't receive any video

For comparison

• qwen3.7-plus with {"type": "video_url", "video_url": "data:video/mp4;base64,..."} works — the model correctly describes the video content.
• kimi-k2.7-code with the same format also works.
• mimo-v2.5 text input works fine (normal chat responses).

Expected behavior

Either video input should actually reach the model (per the advertised capabilities), or the metadata should not advertise video support.

Actual behavior

The model receives the message but no video content — the video modality is effectively non-functional despite being advertised.

Plugins

vision-auto-switch.ts (custom), ooclaw-opencode.js

OpenCode version

1.18.13

Steps to reproduce

1. Use OpenCode Go subscription with API key
2. Send a chat completion request to https://opencode.ai/zen/go/v1/chat/completions with model=mimo-v2.5
3. Include a video content part (any format: video_url string, input_video object, base64 data URL, or public HTTPS URL)
4. Observe: the model responds that it received no video
5. Repeat with qwen3.7-plus using identical video_url format → video is received and described correctly

Screenshot and/or share link

N/A (API-level bug, reproducible with plain curl)

Operating System

Windows 11

Terminal

Windows Terminal

[github-actions]

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

• opencode.ai "mimo-v2.5" is unable to transmit and comprehend audio files #39650: Same model (mimo-v2.5) fails to transmit audio input via the OpenCode Go API — same root symptom (multimodal content not reaching the model despite being advertised), same endpoint, same observed behavior of the model responding as if no media was received.

If these are the same underlying issue, consider consolidating.

[AWD-2069]

I am also not allowed to upload videos in opencode web even when using Mimo.

[thumb2086]

Implementation proposal

The root cause is in packages/opencode/src/provider/provider.ts:700-713 where the zen provider hardcodes:

input: {
  text: true,
  audio: false,   // hardcoded
  image: true,
  video: false,   // hardcoded
}

Even though models like mimo-v2.5 declare audio/video support in their modalities config, the zen provider overrides this to false.

Proposed fix:

File	Change
packages/opencode/src/provider/provider.ts	Set audio: true / video: true based on model modalities instead of hardcoding
packages/console/.../provider/openai-compatible.ts	Add input_audio content type handling (OpenAI spec)
packages/console/.../provider/anthropic.ts	Add audio content type mapping (base64 to Anthropic format)
packages/opencode/src/util/media.ts	Add audio MIME type detection (.mp3, .wav, .m4a, .ogg)
packages/opencode/src/provider/transform.ts	Pass audio content through without stripping

Example (OpenAI audio spec):

{
  "type": "input_audio",
  "input_audio": {
    "data": "<base64_encoded_audio>",
    "format": "wav"
  }
}

Happy to help implement if there's interest.

[JakeBreathild]

Having a similar error with the Opencode Go Provider, Model MiMo V2.5 advertises audio support but the read tool drops it as a binary file, there is already a PR on #18005