Can't add Ollama as Custom Provider, please make localhost-adapted version

[spookynando]

[zoahdev]

Could you share the exact error text/validation message (not just the screenshot) plus the values you entered? The common failure points for a localhost custom provider:

1. baseURL shape ? Ollama's OpenAI-compatible endpoint is http://localhost:11434/v1 (some UIs validate the URL before saving);
2. model id ? must match an installed Ollama model name exactly (e.g. qwen2.5-coder:7b);
3. provider type ? if the custom provider form defaults to "OpenAI-compatible", make sure the API key field is optional/blank for Ollama.

With the error message + your saved config (redact anything sensitive), it's a quick root-cause. Happy to dig in ? and if the validation itself rejects http://localhost, that's an upstream bug worth a patch.

[denial123789]

I checked the current custom-provider implementation. It does not reject http://localhost or require a non-empty API key. The create gate requires all of these before the button enables:

• a valid lowercase Provider ID, for example ollama
• a non-empty Base URL: http://127.0.0.1:11434/v1
• API protocol: openai-completions
• at least one valid Model ID, matching ollama list exactly, including its tag

The API key can stay blank for local Ollama.

First verify from the environment running DSH:

curl http://127.0.0.1:11434/v1/models
ollama list

The important boundary is that localhost belongs to the DSH host process, not the browser. If DSH runs in Docker, WSL, a VM, or another machine, 127.0.0.1 may point at the wrong environment even though Ollama works from the laptop shell.

Stable visual guide with the exact field matrix and host-versus-browser diagnostic:
https://sandbaseai.github.io/deepseek-harness-handbook/ollama-local-provider.html

Reviewable source change:
sandbaseai/deepseek-harness-handbook#18

If creation is still disabled after adding a model row, please paste the text shown under the form and the exact field values with secrets removed; the screenshot alone cannot distinguish a missing model gate from a host reachability failure.

[weijiafu14]

Localhost custom providers do work today — we run our own E2E batteries against http://127.0.0.1:… endpoints on a stock @deepseek-ai/dsh@0.1.1-rc.2, with real turns completing through them, so here is the verified shape rather than a guess:

Option A — pure settings (settings.yaml, official llm-pi-ai adapter):

llm-pi-ai:
  providers:
    ollama:
      baseURL: http://127.0.0.1:11434/v1
      apiKeyEnv: OLLAMA_API_KEY   # Ollama ignores the value; export any non-empty string

Option B — a provider declaration through pi2dsh when you want to declare models/context windows/compat quirks explicitly — full worked recipe in examples/custom-gateways. Our validation battery drives exactly this posture against a localhost endpoint with real completions, tool calls and multi-thousand-token outputs (provider-threads-e2e.json, baseUrl http://127.0.0.1:4601/v1).

Two localhost-specific gotchas we hit ourselves: declare contextWindow/maxTokens to match what your local runtime is actually configured for (a catalog value bigger than the runtime's causes the "output token limit" family of surprises), and if the picker shows nothing, select the route as the default model (settings agent-default-model) — a configured route is not automatically the active one.

Can't comment on the exact error in your screenshot (text not legible to me) — if it persists after the shape above, a transparent recording proxy in front of Ollama will show exactly what reached it.