[ENHANCEMENT] "Ollama compatible" model provider

[kneczaj]

Problem (one or two sentences)

I try to use Inferencer app with RooCode https://inferencer.com/

Inferencer seems to work noticeable faster than Ollama with local models. I have tested it with GLM-4.7-Flash, so I say it after working with this model exactly. It also supports MLX models. As I had problems with LM Studio due to more memory it requires, this is the only MLX supporting runner working for me for now.

Context (who is affected and when)

RooCode v3.21.3
Inferencer v.1.9.5

Inferencer has option to provide "Ollama compatible API", and this is JSON response of its /api/tags endpoint at my machine:

{
  "models": [
    {
      "name": "/inferencerlabs/glm47flashmlx:o",
      "model": "/inferencerlabs/glm47flashmlx:o",
      "modified_at": "2026-02-08T23:57:04.212606191+01:00",
      "size": 24336701885,
      "digest": "54515c0a8d28bed854515c0a8d28bed854515c0a8d28bed854515c0a8d28bed8",
      "details": {}
    },
    {
      "name": "/blobs/inferencerlabs/glm47flashmlx:o",
      "model": "/blobs/inferencerlabs/glm47flashmlx:o",
      "modified_at": "2026-02-08T23:57:04.212606191+01:00",
      "size": 24336701885,
      "digest": "64e5b35b68419b2164e5b35b68419b2164e5b35b68419b2164e5b35b68419b21",
      "details": {}
    }
  ]
}

As you see it lacks "details" key. I think this is the problem which causes RooCode not to find any of the provided models.

However, I have managed to run Inferencer with Roo Code v3.21.2, and it works like a charm :D. Then v3.21.3 already does not detect models from Inferencer. I tested multiple newer versions including the newest 3.47.3 and non of them was able to connect to the model.

What I see at RooCode v3.21.3 and newer:
The model ID (/inferencerlabs/glm47flashmlx:o) you provided is not available. Please choose a different model.

Desired behavior (conceptual, not technical)

Possibility to show all models provided by Ollama API even if only minimum information about the model like at the attached JSON is available. Possibility to connect with any of these models.

Constraints / preferences (optional)

No response

Request checklist

• I've searched existing Issues and Discussions for duplicates
• This describes a specific problem with clear context and impact

Roo Code Task Links (optional)

No response

Acceptance criteria (optional)

No response

Proposed approach (optional)

I understand that there are probably more Ollama API features used at "Ollama" model provider, and they are needed. The proposition is to add "Ollama compatible" mode with minimal API requirement at least when it comes to models discovery. It would be handy for cooperating with third party tools like Inferencer.

Trade-offs / risks (optional)

No response

[roomote]

I've analyzed this issue and identified two root causes in src/api/providers/fetchers/ollama.ts that prevent Ollama-compatible APIs (like Inferencer) from working:

Root Cause 1: Strict Zod schema on /api/tags response

The OllamaModelDetailsSchema requires family (string) and parameter_size (string) as mandatory fields, and OllamaModelSchema requires details to match that schema. When Inferencer returns "details": {}, OllamaModelsResponseSchema.safeParse() fails, rejecting the entire model list. No models are even attempted via /api/show.

Root Cause 2: Strict tools capability filter

Introduced in PR #10735 (v3.21.3), parseOllamaModel now rejects any model where capabilities does not include "tools". Since Inferencer likely does not implement the /api/show capabilities field, models would be filtered out even if the schema issue were fixed.

---

Proposed implementation plan:

1. Make details lenient in the /api/tags schema - Change OllamaModelSchema so details is optional (.optional()). The /api/tags endpoint is only used to get the model names for subsequent /api/show calls, so strict details validation here is unnecessary. Models with empty or missing details should still be passed through to the /api/show step.

2. Make /api/show response schema more lenient - In OllamaModelInfoResponseSchema, make details and model_info optional. This allows Ollama-compatible APIs that don't fully implement /api/show to still return usable model info.

3. Handle missing details gracefully in parseOllamaModel - Use fallback values (e.g. "unknown") for family and parameter_size when details is empty or missing. Update the description string to handle these gracefully.

4. Allow models through when capabilities are unknown - When the /api/show response does not include capabilities (i.e. it's undefined), treat the model as potentially tool-capable rather than filtering it out. This preserves the existing filter for models that explicitly report not supporting tools, while accommodating Ollama-compatible APIs that don't report capabilities at all. The reasoning: if a user explicitly configured a model in their Ollama-compatible runner, they likely want to use it.

5. Add tests - Add test cases for:

   • Models with empty details in /api/tags response
   • Models with missing capabilities being included (not filtered)
   • Models with missing model_info and details in /api/show response

This approach keeps backward compatibility with real Ollama while being tolerant of Ollama-compatible APIs that implement a subset of the API.

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