Preface

The philosophy of DSH is “everything is a plugin,” but the current version of the Models page does not expose an editing entry for third-party models. If you want to use Ollama Cloud models for chatting in the DeepSeek Harness Web interface, or switch search and fetch to Ollama’s web_search / web_fetch backends, you need a plugin to fill this layer. The dsh-llm-ollama introduced below does exactly that.

What is this

dsh-llm-ollama is the Ollama Cloud integration plugin for DeepSeek Harness, maintained by NOirBRight, under the MIT license. The description in package.json is: Ollama Cloud models, OpenAI-compatible chat, and Web Search/Fetch for DeepSeek Harness.

There is a clear trade-off in the design: chat goes through Ollama’s OpenAI-compatible Chat Completions endpoint, mediated by the shared pi-ai adapter; model discovery and Web Search/Fetch retain Ollama’s native APIs, as these independent capabilities do not belong to the chat protocol. The details of the protocol vs. capability separation are recorded in the repository’s ADR 0001.

Core Features

Listing by verified capabilities:

  1. Ollama Cloud Chat: POST <openai-base>/chat/completions, the /api inside baseURL automatically maps to /v1.

  2. Model Discovery (Ollama Native): GET /api/tags + POST /api/show.

  3. Web Search Provider: ollama-cloud (POST /api/web_search), can be paired with any selected chat model.

  4. Web Fetch Provider: ollama-cloud (POST /api/web_fetch), similarly can be paired with any selected chat model.

The latter two are ctx.web providers. DeepSeek, Codex, Kimi, or other OpenAI-compatible chat models can invoke Ollama’s web_search tool as long as the profile selects ollama-cloud.

In the Web configuration section, the plugin contributes an Ollama Cloud card (key: llm-ollama) and the Host’s llm route under Settings → LLM Providers. Settings and credentials are managed via an authenticated Connection RPC; literal credentials are not sent back to the browser.

When fetching available models, the Host reads /api/tags, deduplicates them, and uses /api/show to concurrently enrich up to six models. Native metadata provides context window and vision, thinking, and tools flags, which are not exposed by /v1/models.

Cloud Usage: reads GET <baseURL>/usage, renders consumption percentage for sessions and weekly windows, plus requests per model per week. If the self-hosted endpoint lacks a usage interface, it displays a “not supported” prompt instead of throwing an error.

The model directory is collapsed by default, one model per line: drag handle to sort (order persists with the directory), chevron to expand the context window, Default thinking, and capability flags for that row, trash button to delete.

Regarding reliability: model requests that meet criteria fail by default with a maximum of 8 retries; web requests have a default 15-second budget, retrying once on a transient timeout or transfer failure before following redirects.

Installation and Enabling

First, the version requirements: this version requires DeepSeek Harness 0.1.2-alpha.4 and @deepseek-ai/cordis@4.0.2, and is incompatible with Alpha.1–Alpha.3; users of older runtimes must retain the last plugin tag that adapted to that runtime (current version 0.6.16). The Node engine requires ^22.19.0 || >=24.0.0.

The installation method given in the README is to install directly from GitHub: first install dsh-llm-providers-ui 0.1.3, then install dsh-llm-ollama 0.6.16, and then start the Web:

dsh plugin --profile web add --force \
  https://github.com/NOirBRight/dsh-llm-providers-ui/releases/download/v0.1.3/dsh-llm-providers-ui-0.1.3.tgz
dsh plugin --profile web add --force \
  https://github.com/NOirBRight/dsh-llm-ollama/releases/download/v0.6.16/dsh-llm-ollama-0.6.16.tgz
dsh web

The repository tracks build artifacts that are directly publishable, so GitHub installation does not require a build-script whitelist.

Note that dsh-llm-providers-ui must be explicitly installed in the profile: the LLM Providers settings page and the shared llm-providers order store belong to it. When the owner is missing, the Web Providers page and this card will be omitted with a warning in the browser console, but the Host model route ollama-cloud remains available. When co-existing with an owner, the loading order does not matter.

Typical Usage

Pin Web Providers

Registering these two providers by the plugin does not change the deployment strategy; they need to be pinned in the profile patch:

- id: web
  config:
    searchProvider: ollama-cloud
    fetchProvider: ollama-cloud

Omitting fetchProvider allows migrating only the search while retaining the built-in HTTP fetcher.

Plugin Configuration

Examples given in the README Config section:

- id: llm-ollama
  name: 'dsh-llm-ollama'
  config:
    apiKeyEnv: OLLAMA_API_KEY
    baseURL: https://ollama.com/api
    defaultContextWindow: 262144
    streamIdleTimeoutMs: 300000
    webRequestTimeoutMs: 15000
    retryPolicy:
      mode: normal
      maxRetries: 8
      backoff:
        initialDelayMs: 500
        maxDelayMs: 10000
        jitterRatio: 0.1
    models:
      - id: gpt-oss:20b
        name: GPT-OSS 20B
        contextWindow: 131072
        thinking: true
      - id: llava
        name: LLaVA
        contextWindow: 4096
        vision: true

Fetch Models and View Usage

After the steps above, open Settings → LLM Providers → Ollama Cloud after starting dsh web. Clicking “Fetch Available Models” will immediately open the selector, using an unsaved endpoint and one-time key to invoke the authenticated Connection RPC; after applying, it replaces the draft directory and retains current-only models. The presentation of the Cloud Usage area mirrors ollama.com/settings.

Remote Browser Access

For remote browsers, first configure the Host allowlist, then use the authentication URL printed by DSH; or use an SSH loopback tunnel.

Authentication and Trust Boundaries

The plugin’s management, discovery, and usage channels are registered via the two-parameter rpc.handle(channel, handler) of the Alpha.4 Connection service, without selecting an authority on its own. Each process mints a random launch token; DSH only redeems this token at GET / into a signature browser session cookie bound to the authority. Cookies that are missing, expired, malformed, or have an incorrect authority return 401 before RPC distribution; static resources remain public. Before authentication, Connection requires the Host to be loopback or match a configured --trusted-host entry, and the attached Origin must equal the Host; Host/Origin validation failures return 403. The plugin does not bypass Host trust or browser session checks.

Use Cases and Notes

Suitable users: Users who want to use Ollama Cloud models for chatting in the DSH Web interface; users who want to switch search or fetch to Ollama’s native backends; users who need native metadata such as context window, vision/thinking/tools, etc.

A few notes:

  1. Protocol trade-offs: OpenAI Responses is not the default (Ollama only supports the non-stateful flavor); Anthropic Messages is not the default (requires an extra Bearer header, and has no model list or prompt cache).

  2. When account quotas are exhausted, the real Ollama API check maintains SKIP-QUOTA.

  3. This plugin runs with the permissions of the current dsh process; it is recommended to review the repository source code and license (MIT) before installation to confirm trustworthiness.

Summary

dsh-llm-ollama integrates Ollama Cloud chat, model metadata, usage viewing, and native web search/fetch into DeepSeek Harness, with clear documentation on version compatibility boundaries and authentication strategies. Repository address: https://github.com/NOirBRight/dsh-llm-ollama , Community directory page (independent site, no official affiliation with DeepSeek/FanHuan): https://www.skillhub.cn/plugins/NOirBRight/dsh-llm-ollama .