Summary
V2 filters media by model input capability, but does not separately account for whether the selected provider protocol can represent that media inside a tool result. A vision-capable model can therefore receive a valid tool-result image at the canonical layer while its provider adapter cannot place that image in the protocol-native tool-result shape.
Environment
- opencode version: V2 development branch
- OS: Not environment-specific
- Terminal: Not applicable
- Shell: Not applicable
- Install/channel: V2 development
- Active plugins: Not applicable
Reproduction
- Select a model that supports image input through a provider protocol that cannot carry images inside tool results.
- Have the model call a local tool such as
read that returns an image.
- Continue the session so the tool result is included in the next model request.
Expected Behavior
Request preparation should distinguish model modality support from provider tool-result placement support. When the model supports the media but the protocol cannot carry it inside a tool result, preserve textual tool output and inject the media through a synthetic user message or another protocol-supported placement.
Actual Behavior
The existing capability filter preserves the image because the model supports image input. The generic bridge then emits typed tool-result media, leaving provider adapters that cannot represent that placement to reject, omit, or mishandle it.
Additional Context
This is separate from unsupported-model handling in SessionModelRequest.unsupportedParts, which correctly replaces media with explanatory text when the model lacks that modality.
The placement policy should live above the generic AI SDK bridge and should cover images and other supported media types according to provider protocol capabilities. V1 has related provider-specific extraction and synthetic-user behavior in packages/opencode/src/session/message-v2.ts.
Related PR: #41672
Summary
V2 filters media by model input capability, but does not separately account for whether the selected provider protocol can represent that media inside a tool result. A vision-capable model can therefore receive a valid tool-result image at the canonical layer while its provider adapter cannot place that image in the protocol-native tool-result shape.
Environment
Reproduction
readthat returns an image.Expected Behavior
Request preparation should distinguish model modality support from provider tool-result placement support. When the model supports the media but the protocol cannot carry it inside a tool result, preserve textual tool output and inject the media through a synthetic user message or another protocol-supported placement.
Actual Behavior
The existing capability filter preserves the image because the model supports image input. The generic bridge then emits typed tool-result media, leaving provider adapters that cannot represent that placement to reject, omit, or mishandle it.
Additional Context
This is separate from unsupported-model handling in
SessionModelRequest.unsupportedParts, which correctly replaces media with explanatory text when the model lacks that modality.The placement policy should live above the generic AI SDK bridge and should cover images and other supported media types according to provider protocol capabilities. V1 has related provider-specific extraction and synthetic-user behavior in
packages/opencode/src/session/message-v2.ts.Related PR: #41672