DeepSeek Harness Test: Alle drei Durchläufe als erledigt gemeldet. Nur eine Seite funktionierte tatsächlich.

154.302 Sterne. Jede Rezension, die ich las, sagte mir die gleichen drei Dinge: Alles ist ein Plugin, das Sitzungsprotokoll ist append-only und es ist eine Entwicklervorschau.

Keine einzige sagte mir, wie viel Speicherplatz es frisst. Oder wie viel RAM eine untätige Sitzung belegt. Oder was passiert, wenn man es auf einen Endpunkt richtet, der nicht DeepSeek's eigener ist.

Also habe ich es installiert und ihm einen Job gegeben, dreimal: Erstelle einen Live-ISS-Tracker in einer einzigen eigenständigen HTML-Datei. Drei verschiedene Provider-Konfigurationen, gleicher Prompt, gleiches Modell. Alle drei wurden fertig. Alle drei druckten ein selbstbewusstes „Fertig" mit einer Aufzählungsliste all dessen, was sie angeblich verifiziert hatten.

Dann öffnete ich die drei Seiten in einem Browser. Zwei davon waren kaputt.

Wichtige Erkenntnisse

• npm install @deepseek-ai/dsh zog 531 Pakete und 306 MB auf macOS. Nicht 1,5 GB, aber auch nicht klein, und das dsh-Paket selbst macht davon 172 KB aus.
• Der dsh-Webserver lief im Leerlauf mit 35 bis 40 MB RSS bei geöffneter Live-Sitzung, nachdem er beim Start etwa 212 MB erreicht hatte. Die 500 MB, die Leute nennen, sind nicht der Serverprozess.
• Die Trajectory-Ansicht ist das wahre Ding in dieser Version. Es ist ein reiner Append-Only-JSONL-Ereignisstrom auf der Festplatte, und er hat mir ermöglicht, das Konfigurationsproblem in Minuten statt Stunden zu diagnostizieren.
• Zwei YAML-Zeilen (compat.thinkingFormat und ein echter maxTokens) verwandelten dieselbe Aufgabe von einem 36-Schritt-, 422-Sekunden-Lauf in einen 15-Schritt-, 152-Sekunden-Lauf. Keine der beiden Zeilen steht auf der Dokuseite.
• Jeder Lauf meldete Erfolg. Nur einer erzeugte eine Seite ohne Konsolenfehler. Lies die Ausgabe, nicht die Zusammenfassung.
• Es ist eine Entwicklervorschau, und die README sagt es in Großbuchstaben. Befristeter Pilot, ja. Produktionskontrollzentrum, nein.

Hier ist der gesamte Artikel in einem Bild. Zwei ISS-Tracker-Seiten, gleicher Prompt, gleiches Modell, ein Konfigurationsunterschied. Links ist der Lauf, den ich optimiert habe. Rechts ist der Lauf, den ich nicht optimiert habe.

Seitenvergleich zweier ISS-Tracker-Seiten, erstellt von DeepSeek Harness, links mit einer verstümmelten Weltkarte und einem hängengebliebenen Badge, rechts korrekt gerendert mit einem Live-Marker

Links: der optimierte Lauf, 152 Sekunden, fünfzehn fehlerhafte SVG-Pfade und ein Badge, das auf „Stale" eingefroren ist. Rechts: der naive Lauf, 422 Sekunden, null Konsolenfehler. Beide meldeten Fertig.

Warum jede DeepSeek Harness-Rezension die gleichen drei Dinge sagt

Das Repository ging am 13. August online, und als ich mit dem Schreiben begann, hatte es 154.302 Sterne und 15.960 Forks unter einer MIT-Lizenz (GitHub, August 2026). Bei dieser Geschwindigkeit ist die meiste Berichterstattung ein Lesen der README, weil es für nichts anderes Zeit gab.

Die bestehende DeepSeek Harness-Rezensionslandschaft teilt sich also in drei Lager, und alle drei haben die gleiche Lücke. Die Quellcode-Audit-Artikel zerpflücken die Plugin-Schnittstellen und führen nie einen Benchmark durch. Die Daten-Artikel vergleichen Token-Anzahlen und überspringen explizit Installationsgröße und Speicher. Die Enterprise-Procurement-Beiträge fällen ein Urteil mit fast gar keinen gemessenen Zahlen.

Niemand hat es installiert, eine Aufgabe von Anfang bis Ende ausgeführt und dann das Ergebnis geöffnet.

Unterdessen kam die schärfste Kritik nicht in einer Rezension. Es waren zwei Kommentare im Launch-Thread, die in vier Tagen 737 Punkte und 309 Kommentare erzielten.

Zwei wörtliche Hacker-News-Kommentare zur DeepSeek Harness-Installationsgröße und Speichernutzung im Leerlauf

Die beiden Beschwerden, die diese Rezension tatsächlich zu überprüfen versucht, wörtlich aus dem Launch-Thread zitiert.

Benutzer Kuyawa: „47mb heruntergeladen, 1.5gb nach dem Build, wtf?" und in einer Bearbeitung: „35 Abhängigkeiten machen 1.4gb aus, wofür sind sie?" Benutzer eglintondust in einem Unterthread über CPU-Last: „Speichernutzung ist definitiv außer Kontrolle, habe gerade eine untätige Sitzung, die 500 MB frisst" (Hacker News, August 2026).

Das sind die beiden Zahlen, die ich zuerst überprüfen wollte, weil sie die beiden sind, die entscheiden, ob dieses Ding auf Ihrem Laptop lebt. Beide erwiesen sich als komplizierter als die Zitate vermuten lassen, und eine davon misst etwas anderes, als die Leute annehmen. Wenn Sie die Architektur-Einführung brauchen, bevor das alles Sinn ergibt, das ist ein anderer Artikel: Was DeepSeek Harness eigentlich ist.

Wie ich diese DeepSeek Harness-Rezension eingerichtet habe: Eine Aufgabe, ein Endpunkt

Das Setup ist bewusst langweilig, damit die Variable die Konfiguration ist, nicht die Aufgabe.

Die Aufgabe. Erstelle einen Live-ISS-Tracker in einem einzigen eigenständigen index.html. Es braucht eine externe API, eine Kartenwiedergabe, eine Polling-Schleife und Fehlerbehandlung, also erzwingt es eine echte mehrschrittige Tool-Schleife statt eines einmaligen Code-Dumps. Und entscheidend: Ich kann das Ergebnis öffnen und sofort sehen, ob es funktioniert.

Das Modell. deepseek-ai/deepseek-v4-flash-0731, dasselbe Modell in allen drei Läufen, also ist nichts im Vergleich ein Modellunterschied.

Der Endpunkt. Das ist der Teil, den die Leute überspringen. Harness bringt kein Modell mit. Es braucht eine OpenAI-kompatible Basis-URL und einen Schlüssel, Punkt, und die Konfigurationsoberfläche dafür ist der Ort, an dem alle drei meiner Probleme herkamen. Ich habe es gegen einen gehosteten OpenAI-kompatiblen Endpunkt mit flachem DeepSeek-Preismodell und ohne Spitzenstundenzuschlag ausgeführt, was wichtig ist, wenn Sie dieselbe Aufgabe wiederholt ausführen und die Rechnung über Läufe hinweg vergleichbar haben möchten. Jeder kompatible Endpunkt funktioniert auf die gleiche Weise.

Eine ehrliche Anmerkung zu dieser mittleren Zeile, weil sie mich später gebissen hat: Sie gibt {"code":200,"msg":"succeed","data":[...]} zurück, anstatt der standardmäßigen OpenAI-{"object":"list","data":[...]}-Hülle. Das data-Array ist da, also ist ein nachsichtiger Client in Ordnung, aber gehen Sie nicht davon aus, dass jeder „OpenAI-kompatible" Endpunkt byte-identisch mit der Spezifikation ist.

Preise wurden am 18. August 2026 von der V4 Flash-Modellseite abgelesen. Derzeit gibt es kein Rabattabzeichen auf irgendein DeepSeek-Modell, also ist hier nichts ein zeitlich begrenzter Tarif.

Schritt 1: Installieren Sie DeepSeek Harness und messen Sie, was es tatsächlich kostet

Alles hier ist auf macOS mit Node 22.19+ oder 24+ reproduzierbar (es gibt keine 23.x-Unterstützung, und viele Anleitungen bekommen das falsch). Ich habe Node v24.15.0 und @deepseek-ai/[email protected] verwendet.

Beginnen Sie mit dem Schnellstart, der ein einziger Befehl ist:

bashCopy
1node -v                        # ^22.19.0 || >=24, nicht 23.x
2npx @deepseek-ai/dsh web       # Web-UI auf http://127.0.0.1:3080
3

Um eine Zahl zu erhalten, die Sie tatsächlich mit der 1,5-GB-Behauptung vergleichen können, installieren Sie es stattdessen in ein sauberes Verzeichnis und messen Sie:

bashCopy
1mkdir dsh-size && cd dsh-size && npm init -y
2npm install @deepseek-ai/dsh
3du -sh node_modules
4du -sh node_modules/* | sort -h | tail -8      # wo das Gewicht liegt
5

Hier ist, was das auf meinem Rechner erzeugt hat:

textCopy
1added 531 packages in 2m
2306M    node_modules
3255     Einträge der obersten Ebene in node_modules
4172K    node_modules/@deepseek-ai/dsh          <- das Paket selbst
5
6 13M    node_modules/@shikijs
7 13M    node_modules/openai
8 14M    node_modules/@google/genai
9 17M    node_modules/@img/sharp-libvips-darwin-arm64
10 24M    node_modules/@mistralai/mistralai
11 26M    node_modules/node-pty
12 27M    node_modules/@deepseek-ai
13 34M    node_modules/@opentelemetry
14

Also: 306 MB, nicht 1,5 GB. Die 1,5-GB-Zahl in diesem Hacker-News-Kommentar ist ein vollständiger Quell-Build, der Dev-Abhängigkeiten und Build-Ausgabe über das gesamte Monorepo hinweg einbezieht. Die Laufzeitinstallation ist ein Fünftel davon.

Allerdings sind 306 MB für einen Coding-Agent immer noch viel, und die Aufschlüsselung erklärt genau, warum Leute genervt sind. Sie installieren drei Vendor-SDKs, die Sie vielleicht nie aufrufen (openai, @google/genai, @mistralai/mistralai kommen zusammen auf 51 MB), einen vollständigen OpenTelemetry-Baum, ein natives sharp-Binary und einen Syntax-Highlighter. „Alles ist ein Plugin" hat Versandkosten, und im Moment zahlen Sie alle im Voraus, unabhängig davon, ob Sie diese Routen nutzen.

Für den Arbeitsspeicher im Leerlauf starten Sie das Web-Profil, öffnen Sie eine Sitzung, lassen Sie sie in Ruhe und lesen Sie RSS:

bashCopy
1npx @deepseek-ai/dsh web --port 3099
2# dann, in einem anderen Shell:
3ps -o pid,rss,command -p $(pgrep -f "dsh web")
4

Einmal pro Minute für fünf Minuten bei geöffneter Live-Sitzung und ohne laufende Aufgabe abgetastet:

textCopy
1t+0s     101,8 MB     (direkt nachdem die Sitzung geöffnet wurde)
2t+60s     37,0 MB
3t+120s    39,8 MB
4t+180s    38,8 MB
5t+240s    35,8 MB
6t+300s    35,0 MB
7

Es berührte etwa 212 MB während des Bootens, fiel auf ~102 MB, als die UI sich verband, dann nahm der Garbage Collector es auf die 35 bis 40 MB-Bandbreite herunter, und dort blieb es. Das ist nicht „außer Kontrolle".

Aber eglintondust liegt nicht unbedingt falsch, und das ist der Teil, den es zu verstehen lohnt: Das dsh-Web-Profil ist ein lokaler Server plus ein Browser-Tab. Die 35 MB sind der Server. Die UI ist eine vollständige Web-App in Ihrem Browser, und dieser Speicher wird Chrome zugeschrieben, nicht dsh. Wenn Sie im Aktivitätsmonitor eine 500-MB-Sitzung im Leerlauf beobachten, überprüfen Sie, welchem Prozess sie zugeordnet ist, bevor Sie einen Fehlerbericht einreichen. Vollständige Installationsdetails finden Sie im 10-minütigen Installations-Walkthrough.

Echte Terminalausgabe, die den Installations-Fußabdruck und die Arbeitsspeichermessungen im Leerlauf von DeepSeek Harness zeigt

Die tatsächlichen Messungen, mit den sichtbaren Befehlen. 306 MB installiert, 35 MB im Leerlauf.

Schritt 2: Richten Sie DeepSeek Harness auf Ihren eigenen Endpunkt

In der UI ist das Einstellungen dann Modelle dann Benutzerdefinierten Provider hinzufügen: Provider-ID, Basis-URL, Protokoll, Schlüssel, Modellliste. Sie können es auch direkt in $DSH_HOME/settings.yaml schreiben (Standard ~/.dsh/settings.yaml), was ich getan habe, weil die Dateiversion das ist, was Sie zwischen Läufen differenzieren können.

Abschnitte in dieser Datei sind nach Plugin-ID benannt, was beim ersten Mal nicht offensichtlich ist. Das Provider-Diktat gehört zu llm-pi-ai, und die Standardmodellauswahl gehört zu agent-default-model:

yamlCopy
1llm-pi-ai:
2  providers:
3    atlas:
4      displayName: Atlas Cloud
5      api: openai-completions
6      baseURL: https://api.atlascloud.ai/v1
7      apiKeyEnv: ATLAS_API_KEY
8      models:
9        - id: deepseek-ai/deepseek-v4-flash-0731
10
11agent-default-model:
12  provider: atlas
13  model: deepseek-ai/deepseek-v4-flash-0731
14

Das ist die naive Konfiguration, und es ist die, mit der ich angefangen habe. Es funktioniert. Holen Sie sich einen Schlüssel aus der Atlas-Konsole, export ATLAS_API_KEY=..., und der Lauf geht durch. Beachten Sie, dass apiKeyEnv ein Verweis ist, nicht das Geheimnis, also landet nie ein Schlüssel in dieser Datei.

Ein Detail aus der UI, das leicht zu übersehen und wirklich gut ist: Wenn der Schlüssel aus der Umgebung kommt, wird das API-Schlüsselfeld als Vom Startumgebung bereitgestellt (schreibgeschützt) angezeigt. Der grüne Punkt neben dem Provider bedeutet, dass die Route aufgelöst wurde. Der rote Punkt neben dem integrierten DeepSeek-Provider bedeutet, dass er keine Anmeldeinformationen hat. Das ist ein Zwei-Sekunden-Health-Check, den Sie nicht suchen müssen.

Zwei Dinge an dieser Konfiguration sind jedoch leise falsch, und ich habe es erst herausgefunden, als ich Trajektorien verglichen habe. Behalten Sie diesen Gedanken bis Schritt 4.

Die DeepSeek Harness-Einstellungen Modelle-Seite, die einen benutzerdefinierten OpenAI-kompatiblen Provider namens Atlas Cloud mit einem grünen Statuspunkt und seinem schreibgeschützten API-Schlüssel zeigt, der von der Startumgebung bereitgestellt wird

Einstellungen, Modelle, benutzerdefinierter Provider. Grüner Punkt bedeutet, dass die Route aufgelöst wurde; der integrierte DeepSeek-Provider darüber ist rot, weil er keinen Schlüssel hat.

Schritt 3: Die drei Läufe der DeepSeek Harness-Rezension, nebeneinander

Jedes Mal der gleiche Prompt. Fügen Sie diesen wörtlich ein, wenn Sie ihn reproduzieren möchten:

textCopy
1Erstelle eine Single-Page-ISS-Tracker in einer einzigen eigenständigen index.html.
2
3Anforderungen:
4- Rufe die ISS-Position von https://api.wheretheiss.at/v1/satellites/25544 alle 5 Sekunden ab.
5- Rendere eine Weltkarte mit einem Marker bei der aktuellen Breite/Länge, plus einer verblassenden Spur der letzten 60 Positionen.
6- Zeige Höhe (km), Geschwindigkeit (km/h) und die aktuelle Breite/Länge in einem lesbaren Panel an.
7- Kein Build-Schritt, kein npm install, kein API-Schlüssel. Nur Vanilla JS + Inline-CSS.
8- Behandle Abruffehler, ohne die Seite zu zerstören: Behalte die letzte bekannte Position und zeige ein Stale-Badge an.
9- Schreibe die Datei, dann melde Fertig.
10

Führen Sie es headless aus, damit das Transkript sauber ist:

bashCopy
1export DSH_HOME=$PWD/dsh-home
2export ATLAS_API_KEY=<your key>
3dsh --profile headless "<the prompt above>"
4

Drei Konfigurationen:

• Lauf A, der optimierte: compat.thinkingFormat: deepseek, contextWindow: 1048576, maxTokens: 131072.
• Lauf B, der naive aus Schritt 2: der Modelleintrag ist nichts als id.
• Lauf C, der plausible Fehler: gleich wie A, aber mit maxTokens: 4096, eine Zahl, die ich direkt aus dem eigenen README-Beispiel des Adapters übernommen habe.

Alle drei wurden mit Exit-Code 0 beendet. Alle drei schrieben ein index.html. Alle drei druckten eine Zusammenfassung, die Verifizierung behauptete. Die Zusammenfassung von Lauf C prahlte sogar mit Selbstreparatur: „Ein paar Bugs, die ich während des Builds gefangen und behoben habe: eine undefinierte Variable im Trail-Fade, falsche N/S-E/W-Suffix-Logik..."

Dann öffnete ich alle drei Dateien in einem echten Browser mit geöffneter Konsole und ließ sie zwei Zyklen lang abfragen.

Lesen Sie diese Tabelle noch einmal. Der schnellste Lauf und der Lauf, den ich sorgfältig optimiert hatte, lieferten beide kaputte Seiten. Der langsame, naive, teuerste Lauf ist der einzige, der funktioniert hat.

Das Versagen von Lauf A ist das lehrreiche. Das Telemetrie-Panel war perfekt: 431 km Höhe, 27.547 km/h, korrekte Breite/Länge, live aktualisiert. Die Karte darunter war ein grüner Klecks, weil alle fünfzehn Kontinentpfade in einem verlorenen L ohne Koordinaten endeten ("... L48.0 624.0 L Z"). Und das Badge sagte „Stale, behalte letzte Position" mit „Letzte Aktualisierung: -", während drei erfolgreiche Abrufe im Netzwerk-Tab saßen. Es hat den schwierigen Teil richtig gemacht und den sichtbaren Teil falsch.

Der Grund liegt in seinem eigenen Reasoning-Log, bei Schritt 12, in seinen eigenen Worten: Es hatte eine Variable gelöscht, die sein Kartenbauer noch verwendete, bemerkte es und machte trotzdem weiter. Diese Art von selbst zugefügter Regression spät in einem Lauf ist genau das, wofür ein append-only Trajectory gut ist, was der nächste Schritt ist.

Lauf C ist lustiger und schlimmer. Es behauptete, den Trail-Fade-Bug und die N/S-Suffix-Logik behoben zu haben. Der Trail ist genau das, was kaputt ist (zwölf NaN-Kreise, kein Trail wird gerendert), und die Breitengrad-Beschriftung liest -34,76° S, was doppelt signiert ist. Es hat keines der beiden Dinge behoben, die es angeblich behoben hat, und es hat seine Arbeit mit node --check verifiziert, was JavaScript-Syntax parst und nichts darüber weiß, ob ein SVG-Pfad gültig ist.

Die ISS-Tracker-Seite des dritten Laufs mit einer NaN-positionierten Spur, einem in der oberen linken Ecke feststeckenden Marker und einer doppelt signierten Breitengrad-Beschriftung

Lauf C, der 50-Sekunden-Lauf: hübsch, live und leise kaputt an den beiden Stellen, die es angeblich behoben hat.

Nichts davon ist wirklich ein Harness-Bug. Es ist ein Coding-Agent-Bug, den Harness getreu ausgeführt und dann getreu als Erfolg gemeldet hat. Was uns zu dem einen Teil dieser Version bringt, der mich wirklich beeindruckt hat.

Schritt 4: Der Zwei-Zeilen-Fix und die DeepSeek Harness-Trajectory-Ansicht, die ihn fand

Dass Lauf B 2,8x länger dauerte als Lauf A, ergab für mich keinen Sinn. Gleiches Modell, gleiche Aufgabe, und der einzige Unterschied waren ein paar Zeilen YAML. Also ging ich zur Trajectory.

Die offizielle Beschreibung ist korrekt, was seltener ist, als es sein sollte: „Alles, was das Modell sieht, wird in einem append-only Sitzungsprotokoll aufgezeichnet: Systemprompts, Reasoning, Tool-Aufrufe und -Ergebnisse, Subagent-Planung und jede Kontextinjektion... In der Trajectory-Ansicht können Sie diese Datensätze nach Quelle durchsuchen. Fortsetzen, Verzweigen, Suchen und Wiederholen arbeiten alle auf demselben Ereignisstrom" (DeepSeek Harness, August 2026).

Es ist kein Marketing. Der Stream ist eine echte Datei:

bashCopy
1ls $DSH_HOME/sessions/<workspace>/session-<uuid>/session.jsonl.zstd
2

Ein JSON-Ereignis pro Zeile, zstd-framed, append-only. Lauf A produzierte 606 Ereignisse; Lauf B produzierte 1.709. In der UI nach Quelle filtern oder einfach die dekomprimierte Datei greppen. Die Ereignistypen sind genau das, was der obige Satz verspricht: turn/start, step/start, request/header, request/context, assistant/chunk, reasoning-chunks, tool-call-chunks, tool/call, tool/result, step/end, turn/end.

Das request/header-Ereignis hat es gelöst. Es zeichnet die tatsächlich auf die Leitung gelegte Konfiguration auf:

jsoncCopy
1// Lauf A
2{"config":{"provider":"atlas","model":"deepseek-ai/deepseek-v4-flash-0731","maxTokens":131072},
3 "adapterDefaults":{"maxTokens":true}}
4
5// Lauf B
6{"config":{"provider":"atlas","model":"deepseek-ai/deepseek-v4-flash-0731"}}
7

Lauf B sendete überhaupt keine Ausgabebegrenzung, und sein Reasoning schwoll auf 72.420 Zeichen in 33 Blöcken an, gegenüber 6.094 in 9 bei Lauf A. Da kommen die zusätzlichen 270 Sekunden und die zusätzlichen 44.170 Ausgabe-Token her.

Die Ursache ist dokumentiert, aber nicht auf der Dokuseite. Sie ist vergraben in packages/llm/llm-pi-ai/README.md: der Thinking-Dialekt wird aus der Endpunkt-URL erraten. In den eigenen Worten der Maintainer ist compat.thinkingFormat etwas, das „pi-ai aus der Endpunkt-URL errät; die URL eines privaten Gateways sagt nichts aus, also würde ein Gateway im DeepSeek-Dialekt im OpenAI-Dialekt angesprochen werden, ohne Möglichkeit, dies zu korrigieren."

Mein Endpunkt gibt reasoning_content zurück, die DeepSeek-Schreibweise. Sein Hostname sagt nichts darüber aus. Also fiel der Adapter in Lauf B auf den OpenAI-Dialekt zurück, konnte kein Thinking-Level senden, und das Modell reasoned bei jedem der 36 Aufrufe mit seiner eigenen Voreinstellung. Separater Punkt: Ein Modelleintrag, der nur id deklariert, erbt die Routen-Fallbacks defaultContextWindow: 262144 und defaultMaxTokens: 32768, also verliert ein 1.048.576-Token-Modell stillschweigend drei Viertel seines Fensters.

Beides sind zwei Zeilen:

yamlCopy
1llm-pi-ai:
2  providers:
3    atlas:
4      api: openai-completions             # compat.* existiert NUR unter diesem Protokoll
5      baseURL: https://api.atlascloud.ai/v1
6      apiKeyEnv: ATLAS_API_KEY
7      compat:
8        thinkingFormat: deepseek          # hör auf, aus der URL zu raten
9        supportsReasoningEffort: true
10      models:
11        - id: deepseek-ai/deepseek-v4-flash-0731
12          contextWindow: 1048576          # überschreibe den 262.144-Fallback
13          maxTokens: 131072               # lasse dem Reasoning echten Spielraum
14

Zwei Dinge, die Sie im Kopf behalten sollten. Die Auflösungsreihenfolge ist Modell, dann Route, dann der installierte Katalogeintrag, dann pi-ais URL-Schätzung, also gewinnt ein Wert auf Modellebene. Und compat.* existiert nur unter api: openai-completions; setzen Sie es woanders hin, und die Auflösung schlägt vollständig fehl. Der Adapter unterstützt bewusst kein Bedrock, Vertex, Azure oder Codex, weil deren Authentifizierung mehr als einen Schlüssel, einen Endpunkt und Header benötigt.

Setzen Sie das, und die Drahtkonfiguration von Lauf A ist richtig, seine Token-Rechnung sinkt um das 3,5-fache, und es liefert immer noch eine kaputte Karte. Das ist die ehrliche Zusammenfassung dieser gesamten Übung: Der Konfigurationsfix ist real, und er behebt die Rechnung, nicht die Code-Review, die Sie immer noch selbst durchführen müssen.

Der append-only Sitzungsereignisstrom aus einem echten DeepSeek Harness-Lauf, mit Ereigniszählern und dem Anfrage-Header, der das Konfigurationsproblem aufdeckte

Der Trajectory-Ereignisstrom von Lauf A: 606 Ereignisse, und das eine, das die fehlende Ausgabebegrenzung enthüllte.

Was diese DeepSeek Harness-Rezension gekostet hat und ob sie produktionsreif ist

Drei vollständige Agent-Läufe einer nicht-trivialen Aufgabe, direkt aus den Trajektorien, zum flachen Satz von $0,14 in / $0,28 out pro 1M:

Zwei Dinge, die es wert sind, daraus hervorgehoben zu werden. Erstens, die Cache-Zahlen sind real, und der Endpunkt meldet sie: 93,8 % aller Prompt-Token über die drei Läufe kamen als Cache-Lesevorgänge zurück, was eine Agent-Schleife überhaupt erst erschwinglich macht. Zweitens, der falsch konfigurierte Lauf kostete das 3,5-fache des optimierten für eine Aufgabe identischer Größe. Das ist der tatsächliche Preis der beiden YAML-Zeilen.

Beachten Sie die Form des ersten Aufrufs in jedem Lauf: etwa 11.000 Eingabe-Token, bevor der Agent irgendetwas getan hat. Das ist der Systemprompt, die Tool-Schemas und der Skill-Katalog, den „alles ist ein Plugin" impliziert, und Sie zahlen ihn bei jeder neuen Sitzung. Es ist der Grund, warum die Cache-Trefferquote bei diesem Harness wichtiger ist als bei einem schlankeren, und warum ein Minimal-Mode-Lauf (Bash plus ein Dateieditor) einen Versuch wert ist, wenn Ihre Aufgabe nicht das gesamte Toolset benötigt.

Also, kann man es in der Produktion einsetzen? Nein, und das Projekt stimmt Ihnen zu. Die README in eigenen Worten: „DeepSeek Harness befindet sich derzeit in der Entwicklervorschau und wird schnell iteriert. ES WIRD KOMPATIBILITÄTSBRECHENDE ÄNDERUNGEN GEBEN." Die Web-UI öffnet sich mit einem Modal, das sagt: „DeepSeek Harness 0.1 bleibt im Test für Harness-Entwickler." Die MIT-Lizenz bedeutet, dass Sie damit tun können, was Sie wollen; es bedeutet nicht, dass die API, gegen die Sie entwickeln, nächsten Monat noch existieren wird.

Der Rest der Risikoliste ist kurz und real. Es gibt eine anonyme Telemetrie-UUID. Plugins und MCP-Server werden außerhalb der Bash-Sandbox ausgeführt, also ist ein Plugin Code, dem Sie sich entscheiden zu vertrauen. Und wie diese Rezension auf die harte Tour herausgefunden hat, sind die Einstellungen, die Kosten und Korrektheit steuern, in einer Paket-README dokumentiert, nicht im Leitfaden, was bedeutet, dass Ihre erste Rechnung ein Vielfaches dessen betragen kann, was sie sein sollte, aus Gründen, die Ihnen keine Fehlermeldung verraten wird.

DeepSeek Harness-Rezension: Häufig gestellte Fragen

Ist DeepSeek Harness produktionsreif?

Nein. Die README sagt es deutlich: „DeepSeek Harness befindet sich derzeit in der Entwicklervorschau und wird schnell iteriert. ES WIRD KOMPATIBILITÄTSBRECHENDE ÄNDERUNGEN GEBEN." Die Web-UI wiederholt es in einem Start-Modal. Ein befristeter Pilot mit einer nicht-kritischen Arbeitslast ist heute angemessen. Ein Produktionskontrollzentrum, auf das sich Ihr Team verlässt, ist es nicht, weil die API-Oberfläche, gegen die Sie entwickeln, explizit instabil ist.

Wie viel Festplatten- und Arbeitsspeicher verbraucht DeepSeek Harness tatsächlich?

Auf macOS hat npm install @deepseek-ai/dsh 531 Pakete und 306 MB gezogen, wovon das dsh-Paket selbst 172 KB ist. Die weit verbreiteten 1,5 GB sind ein vollständiger Quell-Build, nicht die Laufzeitinstallation. Der Webserver-Prozess lief im Leerlauf mit 35 bis 40 MB RSS bei geöffneter Live-Sitzung, nachdem er beim Start nahe 212 MB erreicht hatte. Der Speicher der UI wird Ihrem Browser zugeschrieben, nicht dsh.

Warum ist mein DeepSeek Harness-Lauf so viel langsamer und teurer als erwartet?

Höchstwahrscheinlich deklariert Ihr Modelleintrag nichts als id. Das erbt die Routen-Fallbacks defaultContextWindow: 262144 und defaultMaxTokens: 32768, und es lässt den Adapter den Reasoning-Dialekt aus dem Hostnamen Ihres Endpunkts erraten. In meinem Test erzeugte diese Kombination 36 Schritte statt 15 und die 3,5-fachen Token-Kosten für dieselbe Aufgabe. Setzen Sie compat.thinkingFormat, einen echten contextWindow und einen echten maxTokens.

Funktioniert DeepSeek Harness mit Nicht-DeepSeek-Endpunkten?

Ja, jede OpenAI-kompatible Basis-URL funktioniert, und so werden die meisten Leute es ausführen. Der Haken ist, dass der Thinking-Dialekt aus der URL abgeleitet wird, also wird ein Gateway im DeepSeek-Dialekt auf einem neutralen Hostnamen im OpenAI-Dialekt angesprochen. compat.thinkingFormat: deepseek ist die Lösung, und sie existiert nur unter api: openai-completions. Bedrock, Vertex, Azure und Codex werden bewusst nicht unterstützt.

Ist die Trajectory-Ansicht tatsächlich nützlich oder ist es nur Marketing?

Sie ist nützlich und das Stärkste an dieser Version. Das Sitzungsprotokoll ist eine echte Append-Only-JSONL-Datei, die Sie nach Quelle filtern, fortsetzen, verzweigen und wiederholen können, und das request/header-Ereignis hat mir genau gesagt, welche Konfiguration auf die Leitung kam, was mein Problem gelöst hat. Was es nicht tut, ist zu erklären, warum das Modell etwas gewählt hat. Es zeichnet auf, was das Modell gesehen hat, nicht, warum es entschieden hat.

DeepSeek Harness vs. Claude Code oder OpenCode: Welches sollte ich täglich verwenden?

Wenn Sie etwas wollen, das zuverlässig Code schreibt, heute nicht, noch nicht. Wählen Sie Harness, wenn die Agentenlaufzeit selbst das ist, was Sie ändern möchten, denn das Austauschen der Schleife, der Tools oder der UI ist hier Konfiguration und kein Fork. Für einen zahlenbasierten Vergleich der Token-Nutzung siehe DeepSeek Harness vs. OpenCode, und für die Erweiterungsschicht, welche Plugins sich zu installieren lohnen.

---

Läufe durchgeführt am 18. August 2026 auf macOS, Node v24.15.0, @deepseek-ai/[email protected], Modell deepseek-ai/deepseek-v4-flash-0731, bereitgestellt über einen OpenAI-kompatiblen Endpunkt auf Atlas Cloud. Jeder Token-Zähler, jede Wanduhrzeit und jeder Konsolenfehler in diesem Artikel stammen aus den Sitzungsprotokollen und Browserkonsolen dieser Läufe.