DeepSeek Harness local models: Ollama setup and 6 failures

Connecting Ollama to DeepSeek Harness is mostly about four fields in a custom provider. Connection failures, 404s, and model-not-found errors usually come from a wrong field or model name.

Two connection methods

Pick one and get it working before trying the other.

The custom provider is direct. Add it under Settings, Model, and fill the form; Ollama defaults to 127.0.0.1:11434 (source).

The compatible endpoint suits a gateway in front of Ollama. Without a gateway, there is no need for the extra layer.

Do not configure both at once. Two providers for the same model create selection ambiguity; get one working first.

Configure step by step

Make the model list readable before making the session work.

1. Start Ollama and confirm ollama list shows the target model.
2. Open Settings, Model, and add a custom provider.
3. Fill the Provider ID with a distinguishable name, such as ollama-local.
4. Fill the base URL: http://127.0.0.1:11434.
5. Choose the API protocol and model name; the name must match ollama list exactly.
6. Save, refresh the model list, and confirm the model is selectable.
7. Open a new session, select the model, and send a test message.

Match the model name character for character. Case and tag suffixes such as :latest cause "model not found."

Refresh before opening a session. The list is cached; without a refresh the UI may show old options.

Six failures

Six causes cover most local-model problems.

1. Cannot connect. Ollama is not running, the address is wrong, or the port is occupied; test with curl http://127.0.0.1:11434/api/tags.
2. 404. The base URL has an extra or missing path segment; Ollama's root does not need extra paths.
3. Model not found. Name mismatch or not pulled; compare with ollama list.
4. Protocol error. The wrong API protocol was selected; custom providers and compatible endpoints use different protocols.
5. Vision failure. The local model does not support images but the vision toggle is on; disable it or choose a vision model.
6. Timeout. The model is too large, GPUs are insufficient, or inference is slow; test a smaller model first.

Diagnose service, address, model, protocol, capability in that order. The first two are curl tests; do not change session settings first.

Vision and gateway compatibility flags live in settings.yaml. They are not in the UI form; restart or reload after changing them (source).

Verify: three signals

Successful configuration is more than "saved."

1. List signal: the target model appears in the model selector with the exact name.
2. Request signal: a test message gets a reply, and logs show the request going to the local address.
3. Capability signal: if you need images or tool calls, confirm the model supports them; otherwise disable the toggle.

All three must pass. Passing the first two may still fail on complex tasks where capability is missing.

Keep a test record. Model name, base URL, and result make troubleshooting faster.

Fall back to an official model

When the local model is unavailable, roll back completely.

1. Switch the model provider back to official.
2. Or disable the custom provider so sessions stop selecting it.
3. Open a new session to verify; old sessions may hold old references.
4. Keep the local configuration instead of deleting it; disable and re-enable later.
5. Check the default model so new sessions do not fall back to the local provider.

Changing only the model name is not a fallback. The provider remains and the default model still points at it.

Confirm request routing. Logs should show requests going to the official address, not the local port.

Cost and hardware boundaries

Local models trade data locality for hardware and speed.

1. VRAM limits model size. Larger models need more VRAM; insufficient VRAM falls back to CPU and slows down sharply.
2. Longer context uses more VRAM. Long sessions are more likely to exhaust local memory; shorten context or use a smaller model.
3. Concurrency is limited. A single machine suits one user; multiple users need queueing and timeout planning.
4. Capability differs. Tool calling and structured output may differ from official models, affecting plugin behavior.

Boundaries prevent mistaking "it runs" for "it can replace." Local models fit privacy, offline, and cost-controlled scenarios; complex tasks may still need an official model.

Next steps

Get one method working, then diagnose six failures. For the official provider form, read How to run Ollama with DSH. For general model configuration, read How to configure models. For image capability, read Model image capability.

Sources: DeepSeek Harness docs, dsh CLI README, Ollama docs