[diego-anselmo]

Problem

Combo routing can send a request carrying an image to a text-only model. getResolvedModelCapabilities returns supportsVision: null for any model lacking a models.dev attachment flag and a registry vision flag — including multimodal Mistral Pixtral — and the combo compatibility filter only dropped a target when supportsVision === false. So a null (unknown) text model such as ministral-14b slipped through, received the image, and answered "image not provided" / IMAGEM_INDISPONIVEL.

Not a payload-format bug. Verified live: pixtral-12b describes the same image identically whether image_url is the OpenAI object { "url": ... } or a bare string. The original report's A/B was confounded — its two rows hit different effective models via a vision combo (a text-only ministral vs pixtral), so the format was never the cause.

Fix

1. src/lib/modelCapabilities.ts — resolveVisionCapability gains a conservative, last-resort model-id heuristic (VISION_MODEL_ID_FRAGMENTS) so known multimodal families (pixtral, llava, qwen-vl, gpt-4o, gemini, claude-3+, glm-4v, mistral-medium-3, …) resolve to true when no synced/registry/spec data exists. Kept high-precision on purpose: a false positive would re-create the bug. Anything unmatched stays null.
2. open-sse/services/combo.ts — for a request that carries an image, a target is vision-incompatible unless supportsVision === true (was === false). The existing "keep all when none qualify" fallback preserves behavior for combos with no confirmed-vision member, so there is no regression. filterTargetsByRequestCompatibility is exported for the test.

Tests

tests/unit/combo-vision-aware-routing.test.ts (red → green):

• heuristic resolves Pixtral → true; a text-only Mistral model is not a vision false-positive;
• image request drops the non-vision target and keeps the vision target;
• image request with no confirmed-vision target keeps all (fallback, no regression);
• text-only request is untouched by the vision filter.

typecheck:core + eslint clean. Existing suites green (model-capabilities-registry, combo-projection-capabilities-3979, provider-registry-qwen-vision #2822, guardrails/visionBridge, auto-combo).

Follow-ups (separate)

• Consolidate the 3 independent vision-detection lists (VISION_MODEL_ID_FRAGMENTS, catalog VISION_MODEL_KEYWORDS, lite modelSupportsVision) into one shared source.
• Audit why models.dev sync delivers no vision/attachment for Mistral models (root cause behind the null; the heuristic is the safety net).

[gemini-code-assist]

Code Review

This pull request improves combo routing for image requests by ensuring they are only routed to models with confirmed vision capabilities (treating false and null as incompatible), and introduces a fallback heuristic to identify multimodal models by their ID fragments when registry data is missing. Feedback on the changes points out that "gpt-4.1" is likely a typo for "gpt-4.5", and "mistral-medium-3" should be removed from the vision model list as it is a text-only model family.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The model fragment "gpt-4.1" appears to be a typo. OpenAI has not released a "GPT-4.1" model. If you intended to target the multimodal GPT-4.5 family (e.g., gpt-4.5-preview), this should be corrected to "gpt-4.5".

Suggested change

	"gpt-4.1",
	"gpt-4.5",

[gemini-code-assist]

The model fragment "mistral-medium-3" is included in the vision model list, but the Mistral Medium family (including any potential v3 or mistral-medium-latest) consists of text-only models. Including it here could lead to false positives where image requests are routed to a text-only model, which is the exact bug this PR is trying to prevent. Please remove this fragment.

[diego-anselmo]

Follow-up issues opened from this work (each self-contained with file paths, repro, and acceptance):

• fix(capabilities): models.dev sync delivers no vision/attachment for Mistral models (resolve null) #4073 — root cause behind the heuristic added here: models.dev sync delivers no vision/attachment for Mistral models, so getResolvedModelCapabilities resolves null. The heuristic in this PR is the safety net; fix(capabilities): models.dev sync delivers no vision/attachment for Mistral models (resolve null) #4073 fixes the metadata pipeline.
• refactor(capabilities): unify vision model-id detection into one shared source #4072 — consolidate the 3 independent vision-detection lists (modelCapabilities / catalog / lite) into one shared source; they currently disagree (e.g. lite strips images for pixtral/llava/qwen-vl).
• fix(combo): streamed response body "model" reports a different combo member than the x-omniroute-model header #4074 — separate, pre-existing labeling bug surfaced by the new routing: streamed body model reports the combo's primary member while x-omniroute-model header reports the executed model. Observability only.

[diegosouzapw]

Thanks for the sharp fix, @diego-anselmo! 🎯 Diagnosing that combo routing only dropped a target on supportsVision === false — letting null/unknown-capability models (like Pixtral-less Mistral) receive image requests — was spot on. The two-part fix (conservative model-id heuristic + treating !== true as incompatible, with the keep-all fallback to avoid regressions) is exactly right, and the regression test covers it well. On merge I only rebaselined combo.ts in the file-size gate (+6 LOC for your comment block + the test export). Shipping in the next release. 🚀