Use Ollama with DeepSeek Harness: OpenAI-compatible provider

DeepSeek Harness ships no model of its own, so reaching local Ollama means treating it as an OpenAI-compatible endpoint and adding a custom provider under Settings → Models; after the form there are two switches to write into settings.yaml (image input and gateway compatibility). This walks the order "run Ollama → fill the form field by field → add the two switches", with fields and commands aligned to the official docs.

Why DeepSeek Harness can talk to Ollama: a custom provider is an OpenAI-compatible endpoint

Ollama serves an OpenAI-compatible endpoint, and DeepSeek Harness attaches any such endpoint through a custom provider, so no Ollama-specific adapter is involved (source). Prepare the local side first:

1. Install Ollama and start it — install per the Ollama docs, then start the service. Expected: the ollama command works and the service listens locally; it is a foreground process, so closing the terminal that started it stops the service.
2. Pull a model — run ollama pull <model>. Expected: ollama list shows the model name, which you will copy into DSH character for character.
3. Confirm the endpoint — Ollama exposes its OpenAI-compatible endpoint at http://127.0.0.1:11434/v1. Expected: the address responds and nothing else holds the port; if the model or endpoint will not come up, triage it with model connection errors.

Ollama is not the only local option: llama.cpp's llama-server defaults to http://127.0.0.1:8080/v1 and LM-Kit follows your own launch configuration — compare the three in hooking DSH up to a local model. If you changed a name or port, change it on the DSH side too; mismatched ends never connect.

Adding a custom provider in DeepSeek Harness: the five form fields

A custom provider needs five things — a lowercase Provider ID, a display name, a base URL, an API protocol and a credential, plus at least one model — and Provider ID is permanent because every downstream request and credential reference uses it (source). Follow the official form:

1. Open the form — go to Settings → Models and choose Add custom provider (providers already in the catalog use "Add provider" instead).
2. Fill Provider ID and display name — keep the ID lowercase, for example ollama-local; it appears in requests, saved sessions, model defaults and credential references. Expected: the ID is fixed once saved, while the display name stays editable.
3. Fill the base URL and API protocol — set the base URL to http://127.0.0.1:11434/v1 and pick openai-completions. Expected: these two decide where the request goes and what shape it takes; local services usually need no key, but if yours enforces auth, add the credential — an empty one reports MISSING_CREDENTIAL.
4. Add at least one model — type a model ID (a wrong one reports UNKNOWN_MODEL), or click Fetch available models to query the endpoint. Expected: the list only updates the draft and stores nothing before you save; the chosen model shows up in the model selector and becomes the default for new sessions.
5. Save and verify — save, then send one message. Expected: model changes take effect on the next request with no server restart; sessions that already sent requests keep the model recorded in their own log.

DeepSeek Harness image switch and gateway compat in settings.yaml

A hand-entered model is text only until it declares otherwise, so images need input: [text, image] on that model in $DSH_HOME/settings.yaml; when a gateway rejects requests, the two compat switches bend the request shape back to what it accepts (source). Both live in the yaml:

1. Declare image input on the model — add input under the provider's models:
   yaml

   llm-pi-ai:
     providers:
       ollama-local:
         api: openai-completions
         baseURL: http://127.0.0.1:11434/v1
         models:
           - id: vision-model
             input: [text, image]
   

   Expected: that model accepts images; if every hand-entered model does, write defaultInput: [text, image] once on the route as the fallback. The full troubleshooting path is in a model that does not support image.
2. Narrow a catalog model with modelOverrides — catalog providers have no models list to fill, so overrides are keyed by model ID:
   yaml

   llm-pi-ai:
     providers:
       anthropic:
         modelOverrides:
           claude-sonnet-4-5:
             input: [text]
   

   Expected: only that model's modality is narrowed; other models on the same route keep theirs.
3. Correct gateway compatibility with compat — a declared reasoning capability sends the system prompt as role: "developer" and writes the output limit as max_completion_tokens, and many gateways reject both:
   yaml

   llm-pi-ai:
     providers:
       ollama-local:
         api: openai-completions
         baseURL: http://127.0.0.1:11434/v1
         compat:
           supportsDeveloperRole: false
           maxTokensField: max_tokens
         models:
           - id: my-model
   

   Expected: the request shape matches what the gateway accepts; a route-level compat is the default for its models, a model's own value wins field by field, and a key left empty after the colon is rejected rather than ignored.
4. Check the composed result when unsure — run dsh --dump-config to inspect the composed config tree (source). Expected: the model and switches you just wrote appear in the final configuration instead of only in a draft.

DeepSeek Harness with Ollama: caveats

1. DSH does not start Ollama for you: the local service is a foreground process, so closing its terminal closes the service and later requests must fail.
2. input and compat are assertions, not checks: a declared image capability the endpoint does not offer is not blocked here — the provider rejects the request, and a switch your gateway does not need merely sends a different request.
3. Provider ID is written once: it enters requests, sessions, model defaults and credential references, so renaming means adding a provider and deleting the old one.
4. Modality precedence matters: hand-entered models are text by default, catalog models follow the catalog record, and defaultInput only answers for models the catalog does not describe.
5. Watch VRAM first on local models: a model larger than available VRAM either crashes the service or makes it unusably slow — step down a size before tuning the DSH side.

Rather than hand-editing yaml to manage plugin switches, use the Settings page of DSH Plugin Hub (dsh-plugin.org): update settings, security and trust, system diagnostics and the log path all live in the UI.

Sources: DeepSeek Harness official docs - Model configuration, dsh CLI README, Ollama official website, dshplugin/dsh-plugin-hub