[FEATURE]: Add supportsAttachments/vision capability for custom providers

Feature hasn't been suggested before.

I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem

Custom providers using @ai-sdk/openai-compatible cannot send image attachments to vision-capable models. Attachments
are silently stripped before the request is sent.

Root Cause

In internal/llm/models/, SupportsAttachments is hardcoded per-model for built-in providers only. Custom provider
models return empty from SupportedModels, defaulting SupportsAttachments to false.

The stripping happens in the agent code:

go
if !a.provider.Model().SupportsAttachments && attachments != nil {
    attachments = nil
}

Use Case

I'm running a local OpenAI-compatible proxy (kiro-gateway) that supports vision. The proxy correctly handles images (
verified via curl), but opencode strips them before sending because it doesn't know the custom model supports
attachments.

Proposed Solution

Add a supportsAttachments (or capabilities.vision) option to custom provider model config:

json
{
  "provider": {
    "my-proxy": {
      "npm": "@ai-sdk/openai-compatible",
      "options": { "baseURL": "http://localhost:8000/v1" },
      "models": {
        "claude-sonnet-4-5": {
          "name": "Claude Sonnet 4.5",
          "supportsAttachments": true
        }
      }
    }
  }
}

Alternatives Considered

Model aliases matching built-in names - custom providers don't inherit built-in model capabilities

Environment

opencode version: latest
OS: Linux

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

[FEATURE]: Add query parameter support for custom OpenAI-compatible providers #7198: [FEATURE]: Add query parameter support for custom OpenAI-compatible providers - addresses configuration extensibility for custom providers with @ai-sdk/openai-compatible
Custom OpenAI-compatible provider returns no text content #5210: Custom OpenAI-compatible provider returns no text content - highlights issues with custom provider model capabilities not being properly recognized

Feel free to ignore if none of these address your specific case.

The feature already exists in opencode - it's just not documented! closing this issue for now

The modalities config option is already supported.

"modalities": {
  "input": ["text", "image"],
  "output": ["text"]
}

The implementation is in provider.ts lines 760-764:

image: model.modalities?.input?.includes("image") ?? existingModel?.capabilities.input.image ?? false,

Add this to the custom provider section at https://opencode.ai/docs/providers/#custom-provider to make the users figure this easily 👍

@karthick-kk

@karthick-kk worked thank you!

roadmap: #220 filed — Image/vision input is structurally impossible a…

roadmap: ultraworkers#220 filed — Image/vision input is structurally …

roadmap: #220 filed — Image/vision input is structurally impossible a…

The feature already exists in opencode - it's just not documented! closing this issue for now

The modalities config option is already supported.

"modalities": {
"input": ["text", "image"],
"output": ["text"]
}
The implementation is in provider.ts lines 760-764:

image: model.modalities?.input?.includes("image") ?? existingModel?.capabilities.input.image ?? false,
Add this to the custom provider section at https://opencode.ai/docs/providers/#custom-provider to make the users figure this easily 👍

Does this also work with "audio"?
(for Gemma4 models and others ...)

Navigation Menu

Repository navigation

[FEATURE]: Add supportsAttachments/vision capability for custom providers #8875

Feature hasn't been suggested before.

Describe the enhancement you want to request

Problem

Root Cause

Use Case

Proposed Solution

Alternatives Considered

Environment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE]: Add supportsAttachments/vision capability for custom providers #8875

Description

Feature hasn't been suggested before.

Describe the enhancement you want to request

Problem

Root Cause

Use Case

Proposed Solution

Alternatives Considered

Environment

Activity

github-actions commented on Jan 16, 2026

karthick-kk commented on Jan 16, 2026

1saifj commented on Feb 1, 2026

schoenid commented on Jun 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions