@lihuu/dsh-ollama-cloud

A DeepSeek Harness plugin that adds the Ollama cloud chat-completions provider, so the agent can use Ollama cloud models (DeepSeek, GLM, and more).

What it does

• Registers the ollama-cloud-direct provider route on the LLM seam
• Declares the route in the configurable-provider directory as a dormant entry: until configured, it is offered by the Models page's 添加提供方 select (like a pi-ai route), and configuring it turns it into a removable ollama-cloud row
• Installs the llm-ollama-cloud user-settings section, so base URL, model catalog, and defaults are editable on the page and take effect without a restart
• Answers the Models page's fetch available models action from the resolved catalog, or interrogates a drafted endpoint at GET {baseURL}/models
• Ships with a default model catalog: DeepSeek-V4-Flash (cloud), DeepSeek-V4-Pro (cloud), GLM-5.2 (cloud)
• Reads the API key through the harness credential seam, per request — a changed key takes effect without a restart
• Model ids without a :cloud suffix are sent as id:cloud (e.g. deepseek-v4-flash → deepseek-v4-flash:cloud)

Requirements

• DeepSeek Harness 0.1.2+
• An Ollama cloud API key

Install

The package is a bundle: it ships its own configuration layer, so installing it into a profile activates the plugin automatically.

dsh plugin --profile web add @lihuu/dsh-ollama-cloud

dsh plugin add appends the bundle to the profile's layer stack (dsh.profile.bundles), and the bundle's patch file mounts the plugin row. No manual patch editing is needed.

If you previously mounted this plugin by hand (an llm-ollama-cloud row in ~/.dsh/cordis.patch.yml), remove that row before installing the bundle — the duplicate row id fails the boot.

Restart the web service once after installing (bundle layers are composed at boot).

Upgrading from 0.1.x

0.2.0 moves the configuration from section-level fields to a per-route profile (providers.ollama-cloud-direct), which is what makes the route appear in the Models page's 添加提供方 select. If you pinned config in ~/.dsh/cordis.patch.yml, move it under the profile:

# 0.1.x                          # 0.2.0
- id: llm-ollama-cloud            - id: llm-ollama-cloud
  config:                           config:
    apiKeyEnv: ...                    providers:
    baseURL: ...                        ollama-cloud-direct:
    models: ...                           apiKeyEnv: ...
                                          baseURL: ...
                                          models: ...

Easiest path: drop the config: block entirely (keep the bare row) and configure on the Models page after restarting.

Configuration

1. Set the API key

After a restart, open Settings → Models, click 添加提供方, and pick ollama-cloud from the select:

• Type the key and 保存 — it is stored write-only under the OLLAMA_CLOUD_DIRECT_API_KEY credential reference, and the profile is created. The row appears with a green key dot.
• Or save without typing a key — the profile resolves the conventional OLLAMA_CLOUD_API_KEY reference instead, so a key already set in the environment or the credentials file keeps working.

The key can also be set outside the page:

Credentials file. Add one line to ~/.dsh/.credentials.yaml:

version: 1
refs:
  OLLAMA_CLOUD_API_KEY: ollama-xxxxxxxxxxxxxxxx

Environment variable. Set OLLAMA_CLOUD_API_KEY in the environment the harness process runs under (your shell profile, a launchd unit, a process manager, etc.):

export OLLAMA_CLOUD_API_KEY="ollama-xxxxxxxxxxxxxxxx"

While the route is dormant (no profile stored), the adapter already serves the default catalog through that reference — page-stored credentials win over the environment once a profile names one; both are read per request, so changing either never needs a restart.

2. Select the provider

Choose the ollama-cloud-direct provider for the model (for example in the model settings or the agent's provider configuration).

Settings section

The section shape is one profile per route:

llm-ollama-cloud:
  providers:
    ollama-cloud-direct:
      apiKeyEnv: OLLAMA_CLOUD_API_KEY
      baseURL: https://ollama.com/v1
      models:
        - id: deepseek-v4-flash
          contextWindow: 800000

The plugin's cordis.yml mount entry is the section's base layer: pinning the profile there presents the route as an already-configured row; leaving it out keeps it dormant in the add-provider select. Everything the profile allows (apiKeyEnv, baseURL, thinking, reasoningEffort, maxTokens, defaultContextWindow, models, streamIdleTimeoutMs, retryPolicy) is editable on the page or in settings.yaml — the user layer wins, and a change takes effect on the next request without a restart. Fields the curated editor does not show (retry policy, timeouts, thinking defaults) stay owned by the mount config and settings.yaml.

Custom model catalog

The plugin resolves a default catalog when the profile names no models array. To pin one for the deployment, add it to the profile in ~/.dsh/cordis.patch.yml:

- id: llm-ollama-cloud
  config:
    providers:
      ollama-cloud-direct:
        models:
          - id: deepseek-v4-flash
            name: DeepSeek-V4-Flash
            contextWindow: 800000

(Note: pinning the profile this way also presents the route as configured.) The Models page can override the catalog per deployment (自定义设置 → models); reset there hands the catalog back to the layer beneath.

License

MIT