Dokumentation

Dokumentation

DeepSeek Harness

DeepSeek Harness behält seine eigene DeepSeek-Karte und fügt deine daneben hinzu. Fünf Felder unter „Add model provider“ → „Custom model API“ bringen Claude und GPT auf demselben Schlüssel in dieselbe Modellauswahl.

Settings → Models → „Add model provider“ → „Custom model API“ erwartet fünf Felder — Provider ID, Anzeigename, Basis-URL, API-Protokoll und API-Schlüssel — und bringt Claude und GPT in dieselbe Auswahl wie die integrierte DeepSeek-Karte.

Settings → Models → Add model provider → Custom model API
# 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
Die Basis-URL hängt vom API-Protokoll ab. openai-completions verwendet https://api.kunavo.com/v1; anthropic-messages verwendet https://api.kunavo.com, ohne /v1, weil dsh /v1/messages selbst anhängt. Ein Lauf mit dsh 0.2.0-rc.2 gegen einen aufzeichnenden Ersatzdienst klärte beides: Der erste sendete eine Anfrage an /v1/chat/completions, der zweite vom nackten Ursprung an /v1/messages?beta=true — und an /v1/v1/messages, wenn seine Basis-URL /v1 enthielt. Ein echtes Gateway antwortet darauf mit einem 404, nicht mit einem Authentifizierungsfehler.
reasoningEfforts ändert die Rolle des System-Prompts, nicht ob er ankommt. Laut Harness-Dokumentation wird der System-Prompt bei Modellen, die Reasoning deklarieren, als role: "developer" gesendet. Kunavo interpretiert diese Rolle bei jeder Modellfamilie, Claude eingeschlossen, als System-Turn. Daher ist dafür kein Schalter compat erforderlich. Bis zum 2026-09-30 ließ der Claude-Pfad die Rolle weg, und diese Karte empfahl, compat.supportsDeveloperRole: false zu setzen. Falls du das getan hast, ist es harmlos und kann so bleiben.
Kunavo bietet kein DeepSeek-Modell an. Dieser Anbieter wird neben der DeepSeek-Karte eingerichtet und ersetzt sie nicht — behalte deinen DeepSeek-Schlüssel für deepseek--IDs dort und verwende diesen Anbieter für die Claude- und GPT-IDs in der Tabelle unten. Das bedeutet auch, dass der Schalter compat.thinkingFormat: deepseek, den das Harness für „DeepSeek V4 hinter einem OpenAI-kompatiblen Gateway“ dokumentiert, hier nichts bewirkt.
Dein Sitzungsprotokoll wird nicht mitgesendet. Auf seiner integrierten DeepSeek-Route fügt dsh jeder Anfrage zwei Felder hinzu, die das Modell nie zu sehen bekommt: dsh_session_log, die Ereignisse der Sitzung einschließlich des Pfads zu deinem Arbeitsverzeichnis, und dsh_plugin_packages. Beim Testlauf sendete keiner der beiden benutzerdefinierten Anbieter eines davon. Ein Kunavo-Anbieter erhält sie also nicht. Angaben zu ihrem Umfang und zum Schalter, mit dem sich der Upload deaktivieren lässt, findest du unter Preise von DeepSeek Harness.
Niemand bei Kunavo hat DeepSeek Harness gegen den Kunavo-Endpunkt ausgeführt. Was am unten angegebenen Datum getestet wurde: dsh 0.2.0-rc.2 aus npm, ohne Benutzeroberfläche, drei neue Sitzungen pro Route gegen einen lokalen Ersatzdienst, der jede Anfrage aufzeichnet und mit einem Tool-Aufruf antwortet — nicht Kunavo und kein Modell. Alle neun Sitzungen schlossen einen gestreamten Tool-Roundtrip ab und sendeten jedes Mal dieselben Bytes. Damit sind die Pfade und Obergrenzen auf dieser Seite geklärt. Über Kunavos Authentifizierung, Routing oder die Antworten eines Modells sagt das nichts aus. Das curl unten ist die Kunavo-Seite, die du in zehn Sekunden prüfen kannst; dsh ist eine Entwicklervorschau und wird weiterhin geändert.
Kunavo bietet weder Einbettungs- noch Text-zu-Sprache- oder Sprache-zu-Text-Modelle an. Dieser Anbieter verarbeitet daher ausschließlich Chat-Vervollständigungen. Ein Harness-Plugin, das Audio transkribiert oder einen Vektorindex erstellt, behält den bereits verwendeten Anbieterschlüssel bei — durch das Hinzufügen dieses Anbieters werden diese Aufrufe nicht umgeleitet.
Noch kein Schlüssel? Erstelle ein Kunavo-Konto, erstelle einen Schlüssel (er beginnt mit sk-kn-) und füge ab $10 Guthaben hinzu – Aufrufe werden aus diesem Guthaben bezahlt, fehlgeschlagene Aufrufe werden nicht berechnet. Das Dashboard öffnet anschließend die DeepSeek Harness-Einrichtung.

Schritt für Schritt

  1. Erstellen Sie unter /app/keys einen Schlüssel und kopieren Sie ihn — er wird nur einmal angezeigt.
  2. Starte die Web-UI (dsh web) und gehe zu Einstellungen → Modelle. Wähle Modellanbieter hinzufügen. Die Karte öffnet sich mit Drittanbieter-Modellanbieter, wo nur die von dsh mitgelieferten Anbieter aufgeführt sind — stelle auf Benutzerdefinierte Modell-API um.
  3. Trage Anbieter-ID (Kleinschreibung und dauerhaft — laut Dokumentation verwenden Anfragen, gespeicherte Sitzungen, Modellstandards und Anmeldedatenverweise diese ID. Zum Umbenennen musst du einen neuen Anbieter hinzufügen und den alten löschen), Anzeigename, Basis-URL https://api.kunavo.com/v1, API-Protokoll OpenAI Chat Completions und API-Schlüssel ein. Der Schlüssel ist schreibgeschützt; dsh speichert ihn in $DSH_HOME/.credentials.yaml und hinterlegt im Profil nur einen Verweis darauf.
  4. Wähle unter Modellkatalog die Option Verfügbare Modelle abrufen — Kunavo antwortet mit GET /v1/models, sodass die Modellauswahl automatisch gefüllt wird. Markiere die gewünschten Modelle und wähle Ausgewählte hinzufügen. Manuell eingegebene IDs funktionieren genauso. Laut Dokumentation solltest du darauf zurückgreifen, wenn die Suche keine Modelle auflistet.
  5. Optional: Für Claude-IDs über Anthropic-eigenes Protokoll fügst du eine zweite benutzerdefinierte Modell-API mit eigener Anbieter-ID, Basis-URL https://api.kunavo.com — ohne /v1 —, API-Protokoll Anthropic Messages und demselben Schlüssel hinzu. Auch hier ruft Fetch den gesamten Katalog ab; füge nur die claude--IDs hinzu (warum nur diese).
  6. Wähle im Composer ein Modell aus und sende einen Turn, der eine Datei bearbeitet, statt nur zu grüßen — das Harness setzt bei den meisten Aufgaben auf Tool-Aufrufe. Ein erster Lauf, der etwas liest und bearbeitet, sagt dir daher mehr. Modelländerungen gelten ab der nächsten Anfrage; laut Dokumentation ist ein Neustart nicht erforderlich.

Abgeglichen mit die Seite „Modelle konfigurieren“ von DeepSeek Harness (derselbe Text wie in docs/user/guide/providers.md beim Tag dsh-v0.2.0-rc.2) am 1. Oktober 2026. Einstellungen von Drittanbietern können sich ändern; wenn ein Feldname hier nicht mehr mit deiner Ansicht übereinstimmt, ist diese Seite maßgeblich, nicht diese hier.

Vor dem Debugging des Clients prüfen

Eine Anfrage klärt, ob der Fehler am Endpunkt, am Schlüssel oder an der Konfigurationsdatei liegt. Wenn diese Anfrage JSON zurückgibt, funktionieren dieselbe Basis-URL und derselbe Schlüssel 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-..."

Welche Modell-ID in das Feld gehört

Jedes Textmodell ist über eine Modell-ID erreichbar – die aktuelle Liste findest du unter GET /v1/models, den Katalog mit Preisen auf der Modellseite. Die Tarife sind USD pro 1 Mio. Token, Eingabe / Ausgabe.

Modell-IDKunavo: Ein- und AusgabeWo es in DeepSeek Harness hineinpasst
claude-sonnet-5$1.40 / $7.00das Standardmodell für Sitzungen, in denen Dateien bearbeitet werden
claude-opus-5$3.50 / $17.50Planung einer Änderung, bei der ein Fehler teuer wäre
claude-haiku-4-5$0.70 / $3.50günstige Durchläufe — Triage, Zusammenfassungen und die Schleife, die den ganzen Tag läuft
gpt-5-6-sol$2.00 / $12.00eine zweite Meinung aus einer anderen Modellfamilie, mit demselben Schlüssel und Anbieter
gpt-5-6-terra$0.70 / $4.20lange Eingaben, bei denen der Preis pro Token die Rechnung bestimmt
Die Abrechnung erfolgt pro Token aus einem vorausbezahlten Guthaben ohne Monatsgebühr – siehe Abrechnung. Bei wiederholtem Kontext – dem Großteil dessen, was ein Editor oder Chat-Client sendet – verändert Prompt-Caching die Rechnung stärker als die Modellwahl.

Claude über Anthropic Messages

Kunavo unterstützt auch die Anthropic Messages API, und anthropic-messages ist eines der drei Protokolle, die das Formular anbietet. Die Dokumentation des Harness sagt ausdrücklich: „Ein Anbieter spricht ein Protokoll. Ein Gateway, das zwei Protokolle unterstützt, benötigt also zwei Anbieter.“ Dies ist daher ein zweiter Anbieter neben dem ersten, keine Einstellung am ersten.

  • Basis-URL https://api.kunavo.com, der nackte Ursprung. Im Testlauf sendete dieser Ursprung eine Anfrage an /v1/messages?beta=true — denselben Pfad, den auch Claude Code verwendet und den Kunavo unterstützt. Mit /v1 am Ende ging die Anfrage an /v1/v1/messages. Unter DeepSeek Harness und Claude Code im Vergleich sind die Anfragen beider Clients gegenübergestellt.
  • Nur Claude-IDs. Kunavos /v1/messages unterstützt ausschließlich claude--IDs; eine gpt--ID führt dort zu einem 404, das /v1/chat/completions nennt. GPT bleibt beim Anbieter openai-completions.
  • Fetch listet jedes Modell auf; füge nur Claude-Modelle hinzu. Das README von dshs llm-pi-ai besagt, dass die Modellerkennung bei diesem Protokoll GET /v1/models mit Anthropic-Header x-api-key anfragt. Kunavos Modellliste akzeptiert den Schlüssel in diesem Header ebenso wie bei Authorization: Bearer — das geht aus dem Quellcode von dsh und Kunavos eigenen Tests hervor, nicht aus dem Testlauf. Verfügbare Modelle abrufen liefert den gesamten Katalog zurück, einschließlich GPT- und Bildmodellen. Markiere daher nur die claude--IDs; manuelle Eingabe funktioniert genauso. Eine vollständige Liste sagt weniger aus, als es scheint: Laut demselben README wird die Auflistungs-URL mit oder ohne /v1 akzeptiert, während Modellanfragen die Basis-URL unverändert übernehmen. Fetch füllt die Liste also auch von https://api.kunavo.com/v1 aus, und der erste Turn mit dieser Basis-URL geht an /v1/v1/messages.
  • Was es dir bringt. Die Anfrage kommt im Anthropic-Format an — im Testlauf wurde der System-Prompt als Feld der obersten Ebene system übermittelt, sodass die Rolle developer keine Rolle spielt — und Kunavo leitet sie unverändert weiter, statt sie aus dem OpenAI-Format zu übersetzen. Über den Anbieter openai-completions erreichst du dieselben Claude-IDs durch Übersetzung. Deshalb wird er in der Anleitung verwendet.

Die Datei hinter dem Formular

Auf der Seite „Modelle“ wird $DSH_HOME/profiles/<profile>/cordis.patch.yml geschrieben — $DSH_HOME/profiles/web/cordis.patch.yml, wenn du mit dsh web startest. In älteren dsh-Dokumenten wurde auf $DSH_HOME/settings.yaml verwiesen; in der Dokumentation für 0.2.0-rc.2 nicht mehr. Wenn sich Browser und Server auf demselben Rechner befinden, öffnet Konfigurationsdatei öffnen in der Kopfzeile der Einstellungen die Datei, und die Adapter lesen sie bei der nächsten Anfrage erneut ein. Für diesen Endpunkt sind fünf Dinge wichtig:

  1. Kontextfenster und maximale Ausgabetoken — im Formular unter Benutzerdefinierte Einstellungen → Modelloptionen. Eine manuell eingegebene ID enthält weder das eine noch das andere, daher gelten die Standardwerte der Route: 262,144 Token Kontext und 32,768 Token Ausgabe laut README von llm-pi-ai — und im Testlauf forderten beide benutzerdefinierten Anbieter genau max_tokens: 32768 an. Für jede ID in der Tabelle oben gelten höhere Werte. Prüfe dennoch den jeweiligen Eintrag und erhöhe die Werte anhand des Katalogeintrags des Modells, wenn du mehr möchtest. Kunavo berechnet die vom Modell geschriebenen Token, nicht die Obergrenze.
  2. compat.supportsDeveloperRole — nicht erforderlich. Das Harness empfiehlt diese Option für Gateways, die die Rolle developer ablehnen. Kunavo interpretiert diese Rolle bei jeder Modellfamilie, Claude eingeschlossen, als System-Turn. (Bis zum 2026-09-30 ließ der Claude-Pfad sie weg, und dieser Eintrag empfahl, den Schalter zu setzen — ihn eingeschaltet zu lassen ist harmlos.)
  3. compat.maxTokensField — unverändert lassen. Das Harness nennt diese Option zusammen mit dem obigen Schalter als übliche erste Lösung. Kunavos eigener Handler liest jedoch max_completion_tokens und greift ersatzweise auf max_tokens zurück, sodass die Standardeinstellung bereits funktioniert.
  4. reasoningEfforts — kein Formularfeld. Ein manuell eingegebenes Modell deklariert keine Stufen, daher erscheint das Menü Aufwand nicht. Ob das Modell nachdenkt, entscheidet der Standardwert des Endpunkts. Deklariere die Stufen selbst, wenn du das Menü möchtest; bei openai-completions ist jeder Schlüssel eine Stufe und der jeweilige Wert die Schreibweise, die als reasoning_effort gesendet wird. Das funktioniert bei einer gpt--ID; bei einer claude--ID hat es keine Wirkung, denn Kunavos Chat-Schnittstelle leitet reasoning_effort nicht an Anthropic weiter (/docs/chat#reasoning).
  5. Eingabetypen (input: [text, image] in der Datei) — laut Dokumentation „formuliert dies eine Behauptung über deinen Endpunkt, statt ihn zu prüfen“. Wenn du bei einer ID, die keine Bilder verarbeitet, die Bildoption aktivierst, erkennt das Harness den Fehler nicht; die Anfrage wird erst später abgelehnt. Prüfe die ID unter /models, bevor du das Kästchen markierst.

Der Rest dessen, was eine Sitzung sendet — 24 Tool-Definitionen pro Turn, eine kurze Titelanfrage für jede neue Sitzung und die zusätzlichen Felder auf DeepSeeks eigener Route — wird unter Preise von DeepSeek Harness erfasst.

Häufig gestellte Fragen

Wie füge ich DeepSeek Harness einen benutzerdefinierten API-Anbieter hinzu?

Starte die Web-UI mit dsh web, gehe zu Settings → Models und wähle „Add model provider“. Die Karte öffnet sich mit „Third-party model provider“, wo nur die mit dsh ausgelieferten Anbieter aufgeführt sind. Stelle auf „Custom model API“ um. Das Formular verlangt eine kleingeschriebene Anbieter-ID, einen Anzeigenamen, eine Basis-URL, ein API-Protokoll und einen API-Schlüssel sowie mindestens ein Modell unter Model catalog. Die Anbieter-ID ist dauerhaft, denn Anfragen, gespeicherte Sitzungen, Modellstandards und Anmeldedatenverweise verwenden sie. Zum Umbenennen musst du einen neuen Anbieter hinzufügen und den alten löschen. In 0.2.0-rc.2 speichert die Seite die Konfiguration in der cordis.patch.yml des aktiven Profils — unter dsh web also in $DSH_HOME/profiles/web/cordis.patch.yml.

Muss die DeepSeek-Harness-Basis-URL auf /v1 enden?

Das hängt vom API-Protokoll ab. Für openai-completions ja: https://api.kunavo.com/v1, was bei einem Lauf mit dsh 0.2.0-rc.2 eine Anfrage an /v1/chat/completions gesendet hat. Für anthropic-messages nein: https://api.kunavo.com, da dsh selbst /v1/messages anhängt — der nackte Ursprung führte zu einer Anfrage an /v1/messages?beta=true, während eine Basis-URL mit angehängtem /v1 zu /v1/v1/messages führte. Ein echtes Gateway antwortet darauf mit 404 statt mit einem Authentifizierungsfehler. Der Testlauf erfolgte gegen einen lokalen Ersatzdienst, der Anfragen aufzeichnet, nicht gegen Kunavo.

Kann DeepSeek Harness Claude- oder GPT-Modelle statt DeepSeek verwenden?

Ja. Das API-Protokollfeld bezeichnet das Übertragungsformat, nicht den Anbieter: openai-completions ist OpenAI Chat Completions, openai-responses ist die Responses API und anthropic-messages ist die Anthropic Messages API. Ein benutzerdefinierter Anbieter übergibt deine Modell-ID direkt an die konfigurierte Basis-URL. Die ID wird also an diesem Endpunkt und nicht innerhalb des Harness aufgelöst. Bei Kunavo erreicht ein openai-completions-Anbieter unter https://api.kunavo.com/v1 Claude- und GPT-IDs; ein zweiter Anbieter mit anthropic-messages unter https://api.kunavo.com erreicht ausschließlich Claude-IDs im nativen Anthropic-Anfrageformat. Beide werden neben der integrierten DeepSeek-Karte eingerichtet, statt sie zu ersetzen. DeepSeek-IDs verwenden daher weiterhin deinen DeepSeek-Schlüssel.

Was sendet DeepSeek Harness an einen benutzerdefinierten Anbieter?

Bei einem aufgezeichneten Lauf mit dsh 0.2.0-rc.2 sendeten beide benutzerdefinierten Anbieter — openai-completions und anthropic-messages — bei jedem Agent-Turn 24 Tool-Definitionen, forderten max_tokens 32,768 an (den Standardwert des Harness für ein manuell eingegebenes Modell ohne Größenangabe) und stellten für jede neue Sitzung eine kurze Titelanfrage mit max_tokens 64. Keiner von beiden sendete dsh_session_log oder dsh_plugin_packages: Diese beiden Felder, das Ereignisprotokoll der Sitzung und die Liste der installierten Plugins, wurden nur mit der integrierten DeepSeek-Route übertragen. Beim Testlauf wurde ein Ersatzdienst verwendet, der Anfragen aufzeichnet, nicht Kunavo. Er zeigt also, was dsh sendet, nicht, was ein Anbieter damit macht.

Warum verhält sich DeepSeek Harness so, als würde es meinen System-Prompt ignorieren?

Prüfe, ob das Modell Reasoning-Stufen deklariert. Bei openai-completions sendet das Harness den System-Prompt eines Reasoning-Modells mit der Rolle "developer" statt "system", weil es das Anfrageformat aus der Endpunkt-URL ableitet und eine Adresse, die es nicht als OpenAI selbst erkennt, entsprechend behandelt. Kunavo interpretiert diese Rolle bei jeder Modellfamilie, Claude eingeschlossen, als System-Turn. Bei Kunavo kommt der Prompt also in beiden Fällen an. Bis zum 2026-09-30 ließ der Claude-Pfad die Rolle stillschweigend weg. Falls ein Prompt vorher fehlte, war das die Ursache; compat.supportsDeveloperRole: false auf der Route oder dem Modell in der cordis.patch.yml des Profils war die Abhilfe. Das ist nicht mehr erforderlich; wenn es aktiviert bleibt, ist es harmlos. Ein anthropic-messages-Anbieter sendet die Rolle nie: Sein System-Prompt wird als Anthropic-Feld system der obersten Ebene übertragen.

Warum liefert „Verfügbare Modelle abrufen“ in DeepSeek Harness nichts oder einen 401-Fehler?

Die Modellerkennung verwendet die Basis-URL, das Protokoll und den Schlüssel, die aktuell im Formular stehen. Ein 401-Fehler deutet daher meist auf den Schlüssel hin, eine leere Liste auf die Basis-URL oder ein Auflistungsformat, das die Erkennung nicht ausliest. Das Harness dokumentiert beide Fälle und empfiehlt, die IDs manuell einzugeben; das funktioniert genauso. Die beiden Protokolle senden den Schlüssel unterschiedlich: openai-completions als Authorization: Bearer, anthropic-messages im Anthropic-Header x-api-key. Kunavos Modellliste akzeptiert beides. Mit einem einfachen curl-Aufruf an https://api.kunavo.com/v1/models und demselben Schlüssel im selben Header lässt sich feststellen, wo der Fehler liegt: JSON in der Antwort bedeutet, dass das Problem im Formular liegt, 401 weist auf den Schlüssel hin, 404 auf die URL. Bei anthropic-messages lässt eine vollständige Liste noch zwei Fragen offen: ob die Basis-URL stimmt, denn die Modellerkennung entfernt ein nachgestelltes /v1 aus der Auflistungs-URL, Modellanfragen jedoch nicht; und welche IDs der Anbieter aufrufen kann, denn die Liste enthält den gesamten Katalog und dort funktionieren nur IDs mit claude-. Ein integrierter Anbieter wird immer aus dem installierten Katalog bedient, selbst wenn seine Basis-URL auf einen anderen Ort verweist. Rufe Fetch daher über einen benutzerdefinierten Anbieter auf, um zu sehen, was der Endpunkt tatsächlich bereitstellt.