fix: detect Ollama vision capability from capabilities array

[dishit-wednesday]

Summary

• Ollama now exposes multimodal support via a top-level capabilities array (e.g. ["completion", "vision", "tools", "thinking"]) for newer models like Gemma 4
• The old code only checked model_info keys for "vision"/"clip" patterns — Gemma 4's model_info has neither, so it was always detected as non-vision
• Also wires supportsToolCalling from the capabilities array (was previously only detected for LM Studio)

Detection priority order (most to least reliable):

1. capabilities array — new Ollama format, explicit
2. model_info key scan — old format, still works for older models
3. projector_info key scan — fallback for models with a projector but no capabilities array

Test plan

• Select an Ollama model with vision (e.g. huihui_ai/gemma-4-abliterated:12b) — image attachment button should appear in chat
• Select a non-vision Ollama model — image attachment button should not appear
• Select an older vision model (e.g. llava) — still detected correctly via model_info fallback
• Existing unit tests: npm test -- --testPathPattern=remoteModelCapabilities (25 tests, all pass)

🤖 Generated with Claude Code

[greptile-apps]

Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.

[gemini-code-assist]

Code Review

This pull request enhances Ollama model capability extraction by parsing the top-level capabilities array for vision and tool calling support, and fallback checking projector_info for multimodal models. Feedback highlights a potential issue where returning supportsToolCalling as undefined for older models could overwrite default capabilities during an object merge, and suggests conditionally including the property only when it is defined.

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]

If supportsToolCalling is undefined (which happens for older Ollama models that do not expose the capabilities array), returning it explicitly as undefined in the object will overwrite the default supportsToolCalling: true when merged via object spread in OpenAICompatibleProvider.updateCapabilities (i.e., { ...this.modelCapabilities, ...capabilities }). This would unintentionally disable tool calling for all older Ollama models.

We should conditionally include supportsToolCalling in the returned object only when it is explicitly defined.

  return {
    contextLength,
    supportsVision,
    ...(supportsToolCalling !== undefined ? { supportsToolCalling } : {}),
    supportsThinking,
  };

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud