fix: respect multimodal provider vision capabilities

[code-yeongyu]

Summary

• cache provider-declared image-capable models from modalities and capabilities during config handling
• build a dynamic multimodal-looker fallback chain that prefers configured vision-capable providers before the static hardcoded chain
• add focused tests for provider vision caching and multimodal looker model resolution

Testing

• bun test
• bun run typecheck
• bun run build

---

Summary by cubic

Respect provider-declared vision support for multimodal-looker by caching image-capable models and building a provider-aware fallback chain that preserves hardcoded variant behavior. Addresses Linear 2323.

• Bug Fixes
  • Detect and cache vision-capable models from modalities.input or capabilities.input.image; track in plugin state and a shared store; clear stale entries on config updates.
  • Build a dynamic multimodal-looker fallback chain from cached models, merged with the static chain without duplicates; prefer connected providers and fall back to the static chain when needed.
  • Resolve agent metadata via the model-resolution pipeline using available models and connected providers; keep the configured model when it matches a vision-capable option and preserve the registered variant.
  • Add tests for provider caching, dynamic chain behavior, and agent model resolution; rename a test to .ts for proper execution.

^{Written for commit e513f66. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 7 files

Confidence score: 3/5

• There is a concrete compatibility risk in src/plugin-handlers/provider-config-handler.test.ts: the issue indicates ProviderConfig.models.capabilities is not a valid OpenCode SDK field, so config handling/tests may diverge from actual SDK behavior.
• Given the 6/10 severity with high confidence (10/10), this is more than a housekeeping concern and could cause user-facing misconfiguration around model/image capability declarations.
• Pay close attention to src/plugin-handlers/provider-config-handler.test.ts - compatibility expectations may be encoded against an unsupported capabilities property.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/plugin-handlers/provider-config-handler.test.ts">

<violation number="1" location="src/plugin-handlers/provider-config-handler.test.ts:35">
P2: Custom agent: **Opencode Compatibility**

According to the OpenCode SDK source code, `capabilities` is not a valid property within `ProviderConfig.models`. Image support in user configuration is exclusively declared using `modalities: { input: ['image'] }`. The `capabilities` object is an internal model representation in OpenCode and is not exposed in the user-facing configuration schema.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P2: Custom agent: Opencode Compatibility

According to the OpenCode SDK source code, capabilities is not a valid property within ProviderConfig.models. Image support in user configuration is exclusively declared using modalities: { input: ['image'] }. The capabilities object is an internal model representation in OpenCode and is not exposed in the user-facing configuration schema.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/plugin-handlers/provider-config-handler.test.ts, line 35:

<comment>According to the OpenCode SDK source code, `capabilities` is not a valid property within `ProviderConfig.models`. Image support in user configuration is exclusively declared using `modalities: { input: ['image'] }`. The `capabilities` object is an internal model representation in OpenCode and is not exposed in the user-facing configuration schema.</comment>

<file context>
@@ -0,0 +1,84 @@
+        google: {
+          models: {
+            "gemini-3-flash": {
+              capabilities: {
+                input: {
+                  image: true,
</file context>

[cubic-dev-ai]

1 issue found across 2 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/tools/look-at/multimodal-fallback-chain.ts">

<violation number="1" location="src/tools/look-at/multimodal-fallback-chain.ts:41">
P2: Sort `existingIndexes` to preserve dynamic fallback priority and chain ordering when merging entries.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P2: Sort existingIndexes to preserve dynamic fallback priority and chain ordering when merging entries.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/tools/look-at/multimodal-fallback-chain.ts, line 41:

<comment>Sort `existingIndexes` to preserve dynamic fallback priority and chain ordering when merging entries.</comment>

<file context>
@@ -37,13 +37,45 @@ export function buildMultimodalLookerFallbackChain(
     )
-    if (providerModelKeys.every((key) => seen.has(key))) {
+
+    const existingIndexes = [...new Set(
+      providerModelKeys
+        .map((key) => entryIndexByKey.get(key))
</file context>

Suggested change

	const existingIndexes = [...new Set(
	providerModelKeys
	.map((key) => entryIndexByKey.get(key))
	.filter((index): index is number => index !== undefined),
	)]
	const existingIndexes = [...new Set(
	providerModelKeys
	.map((key) => entryIndexByKey.get(key))
	.filter((index): index is number => index !== undefined),
	)].sort((a, b) => a - b)