Subagent with vision-capable model fails to analyze images

[qiqingli]

Description

An image-analyst subagent was configured using moonshotai/kimi-k2.6 (a multimodal model). Switching to this model in the main session works fine for image analysis. However, when called via subagent, it returns: "the currently running model does not support directly reading image files."
Steps to reproduce:

Environment:

• macOS
• opencode 1.17.11

Plugins

No response

OpenCode version

opencode 1.17.11

Steps to reproduce

1. Configure a vision-capable model in opencode.json:
   "moonshotai/kimi-k2.6": {
   "name": "kimi-k2.6",
   "attachment": true,
   "modalities": {
   "input": ["text", "image"],
   "output": ["text"]
   }
   }
2. Create subagent config at ~/.config/opencode/agents/image-analyst.md:

---

description: Image recognition and visual analysis agent
mode: subagent
model: Nvidia/moonshotai/kimi-k2.6
temperature: 0.1
tools:
write: false
edit: false
bash: false

3. Invoke the image-analyst subagent with an image file
4. The subagent responds that the current model does not support image input
   Expected behavior: The subagent should receive and analyze the image, just as the main session does when switched to kimi-k2.6.
   Actual behavior: The subagent reports that the model does not support image input.

Additional verification:
Directly calling the Nvidia API (kimi-k2.6 model) via curl successfully analyzes the image, confirming there is no issue at the API level. The problem lies in opencode's subagent mechanism, which fails to pass image attachments to the subagent's model.

Screenshot and/or share link

No response

Operating System

macOS 13.7.8

Terminal

iTerm2

[github-actions]

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

• bug: @mention subagent with attached image in Web UI — image not forwarded to multimodal subagent #25553: Same root cause — image not forwarded to multimodal subagent, parent agent errors with "this model does not support image input"
• Bug: opencode-go/kimi-k2.6 fails in child sessions with "image.png" error #24454: Same symptom with kimi-k2.6 specifically — works in main session but fails in child/subagent sessions with image input error

[CSWNDQTJ-Kenny]

Hi @reporter — I hit the exact same bug (GLM-5.2-Coding parent + multimodal subagent on 1.17.20) and traced it down to the source bundle. Sharing root cause + a minimal patch in case it helps the maintainers.

Root cause

TaskTool.execute receives ctx.messages (the full parent session, including image file parts), but runTask builds the child subagent prompt only from params.prompt:

// runTask, inside TaskTool.execute
const parts6 = await ops.resolvePromptParts(params.prompt);
// ↑ resolvePromptParts only walks text + markdown file references,
//   it never reads ctx.messages, so image parts are dropped here
await ops.prompt({ parts: parts6 });

So the image attached to the parent user message is never forwarded into the child subagent prompt, regardless of whether the child model is multimodal. The "model does not support image input" error comes from a different downstream issue (see below) — the image never even reaches the child model's unsupportedParts check in the first place.

Minimal patch

Insert image extraction between resolvePromptParts and ops.prompt:

const parts6 = await ops.resolvePromptParts(params.prompt);
const imageParts = (ctx.messages ?? [])
  .flatMap((m) => m.parts ?? [])
  .filter((p) => p.type === "file" && p.mime?.startsWith("image/"))
  .map((p) => ({ type: "file", mime: p.mime, url: p.url, filename: p.filename }));
if (imageParts.length > 0) parts6.push(...imageParts);
await ops.prompt({ parts: parts6 });

Related secondary bug — unsupportedParts modalities format

Even with the patch above, some custom OpenAI-compatible providers (kimi-vision, doubao, MiMo-V2.5) still fail because unsupportedParts assumes capabilities are stored as an array:

model.capabilities.modalities.input.includes("image")  // throws if input is an object

But providers defined via config get capabilities built as a boolean object in the configProviders loop:

{ input: { image: true, text: true }, output: { text: true } }

So .includes("image") throws / returns undefined, the image gets stripped, and the child model never sees it. The unsupportedParts check needs to handle both formats:

const input = model.capabilities?.modalities?.input ?? {};
const supportsImage = Array.isArray(input)
  ? input.includes("image")
  : input.image === true;

This is also tracked in #30071.

Verification

Patched both runTask and unsupportedParts in app.asar on 1.17.20 → @image subagent (MiMo-V2.5) correctly receives and analyzes attached PNG. Confirmed via server logs that child session now receives file parts with image/png mime.

Happy to open a PR if maintainers confirm the approach. This is also tracked in #32302 (stalled since June) — both fixes are needed.

[guaccio2209]

Same root cause confirmed on the hosted relay (OpenCode Go plan) — with A/B evidence

I'm hitting this exact bug, but on the hosted relay (https://opencode.ai/zen/go/v1, the endpoint behind the paid OpenCode Go subscription), not just the CLI subagent path. Worth adding to this issue since it means paying subscribers are affected too.

A/B test, same payload, same model (gpt-5.6-luna, which is vision-capable per OpenRouter's registry):

1. OpenRouter — POST https://openrouter.ai/api/v1/chat/completions, message content = [{type: text}, {type: image_url, image_url: {url: }}]
   → HTTP 200, correct answer ("Red" for a red test image). Works.

2. OpenCode relay — identical payload to https://opencode.ai/zen/go/v1/chat/completions with model: "gpt-5.6-luna"
   → HTTP 400 with empty choices:

{"id":"chatcmpl_...","object":"chat.completion","choices":[{"index":0,"message":{"role":"assistant"},"finish_reason":null}]}

Text-only request to the same endpoint → HTTP 200. Fails only when an image is included.

The image part never reaches the model, it's stripped somewhere between the relay and the upstream API. This matches the behavior described in #30071 (image inputs silently removed for OpenAI-compatible providers).

This also affects @CSWNDQTJ-Kenny's PR #39417 (closed): the fix targets the CLI subagent path, but the hosted relay appears to have the same stripping behavior independently.

Request: could the maintainers confirm whether image passthrough is supported on the zen/go relay endpoint, and if so, what the correct request format is? Happy to provide a full request/response dump (with sanitized keys) to help debug.