DeepSeek Harness

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

# Settings → Models → Add a custom provider
#
#   Provider ID     kunavo          (lowercase, and permanent)
#   display name    Kunavo
#   base URL        https://api.kunavo.com/v1
#   API protocol    openai-completions
#   API key         sk-kn-...
#
# Then Model catalog → Fetch available models → Add selected,
# or type the ids by hand. The Models page writes $DSH_HOME/settings.yaml;
# the same provider in that file looks like this:

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

Step by step

1. Create a key at /app/keys and copy it — it is shown once.
2. Open the Web UI and go to Settings → Models. Below the DeepSeek card, choose Add a custom provider — not Add provider, which only picks from the catalog dsh ships with.
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, API protocol = openai-completions and API key.
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. 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 on September 21, 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.

The fields the form does not have

The Models page and $DSH_HOME/settings.yaml are the same document — the docs say the adapters re-read it on the next request, and that when the browser is on the same machine as the server you can open it with Open configuration file in the Settings header. Four things matter for this endpoint, and only one of them has a field in the form:

1. compat.supportsDeveloperRole: false — set it on the route or on the model for any claude- id that declares reasoning levels. The harness recommends this switch for gateways that reject the developer role; Kunavo does not reject it on the Claude path, it drops the message, which is worse to debug because nothing fails. The symptom is a model that behaves as if it never read your instructions.
2. 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.
3. reasoningEfforts — 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; each key is a level and its value is the spelling sent as reasoning_effort.
4. input: [text, image] — the docs are clear that this “states a claim about your endpoint rather than checking it”. Declaring images on an id that does not take them is not caught in the harness; the request is refused further along. Check the id on /models before you tick the box.

One structural point from the same page, worth knowing before you plan around it: “A provider speaks one protocol, so a gateway that serves two needs two providers.” Kunavo answers an Anthropic Messages surface as well, and anthropic-messages is one of the three values the API protocol field offers — but the harness's docs show a base URL example only for the OpenAI-compatible protocols, so this page does not put a value in that field for a form it has not seen settled. The openai-completions route above is the unambiguous one.