[BUG] GEMMA 4 has Vision but ROO CODE says Does not support images

[DATEx2]

Problem (one or two sentences)

Family: gemma4, Context: 262144, Size: 25.2B

gemma4:26b-q4_K_M-unsloth-65536
Context Window: 65,536 tokens
Max output: 262,144 tokens
Does not support images
Supports prompt caching
65536

https://playground.roboflow.com/models/qwen/qwen3-6-35b-a3b
It says it has multimodal vision
Why is that ROO CODE says it does not support images?

Context (who is affected and when)

gemma4:26b-q4_K_M-unsloth-65536

Reproduction steps

Choose Ollama
Choose gemma4:26b-q4_K_M-unsloth-65536
See that Does not support images is shown

Expected result

Images to be supported

Actual result

Images are not supported, also cannot paste image

Variations tried (optional)

Same model with Cline or Continue.dev works just fine with images

App Version

latest

API Provider (optional)

Ollama

Model Used (optional)

gemma4:26b-q4_K_M-unsloth-65536

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

Root cause: The Ollama model fetcher in src/api/providers/fetchers/ollama.ts determines vision support solely from the capabilities array returned by Ollama's /api/show endpoint (line 55: rawModel.capabilities?.includes("vision")). If the Ollama version or model manifest doesn't include "vision" in the capabilities array for gemma4, Roo Code will incorrectly report "Does not support images".

Proposed fix: Add a fallback vision detection mechanism in the parseOllamaModel function. When capabilities doesn't include "vision", check the model's details.families array for known vision-related family names. Vision models in Ollama typically register vision encoder families (e.g., "clip" for CLIP-based encoders, or other vision-related identifiers). Gemma 4 uses a SigLIP vision encoder which may appear as a distinct family.

Implementation steps:

1. In src/api/providers/fetchers/ollama.ts, update the parseOllamaModel function to add a fallback check: if capabilities doesn't include "vision", inspect rawModel.details.families for known vision encoder families (e.g., "clip", "siglip", "mmproj", etc.) and also check rawModel.model_info keys for vision-related architecture indicators
2. Add corresponding unit tests in src/api/providers/fetchers/__tests__/ollama.test.ts to verify the fallback detection works
3. Update the test fixtures if needed to include a gemma4-like model entry

This approach makes Roo Code more resilient when Ollama's capabilities array is incomplete, while still preferring the authoritative capabilities field when available.

Note: It would be helpful to know the exact output of ollama show gemma4:26b-q4_K_M-unsloth-65536 --json on your machine, specifically the capabilities, details.families, and model_info fields. This will confirm which fallback signals are available for gemma4.

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[DATEx2]

It seems `gemma4:26b-ab4-it-q4_K_M-65536` it works - just the `unsloth` version has the `vision` capability removed for some reason. Best Regards Laurentiu Macovei, DATEx2.bike <https://datex2.bike/?cs=email&cm=email>fb.com/DATEx2/reviews <https://facebook.com/DATEx2/reviews> bit.ly/DATEx2 <https://bit.ly/DATEX2> 65 Plugului, 805300 Tecuci, GL, RO

…

On Tue, Apr 28, 2026 at 1:32 PM roomote-v0[bot] ***@***.***> wrote: *roomote-v0[bot]* left a comment (RooCodeInc/Roo-Code#12211) <#12211 (comment)> I've analyzed this issue and here's my proposed implementation plan: *Root cause:* The Ollama model fetcher in src/api/providers/fetchers/ollama.ts determines vision support solely from the capabilities array returned by Ollama's /api/show endpoint (line 55: rawModel.capabilities?.includes("vision")). If the Ollama version or model manifest doesn't include "vision" in the capabilities array for gemma4, Roo Code will incorrectly report "Does not support images". *Proposed fix:* Add a fallback vision detection mechanism in the parseOllamaModel function. When capabilities doesn't include "vision", check the model's details.families array for known vision-related family names. Vision models in Ollama typically register vision encoder families (e.g., "clip" for CLIP-based encoders, or other vision-related identifiers). Gemma 4 uses a SigLIP vision encoder which may appear as a distinct family. *Implementation steps:* 1. In src/api/providers/fetchers/ollama.ts, update the parseOllamaModel function to add a fallback check: if capabilities doesn't include "vision", inspect rawModel.details.families for known vision encoder families (e.g., "clip", "siglip", "mmproj", etc.) and also check rawModel.model_info keys for vision-related architecture indicators 2. Add corresponding unit tests in src/api/providers/fetchers/__tests__/ollama.test.ts to verify the fallback detection works 3. Update the test fixtures if needed to include a gemma4-like model entry This approach makes Roo Code more resilient when Ollama's capabilities array is incomplete, while still preferring the authoritative capabilities field when available. *Note:* It would be helpful to know the exact output of ollama show gemma4:26b-q4_K_M-unsloth-65536 --json on your machine, specifically the capabilities, details.families, and model_info fields. This will confirm which fallback signals are available for gemma4. Please mention @roomote <https://github.com/roomote> in a comment saying that you approve this plan, and I'll proceed with the implementation. — Reply to this email directly, view it on GitHub <#12211 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUAK6IYRPM5P4DIUGBNUFXL4YCJGNAVCNFSM6AAAAACYJHIJ76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGMZUHAZDKNZRG4> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[roomote-v0]

Thanks for the additional info, @DATEx2. I've seen your comment -- it looks like the unsloth variant strips the "vision" capability from the Ollama model metadata even though the model itself supports images. I'll add a fallback detection mechanism that checks model_info keys and details.families for vision-related indicators (e.g., vision encoder families like "gemma4_vision_encoder"). Opening a draft PR shortly.

[roomote-v0]

Opened a draft PR with my attempt at addressing this: #12214

The fix adds fallback vision detection in parseOllamaModel -- when capabilities omits "vision", it checks details.families for known vision encoder families (clip, siglip, mmproj, mllama) and model_info keys for vision-related architecture indicators. This should cover the gemma4 unsloth variant and similar cases. Feedback welcome!

[DATEx2]

That was fast! Thank you! Looking forward to seeing it deployed in the next release (y)