Enable model discovery (Fetch models) for the Ollama BYOK provider

[dpeterson01]

What problem are you trying to solve?

Running Open Design against a local Ollama server (BYOK → Ollama provider pointed at a local endpoint), the Fetch models button is disabled and model discovery returns an unsupported_ollama result. I can't auto-populate the models I actually have installed, so I have to know and type each model id by hand.

Every other supported protocol (OpenAI, Anthropic, Google, AIHubMix, SenseAudio) can fetch its catalogue. Ollama is the one gap, even though it exposes a discovery endpoint (GET /api/tags) that lists locally-pulled models. So the capability exists on the provider side; the daemon just doesn't call it.

Related: I opened #6076, which lets you at least type a custom model id in the onboarding BYOK picker. Discovery would remove the guesswork entirely.

Describe the solution you'd like

Wire up the daemon's provider-model discovery for the ollama protocol in apps/daemon/src/integrations/provider-models.ts:

• providerModelsUrl: GET {baseUrl}/api/tags
• an extractOllamaModels parser for the { models: [{ name, ... }] } response shape → { id, label }
• headers: none needed for local Ollama (unauthenticated); optional bearer if a key is supplied

Then remove the apiProtocol === 'ollama' short-circuits in the front-end gates (EntryShell.tsx, SettingsDialog.tsx, InlineModelSwitcher.tsx, AvatarMenu.tsx) so Fetch models lights up and populates the installed models.

Design question I'd like to settle before coding

The protocol is labeled "Ollama Cloud" and defaults to ollama.com, but /api/tags is a local Ollama endpoint. I suspect discovery was stubbed on purpose because the cloud endpoint behaves differently. Before writing a PR I'd like to agree on the boundary:

• Option A: only attempt /api/tags when the base URL is a loopback/local host, and keep the current "not available" message for genuine cloud endpoints.
• Option B: always attempt it and let it fail gracefully for cloud.

I lean toward A. It respects what looks like a deliberate choice and avoids confusing people who really are pointed at the cloud. Does that match your intent, or is there a reason discovery was left off that I'm missing?

Alternatives you've considered

• Typing the model id by hand. Works, but you have to remember exact ids and tags. allow custom model entry in the onboarding BYOK model picker #6076 at least makes this possible during onboarding.
• Relying on the suggestion list only. Misses any locally-installed or newer model.

Additional context

Related PR: #6076 (custom model entry in the onboarding BYOK picker).

Would you be willing to contribute a PR?

Yes, with guidance from a maintainer.

[open-design-bot]

🎉 ✨ Welcome to Open Design, @dpeterson01!

✨ 🔥 Lit the spark.

🌱 Your first contribution adds energy to the project. Thanks for showing up and helping Open Design grow.

💛 Thanks for helping Open Design grow. Keep building in the open. 🚀

🔗 Share on X (English) · 分享到 X（中文）

[lefarcen]

Hi @dpeterson01! Thanks for writing this up so clearly — the split between local Ollama discovery and Ollama Cloud is exactly the right boundary to call out.

I checked the current implementation, and your read matches the code:

• apps/daemon/src/integrations/provider-models.ts only implements discovery for OpenAI / SenseAudio, Anthropic, Google, and AIHubMix right now, so ollama falls through as unsupported.
• On the web side, model discovery is explicitly blocked for ollama in EntryShell.tsx, SettingsDialog.tsx, InlineModelSwitcher.tsx, and AvatarMenu.tsx.
• The existing UI copy also frames this as an Ollama Cloud limitation (settings.fetchModelsUnsupportedOllama), not a generic "Ollama can never fetch models" decision.

So for this issue, Option A looks like the right first step: enable /api/tags only for local/loopback Ollama base URLs, and keep the current fallback for real ollama.com / cloud endpoints. That also lines up with the codebase's current direction: we already have a local-Ollama guard in apps/web/src/utils/byokProvider.ts, and local Ollama is already treated specially in a few BYOK paths.

One nuance worth keeping in scope: the current local helper is strictly loopback (localhost, 127.0.0.1, ::1), so LAN/self-hosted remote Ollama would still be a separate expansion from this issue.

Related context:

• allow custom model entry in the onboarding BYOK model picker #6076 already improves the manual-entry fallback during onboarding.
• Added Ollama API Support + Claude Code Integration with Ollama Launch #673 is the broader native Ollama support thread, but this issue is a good focused slice for BYOK model discovery.

A PR for the local-only path would be welcome here. The shape you outlined — daemon discovery + Ollama response parsing + removing the frontend short-circuits for the local case — is the direction we’d want to review. ❤️

[lefarcen]

This is open for community help — if you'd like to take it, comment /claim and we can track it with you.

[dpeterson01]

/claim

[lefarcen]

Hey @dpeterson01 — thanks for picking this up. The local-only Ollama discovery slice is a great one to push on.

Roughly how long do you think it'll take: a few hours, 1–3 days, about a week, or longer?

[dpeterson01]

Follow-up on scope now that the PR is up (#6079).

That PR keeps discovery strictly loopback (localhost / 127.0.0.1 / ::1), matching what we agreed here.

The adjacent case I'd like to handle next: Open Design running in Docker, where the container reaches the host's Ollama via host.docker.internal rather than loopback. Today the loopback gate (correctly) leaves "Fetch models" disabled there, so Dockerized users fall back to manual entry. The daemon can already reach that host when it's covered by OD_ALLOWED_INTERNAL_HOSTS, so enabling discovery is a small gate change: treat host.docker.internal as a local Ollama host for discovery.

Would you prefer that as a separate follow-up issue/PR, or folded into #673? Happy to take it either way once #6079 lands.

[lefarcen]

PR #6079 is now up for this and keeps the boundary discussed here: local/loopback Ollama only, with Ollama Cloud still left on the existing unsupported path.

It wires /api/tags into daemon-side model discovery and updates the existing BYOK model-fetch surfaces to enable the current flow for local Ollama. Keeping this issue open until that PR lands.

[lefarcen]

Hey @dpeterson01 — I’d keep that as a separate follow-up from #673.

host.docker.internal still feels like the same BYOK discovery path as #6079, just one narrow expansion of the local-host gate for Docker setups that are already explicitly trusted via OD_ALLOWED_INTERNAL_HOSTS. #673 is the broader native-Ollama track, so folding this into that would make the scope fuzzier than it needs to be. If you want to take it next after #6079 lands, a small follow-up issue/PR with exactly that boundary sounds right.

[lefarcen]

Quick state sync: #6079 is now in reviewer hands, so let’s keep this issue pinned to the original loopback-only scope until that lands.

After that, please feel free to open the host.docker.internal expansion as a separate follow-up from #673 — that still looks like the cleanest next slice.

[dpeterson01]

Thanks for the state sync, and sorry I ran past your timing question earlier. It came together in a few hours: #6079 is up with the loopback-only slice, daemon + web tests, and a manual check against a local Ollama.

Agreed on keeping this one pinned to loopback-only until #6079 lands. Once it does, I'll open the host.docker.internal expansion as its own small follow-up, separate from #673, scoped to exactly that gate change for Docker setups already trusted via OD_ALLOWED_INTERNAL_HOSTS.

[lefarcen]

No worries — the “few hours” update helps, and thanks for circling back with it.

The loopback-only slice in #6079 sounds exactly right, and keeping the host.docker.internal expansion as its own follow-up after this lands is the cleanest next step.