DeepSeek Harness

Settings → Models → “Add model provider” → “Custom model API” takes five fields — Provider ID, display name, base URL, API protocol and API key — and puts Claude and GPT in the same picker as the built-in DeepSeek card.

# Settings → Models → Add model provider → Custom model API
#
#   Provider ID     kunavo          (lowercase, and permanent)
#   display name    Kunavo
#   base URL        https://api.kunavo.com/v1
#   API protocol    OpenAI Chat Completions   (openai-completions)
#   API key         sk-kn-...
#
# Then Model catalog → Fetch available models → Add selected,
# or type the ids by hand. The page writes the active profile's
# $DSH_HOME/profiles/<profile>/cordis.patch.yml — profile "web" under
# `dsh web`. The same provider there, plus an optional second one
# that sends Claude ids over Anthropic Messages, whose base URL has
# NO /v1. This entry replaces the whole llm-pi-ai config: keep any
# provider already in it.

- id: llm-pi-ai
  config:
    providers:
      kunavo:
        apiKeyEnv: KUNAVO_API_KEY
        api: openai-completions
        baseURL: https://api.kunavo.com/v1   # → /v1/chat/completions
        models:
          - id: claude-sonnet-5
          - id: claude-opus-5
          - id: claude-haiku-4-5
          - id: gpt-5-6-sol
      kunavo-claude:
        apiKeyEnv: KUNAVO_API_KEY
        api: anthropic-messages
        baseURL: https://api.kunavo.com      # → /v1/messages
        models:
          - id: claude-sonnet-5
          - id: claude-haiku-4-5

Step by step

1. Create a key at /app/keys and copy it — it is shown once.
2. Start the Web UI (dsh web) and go to Settings → Models. Choose Add model provider. The card opens on Third-party model provider, which only lists the providers dsh ships with — switch it to Custom model API.
3. Fill in Provider ID (lowercase, and permanent — the docs say requests, saved sessions, model defaults and credential references all use it, and renaming means adding a new provider and deleting the old one), display name, base URL https://api.kunavo.com/v1, API protocol OpenAI Chat Completions and API key. The key is write-only; dsh keeps it in $DSH_HOME/.credentials.yaml and stores only a reference to it in the profile.
4. Under Model catalog, choose Fetch available models — Kunavo answers GET /v1/models, so the picker fills itself. Tick what you want and choose Add selected. Ids typed by hand work just the same, and the docs say to fall back to that whenever discovery lists nothing.
5. Optional: for Claude ids over Anthropic's own protocol, add a second custom model API with its own Provider ID, base URL https://api.kunavo.com — no /v1 — API protocol Anthropic Messages and the same key. Fetch lists the whole catalog here too; add only the claude- ids (why only those).
6. Pick a model in the composer and send a turn that touches a file, not a greeting — the harness leans on tool calling for most of what it does, so a first run that reads and edits something tells you more. Model changes take effect on the next request; the docs are explicit that nothing needs a restart.

Checked against the DeepSeek Harness “Configure models” page (the same text as docs/user/guide/providers.md at tag dsh-v0.2.0-rc.2) on October 1, 2026. Third-party settings move; if a field name here no longer matches what you see, that page is the authority, not this one.

Verify before you debug the client

One request settles whether a failure is the endpoint, the key, or the configuration file. If this returns JSON, the same base URL and key work in DeepSeek Harness.

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

Which model id to put in the field

Every text model is reachable as a model id — the live list is GET /v1/models, and the catalog with prices is on the models page. Rates are USD per 1M tokens, input / output.

Claude over Anthropic Messages

Kunavo answers the Anthropic Messages API as well, and anthropic-messages is one of the three protocols the form offers. The harness's docs are plain that “A provider speaks one protocol, so a gateway that serves two needs two providers” — so this is a second provider beside the first, not a setting on it.

• Base URL https://api.kunavo.com, the bare root. In the run, that root posted to /v1/messages?beta=true — the path Claude Code uses too, and one Kunavo answers. With /v1 on the end it posted to /v1/v1/messages. DeepSeek Harness vs Claude Code puts the two clients' requests side by side.
• Claude ids only. Kunavo's /v1/messages serves claude- ids and nothing else; a gpt- id there gets a 404 that names /v1/chat/completions. Keep GPT on the openai-completions provider.
• Fetch lists every model; add only the Claude ones. dsh's llm-pi-ai README says discovery on this protocol asks GET /v1/models with Anthropic's x-api-key header, and Kunavo's model list takes the key in that header as it does in Authorization: Bearer — that comes from dsh's source and Kunavo's own tests, not from the run. What Fetch available models gets back is the whole catalog, GPT and image models included, so tick only the claude- ids; typing them by hand works the same. A full list proves less than it looks: the same README says the listing URL is accepted with or without /v1, while model requests take the base URL unchanged — so Fetch fills the list from https://api.kunavo.com/v1 as well, and the first turn from that base URL goes to /v1/v1/messages.
• What it buys you. The request arrives in Anthropic's shape — in the run, the system prompt travelled as the top-level system field, so the developer role never comes up — and Kunavo hands it on as it is rather than translating it from OpenAI's. The openai-completions provider reaches the same Claude ids through translation, which is why it is the one in the steps.

The file behind the form

The Models page writes $DSH_HOME/profiles/<profile>/cordis.patch.yml — $DSH_HOME/profiles/web/cordis.patch.yml when you start with dsh web. Older dsh docs pointed at $DSH_HOME/settings.yaml; 0.2.0-rc.2's do not. When the browser is on the same machine as the server, Open configuration file in the Settings header opens it, and the adapters re-read it on the next request. Five things matter for this endpoint:

1. Context window and max output tokens — in the form, under Customized settings → Model options. An id typed in by hand carries neither, so the route's fallbacks apply: 262,144 tokens of context and 32,768 of output, per the llm-pi-ai README — and in the run both custom providers asked for exactly max_tokens: 32768. Every id in the table above takes more; check the row either way, and raise them from the model's catalog entry if you want more. Kunavo bills the tokens the model writes, not the cap.
2. compat.supportsDeveloperRole — not needed. The harness recommends it for gateways that reject the developer role; Kunavo reads that role as the system turn on every family, Claude included. (Until 2026-09-30 the Claude path dropped it, and this item told you to set the switch — leaving it set is harmless.)
3. compat.maxTokensField — leave it alone. The harness pairs it with the switch above as the usual first fix, but Kunavo's own handler reads max_completion_tokens and falls back to max_tokens, so the default already works.
4. reasoningEfforts — no field in the form. A model you enter by hand declares no levels, so the Effort menu does not appear and the endpoint's own default decides whether the model thinks. Declare the levels yourself if you want the menu; on openai-completions each key is a level and its value is the spelling sent as reasoning_effort. That reaches a gpt- id; on a claude- id it has no effect, because Kunavo's chat surface does not forward reasoning_effort to Anthropic (/docs/chat#reasoning).
5. Input types (input: [text, image] in the file) — the docs are clear that this “states a claim about your endpoint rather than checking it”. Ticking Image on an id that does not take images is not caught in the harness; the request is refused further along. Check the id on /models before you tick the box.

The rest of what a session sends — 24 tool definitions per turn, a short title request for every new session, and the extra fields on DeepSeek's own route — is measured on DeepSeek Harness pricing.