Images pasted with a custom-provider model are silently replaced by a "[Attached image/png: ...]" text placeholder — no warning, even when the upstream model has vision #47480

Activity

1. github-actions

   assigned

   neriousy

   on Sep 5, 2026
2. github-actions commented on Sep 5, 2026

   

   github-actionsBot

   on Sep 5, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Registry-sourced models resolve empty input capabilities; file-part rejection echoes wrong media type #44639: Registry-sourced models resolve empty input capabilities — same root cause (capability defaults to false for non-bundled models, image parts rejected/replaced) and identical workaround (explicit per-model capability override in opencode.json). That report also covers the misleading error message path.
   • [BUG]: interactive image file part is persisted but not always forwarded to the model #39083: Image file part persisted but not always forwarded to the model — overlapping symptom (model responds as though no image was provided despite valid part in session).
   • Unable to read images for some models #5359: Unable to read images for some models — same surface symptom with a custom OpenAI-compatible provider (LiteLLM/Vertex AI), though the root cause there may differ.

   If your issue is specifically about the silent text-placeholder substitution with no warning (rather than an outright rejection or missing forwarding), it may be distinct enough to stand on its own — please check the above and close or cross-link as appropriate.
3. eddoww commented on Sep 18, 2026

   

   eddoww

   on Sep 18, 2026

   More actions

   Confirming this on a self-hosted OpenAI-compatible gateway/router, configured as a custom provider that lives only in opencode.json and uses @ai-sdk/openai-compatible. Two paths hit the same capability gate:

   1. Attaching/pasting an image is rewritten to a [Attached image/png: …] placeholder.
   2. Reading a local image via the Read tool returns ERROR: Cannot read "image.png" (this model does not support image input).

   Minimal repro:

   {
     "provider": {
       "mygateway": {
         "npm": "@ai-sdk/openai-compatible",
         "options": { "baseURL": "https://gateway.example.com/v1" },
         "models": {
           "my-vision-alias": { "name": "my-vision-alias" }
         }
       }
     }
   }

   The upstream route is vision-capable: sending the exact same image directly to the gateway as a base64 image_url data URI via curl works and the model describes it correctly. So this is client-side capability resolution, not the model or the gateway — the custom model's capabilities.input resolves to ["text"] (no models.dev entry, and the gateway's /v1/models carries no modality metadata), so image/* parts are dropped before they reach the already-functional OpenAI-compatible conversion.

   Workaround that works today — declare modalities explicitly per model:

   "my-vision-alias": {
     "name": "my-vision-alias",
     "attachment": true,
     "modalities": { "input": ["text", "image"], "output": ["text"] }
   }

   Related: #44639 (same root cause plus the misleading error), #20802, and the proposed defaults in #21627 / #23501. Flipping the default for custom @ai-sdk/openai-compatible models would remove the need for per-model config that most users won't discover.
4. saiqulhaq-hh commented on Sep 25, 2026

   

   saiqulhaq-hh

   on Sep 25, 2026

   More actions

   Still hit this in 1.18.32 (newer than the 1.18.25 / 1.18.29 verified versions in this thread). Same LiteLLM OpenAI-compatible custom-provider scenario as @eddoww — litellm.hhstaging.dev/v1 proxying minimax/MiniMax-M3 (model advertises supports_vision: true in the litellm admin UI and accepts the same base64 image_url payload via direct curl with 200 + correct description).

   opencode.jsonc:

   "minimax/MiniMax-M3": {
     "name": "MiniMax M3",
     "attachment": true,
     "modalities": { "input": ["text", "image"] }
   }

   Read tool still returns:

   ERROR: Cannot read "screenshot.png" (this model does not support image input)
   

   Root cause in the binary (verified by strings on the embedded JS bundle in opencode 1.18.32): the conversion cascade for user-defined custom-provider models ends up with Z.capabilities.input as an array ["text","image"], but the read tool's filter does Z.capabilities.input[W] (array index-by-string → undefined). The object form {image: true, ...} is only populated when a models.dev registry entry exists for the model (J.input_modalities?.includes("image")); for custom aliases with no registry entry the cascade falls through to Y?.capabilities.input.image, which is never set because the public user schema doesn't expose capabilities.

   The exact gating line in the read-tool message filter:

   if (Z.capabilities.input[W]) return J;          // W = "image"
   return { type: "text", text: `ERROR: Cannot read ${G ?? W} (this model does not support ${W} input). Inform the user.` };

   Workarounds tried, both inert in 1.18.32:

   • attachment: true — sets a separate capabilities.attachment bool used by the UI affordance; does not populate capabilities.input.image.
   • modalities: { input: ["text", "image"] } — copied into capabilities.input as an array, but the read tool's key lookup still misses.

   Suggested fix: in the user-config → internal-model converter, when no models.dev entry exists for the model, translate modalities.input[] into the object form so capabilities.input.image resolves truthy for the read-tool filter. Or expose capabilities (or just capabilities.input: { image?: boolean, ... }) as a user schema field with the same boolean keys the resolver already consumes.

   Until then, this binary is unusable for vision via custom-provider aliases — even when the upstream endpoint is fully vision-capable.
5. thdxr commented on Oct 11, 2026

   

   thdxr

   on Oct 11, 2026

   Member

   More actions

   Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

   — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊
6. thdxr

   closed this as not plannedon Oct 11, 2026