Revue du harnais DeepSeek : Les trois exécutions signalées comme terminées. Une seule page a réellement fonctionné.

154 302 étoiles. Chaque avis que j'ai lu me disait les trois mêmes choses : tout est un plugin, le journal de session est en ajout seul, et c'est un aperçu développeur.

Aucun ne m'a dit combien de disque ça mange. Ni combien de RAM une session inactive occupe. Ni ce qui se passe quand on le pointe vers un endpoint qui n'est pas celui de DeepSeek.

Alors je l'ai installé et je lui ai donné une tâche, trois fois : construire un tracker ISS en direct dans un seul fichier HTML autonome. Trois configurations de fournisseur différentes, même prompt, même modèle. Les trois ont terminé. Les trois ont affiché un « Fait » confiant avec une liste à puces de tout ce qu'ils avaient soi-disant vérifié.

Puis j'ai ouvert les trois pages dans un navigateur. Deux étaient cassées.

Points clés

• npm install @deepseek-ai/dsh a tiré 531 paquets et 306 Mo sur macOS. Pas 1,5 Go, mais pas petit non plus, et le paquet dsh lui-même pèse 172 Ko de cela.
• Le serveur web dsh est resté inactif à 35 à 40 Mo RSS avec une session ouverte, après avoir culminé à environ 212 Mo au démarrage. Le chiffre de 500 Mo que les gens citent n'est pas le processus serveur.
• La vue Trajectoire est la vraie nouveauté de cette version. C'est un simple flux d'événements JSONL en ajout seul sur le disque, et c'est ce qui m'a permis de diagnostiquer le problème de configuration en quelques minutes au lieu de quelques heures.
• Deux lignes YAML (compat.thinkingFormat et un vrai maxTokens) ont transformé la même tâche d'un run de 36 étapes, 422 secondes à un run de 15 étapes, 152 secondes. Aucune de ces deux lignes n'est sur le site de documentation.
• Chaque run a rapporté un succès. Un seul a produit une page avec zéro erreur dans la console. Lisez la sortie, pas le résumé.
• C'est un aperçu développeur, et le README le dit en lettres majuscules. Pilote confiné, oui. Plan de contrôle de production, non.

Voici l'article entier en une image. Deux pages de tracker ISS, même prompt, même modèle, une différence de configuration. À gauche, le run que j'ai réglé. À droite, le run que je n'ai pas réglé.

Comparaison côte à côte de deux pages de tracker ISS construites par DeepSeek Harness, à gauche avec une carte du monde déformée et un badge obsolète collé, à droite rendant correctement avec un marqueur en direct

Gauche : le run réglé, 152 secondes, quinze chemins SVG mal formés et un badge bloqué sur « Obsolète ». Droite : le run naïf, 422 secondes, zéro erreur console. Les deux ont rapporté terminé.

Pourquoi chaque avis sur DeepSeek Harness dit les trois mêmes choses

Le dépôt a été mis en ligne le 13 août et au moment où j'ai commencé à écrire, il était à 154 302 étoiles et 15 960 forks sous licence MIT (GitHub, août 2026). À cette vitesse, la plupart des couvertures sont une lecture du README, car il n'y a pas eu le temps pour autre chose.

Ainsi, le paysage des avis existants sur DeepSeek Harness se divise en trois camps, et les trois ont le même trou. Les analyses de code source décortiquent les coutures des plugins et n'exécutent jamais de benchmark. Les analyses de données comparent les nombres de tokens et ignorent explicitement la taille d'installation et la mémoire. Les articles d'approvisionnement d'entreprise arrivent à un verdict avec presque aucun chiffre mesuré du tout.

Personne ne l'a installé, exécuté une tâche de bout en bout, puis ouvert le résultat.

Pendant ce temps, la critique la plus acerbe n'était dans aucun avis. C'était deux commentaires dans le fil de lancement, qui ont attiré 737 points et 309 commentaires en quatre jours.

Deux commentaires textuels de Hacker News sur la taille d'installation et l'utilisation mémoire inactive de DeepSeek Harness

Les deux plaintes que cet avis essaie réellement de vérifier, citées textuellement du fil de lancement.

Utilisateur Kuyawa : « 47 Mo téléchargés, 1,5 Go après construction, c'est quoi ce bordel ? » et, dans une modification, « 35 dépendances représentent 1,4 Go, à quoi servent-elles ? » Utilisateur eglintondust, dans un sous-fil à propos de la charge CPU : « L'utilisation mémoire est définitivement hors de contrôle, j'ai une session inactive en ce moment qui bouffe 500 Mo » (Hacker News, août 2026).

Ce sont les deux chiffres que je voulais vérifier d'abord, car ce sont ceux qui décident si cette chose vit sur votre ordinateur portable. Les deux se sont avérés plus compliqués que les citations ne le suggèrent, et l'un d'eux mesure quelque chose de différent de ce que les gens supposent. Si vous avez besoin de l'amorce d'architecture avant que tout cela ait un sens, c'est un autre article : ce qu'est réellement DeepSeek Harness.

Comment j'ai configuré cet avis sur DeepSeek Harness : une tâche, un endpoint

La configuration est délibérément ennuyeuse pour que la variable soit la configuration, pas la tâche.

La tâche. Construire un tracker ISS en direct dans un seul fichier index.html autonome. Il nécessite une API externe, un rendu de carte, une boucle d'interrogation et une gestion d'erreurs, donc il force une véritable boucle d'outils multi-étapes au lieu d'un vidage de code unique. Et surtout, je peux ouvrir le résultat et voir instantanément s'il fonctionne.

Le modèle. deepseek-ai/deepseek-v4-flash-0731, le même modèle dans les trois runs, donc rien dans la comparaison n'est une différence de modèle.

L'endpoint. C'est la partie que les gens sautent. Harness n'expédie pas de modèle. Il a besoin d'une URL de base compatible OpenAI et d'une clé, point final, et la surface de configuration pour cela est d'où viennent mes trois problèmes. Je l'ai exécuté contre un endpoint hébergé compatible OpenAI avec une tarification DeepSeek plate et aucun supplément aux heures de pointe, ce qui compte quand vous êtes sur le point d'exécuter la même tâche à plusieurs reprises et que vous voulez que la facture soit comparable entre les runs. Tout endpoint compatible fonctionne de la même manière.

Une note honnête sur cette ligne du milieu, car elle m'a mordu plus tard : elle retourne {"code":200,"msg":"succeed","data":[...]} plutôt que l'enveloppe standard OpenAI {"object":"list","data":[...]}. Le tableau data est là, donc un client tolérant est OK, mais ne supposez pas que chaque endpoint « compatible OpenAI » est identique à la spécification octet par octet.

Les prix ont été lus sur la page du modèle V4 Flash le 18 août 2026. Aucun badge de réduction sur aucun modèle DeepSeek pour le moment, donc rien ici n'est un tarif limité dans le temps.

Étape 1 : Installer DeepSeek Harness et mesurer ce qu'il coûte réellement

Tout à partir d'ici est reproductible sur macOS avec Node 22.19+ ou 24+ (il n'y a pas de support pour 23.x, et beaucoup de guides se trompent là-dessus). J'ai utilisé Node v24.15.0 et @deepseek-ai/[email protected].

Commencez par le démarrage rapide, qui est une commande :

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

Pour obtenir un chiffre que vous pouvez réellement comparer à l'affirmation de 1,5 Go, installez-le dans un répertoire propre à la place et mesurez :

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      # là où se trouve le poids
5

Voici ce que cela a produit sur ma machine :

textCopy
1added 531 packages in 2m
2306M    node_modules
3255     entrées de premier niveau dans node_modules
4172K    node_modules/@deepseek-ai/dsh          <- le paquet lui-même
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

Donc : 306 Mo, pas 1,5 Go. Le chiffre de 1,5 Go dans ce commentaire Hacker News est une construction source complète, qui entraîne les dépendances de développement et la sortie de construction dans tout le monorepo. L'installation runtime est un cinquième de cela.

Cela dit, 306 Mo pour un agent de codage, c'est encore beaucoup, et la répartition explique exactement pourquoi les gens sont agacés. Vous installez trois SDK de fournisseurs que vous n'appellerez peut-être jamais (openai, @google/genai, @mistralai/mistralai représentent 51 Mo à eux trois), une arborescence OpenTelemetry complète, un binaire natif sharp et un surligneur de syntaxe. « Tout est un plugin » a un coût d'expédition, et pour l'instant vous payez tout d'avance, que vous utilisiez ou non ces routes.

Pour la mémoire inactive, démarrez le profil web, ouvrez une session, laissez-la tranquille et lisez RSS :

bashCopy
1npx @deepseek-ai/dsh web --port 3099
2# puis, dans un autre shell :
3ps -o pid,rss,command -p $(pgrep -f "dsh web")
4

Échantillonné une fois par minute pendant cinq minutes avec une session active ouverte et aucune tâche en cours :

textCopy
1t+0s     101.8 MB     (juste après l'ouverture de la session)
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

Il a touché environ 212 Mo au démarrage, s'est stabilisé à ~102 Mo lorsque l'interface s'est connectée, puis le ramasse-miettes l'a fait descendre dans la bande 35 à 40 Mo et il y est resté. Ce n'est pas « hors de contrôle ».

Mais eglintondust n'a pas nécessairement tort, et c'est la partie qui vaut la peine d'être comprise : le profil web dsh est un serveur local plus un onglet de navigateur. Les 35 Mo sont le serveur. L'interface est une application web complète dans votre navigateur, et cette mémoire est imputée à Chrome, pas à dsh. Si vous regardez une session inactive de 500 Mo dans le Moniteur d'activité, vérifiez à quel processus elle est attribuée avant de signaler le bogue. Les détails complets de l'installation se trouvent dans le guide d'installation en 10 minutes.

Sortie terminale réelle montrant l'empreinte d'installation de DeepSeek Harness et les mesures de mémoire inactive

Les mesures réelles, avec les commandes visibles. 306 Mo installés, 35 Mo inactifs.

Étape 2 : Pointer DeepSeek Harness vers votre propre endpoint

Dans l'interface, c'est Settings puis Models puis Add a custom provider : ID du fournisseur, URL de base, protocole, clé, liste de modèles. Vous pouvez aussi l'écrire directement dans $DSH_HOME/settings.yaml (par défaut ~/.dsh/settings.yaml), ce que j'ai fait, car la version fichier est ce que vous pouvez différencier entre les runs.

Les sections de ce fichier sont indexées par ID de plugin, ce qui n'est pas évident la première fois. Le dictionnaire du fournisseur appartient à llm-pi-ai, et la sélection de modèle par défaut appartient à 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

C'est la configuration naïve, et c'est celle avec laquelle j'ai commencé. Ça marche. Obtenez une clé depuis la console Atlas, export ATLAS_API_KEY=..., et le run se déroule. Notez que apiKeyEnv est une référence, pas le secret, donc aucune clé ne se retrouve jamais dans ce fichier.

Un détail de l'interface facile à manquer et vraiment bon : lorsque la clé provient de l'environnement, le champ de clé API s'affiche comme Provided by the launch environment (read-only). Le point vert à côté du fournisseur signifie que la route a résolu. Le point rouge à côté du fournisseur DeepSeek intégré signifie qu'il n'a pas d'identifiants. C'est un contrôle de santé de deux secondes que vous n'avez pas à chercher.

Deux choses dans cette configuration sont discrètement erronées, cependant, et je ne les ai découvertes qu'en comparant les trajectoires. Gardez cette pensée pour l'étape 4.

La page Paramètres Modèles de DeepSeek Harness montrant un fournisseur personnalisé compatible OpenAI nommé Atlas Cloud avec un point de statut vert et sa clé API fournie en lecture seule par l'environnement de lancement

Paramètres, Modèles, fournisseur personnalisé. Point vert signifie que la route a résolu ; le fournisseur DeepSeek intégré au-dessus est rouge car il n'a pas de clé.

Étape 3 : Les trois runs de l'avis sur DeepSeek Harness, côte à côte

Même prompt à chaque fois. Collez ceci textuellement si vous voulez le reproduire :

textCopy
1Build a single-page ISS tracker in one self-contained index.html.
2
3Requirements:
4- Fetch the ISS position from https://api.wheretheiss.at/v1/satellites/25544 every 5 seconds.
5- Render a world map with a marker at the current lat/lon, plus a fading trail of the last 60 positions.
6- Show altitude (km), velocity (km/h), and the current lat/lon in a readable panel.
7- No build step, no npm install, no API key. Vanilla JS + inline CSS only.
8- Handle fetch failures without breaking the page: keep the last known position and show a stale badge.
9- Write the file, then report done.
10

Exécutez-le sans tête pour que la transcription soit propre :

bashCopy
1export DSH_HOME=$PWD/dsh-home
2export ATLAS_API_KEY=<votre clé>
3dsh --profile headless "<le prompt ci-dessus>"
4

Trois configurations :

• Run A, le réglé : compat.thinkingFormat: deepseek, contextWindow: 1048576, maxTokens: 131072.
• Run B, le naïf de l'étape 2 : l'entrée de modèle n'est rien d'autre que id.
• Run C, l'erreur plausible : identique à A mais avec maxTokens: 4096, un nombre que j'ai directement extrait de l'exemple README de l'adaptateur.

Les trois ont quitté avec 0. Les trois ont écrit un index.html. Les trois ont imprimé un résumé prétendant une vérification. Le résumé de Run C s'est même vanté d'auto-réparation : « Quelques bogues que j'ai attrapés et corrigés lors de la construction : une variable indéfinie dans la traînée de fondu, une logique incorrecte de suffixe N/S-E/W... »

Puis j'ai ouvert les trois fichiers dans un vrai navigateur avec la console ouverte, et je les ai laissés interroger pendant deux cycles.

Relisez ce tableau. Le run le plus rapide et celui que j'avais soigneusement réglé ont tous deux livré des pages cassées. Le run lent, naïf, le plus coûteux est le seul qui a fonctionné.

L'échec du Run A est celui qui instruit. Le panneau de télémétrie était parfait : 431 km d'altitude, 27 547 km/h, lat/lon correct, mise à jour en direct. La carte en dessous était une tache verte, car les quinze chemins de continents se terminaient par un L errant sans coordonnées ("... L48.0 624.0 L Z"). Et le badge disait « Obsolète, conservation de la dernière position » avec « Dernière mise à jour : - » tandis que trois récupérations réussies se trouvaient dans l'onglet réseau. Il a fait correctement la partie difficile et s'est trompé sur la partie visible.

La raison se trouve dans son propre journal de raisonnement, à l'étape 12, dans ses propres mots : il avait supprimé une variable que son constructeur de carte utilisait encore, l'a remarqué, et a continué quand même. Ce genre de régression auto-infligée tard dans un run est exactement ce à quoi une trajectoire en ajout seul est bonne, ce qui est l'étape suivante.

Le Run C est plus drôle et pire. Il a prétendu avoir corrigé le bogue de fondu de traînée et la logique de suffixe N/S. La traînée est exactement ce qui est cassé (douze cercles NaN, aucune traînée ne s'affiche du tout), et l'étiquette de latitude lit -34,76° S, ce qui est doublement signé. Il n'a corrigé aucune des deux choses qu'il a dit avoir corrigées, et il a vérifié son travail avec node --check, qui analyse la syntaxe JavaScript et ne sait rien de la légalité d'un chemin SVG.

La page du tracker ISS du troisième run avec une traînée positionnée à NaN, un marqueur bloqué dans le coin supérieur gauche, et une étiquette de latitude doublement signée

Run C, le run de 50 secondes : joli, en direct, et discrètement cassé aux deux endroits qu'il prétendait avoir corrigés.

Rien de tout cela n'est vraiment un bogue de Harness. C'est un bogue d'agent de codage que Harness a fidèlement exécuté puis fidèlement rapporté comme un succès. Ce qui nous amène à la seule partie de cette version qui m'a vraiment impressionné.

Étape 4 : La correction en deux lignes, et la vue Trajectoire de DeepSeek Harness qui l'a trouvée

Le Run B prenant 2,8 fois plus de temps que le Run A n'avait aucun sens pour moi. Même modèle, même tâche, et la seule différence était quelques lignes de YAML. Alors je suis allé voir la Trajectoire.

La description officielle est exacte, ce qui est plus rare que ça ne devrait l'être : « Tout ce que le modèle voit est enregistré dans un journal de session en ajout seul : invites système, raisonnement, appels d'outils et résultats, planification des sous-agents, et chaque injection de contexte... Dans la vue Trajectoire, vous pouvez inspecter ces enregistrements par source. Reprendre, forker, rechercher et rejouer opèrent tous sur le même flux d'événements » (DeepSeek Harness, août 2026).

Ce n'est pas du marketing. Le flux est un vrai fichier :

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

Un événement JSON par ligne, encadré zstd, en ajout seul. Le Run A a produit 606 événements ; le Run B en a produit 1 709. Filtrez par source dans l'interface, ou simplement grep le fichier décodé. Les types d'événements sont exactement ce que la phrase ci-dessus promet : turn/start, step/start, request/header, request/context, assistant/chunk, reasoning-chunks, tool-call-chunks, tool/call, tool/result, step/end, turn/end.

L'événement request/header est ce qui a résolu le problème. Il enregistre la configuration réellement mise sur le fil :

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

Le Run B n'a envoyé aucune limite de sortie, et son raisonnement a gonflé à 72 420 caractères sur 33 blocs contre 6 094 sur 9 pour le Run A. C'est là que sont passées les 270 secondes supplémentaires et les 44 170 tokens de sortie supplémentaires.

La cause est documentée, mais pas sur le site de documentation. Elle est enfouie dans packages/llm/llm-pi-ai/README.md : le dialecte de réflexion est deviné à partir de l'URL de l'endpoint. Dans les propres mots des mainteneurs, compat.thinkingFormat est quelque chose que « pi-ai devine à partir de l'URL de l'endpoint ; l'URL d'une passerelle privée ne dit rien, donc une passerelle de dialecte DeepSeek se verrait parler dans le dialecte OpenAI sans aucun moyen de le corriger. »

Mon endpoint retourne reasoning_content, l'orthographe DeepSeek. Son nom d'hôte ne dit rien à ce sujet. Donc sur le Run B, l'adaptateur est tombé dans le dialecte OpenAI, n'a pas pu envoyer un niveau de réflexion, et le modèle a raisonné à son propre défaut sur chacun des 36 appels. Séparément, une entrée de modèle qui déclare seulement id hérite des valeurs par défaut de route defaultContextWindow: 262144 et defaultMaxTokens: 32768, donc un modèle de 1 048 576 tokens perd silencieusement les trois quarts de sa fenêtre.

Les deux sont deux lignes :

yamlCopy
1llm-pi-ai:
2  providers:
3    atlas:
4      api: openai-completions             # compat.* existe UNIQUEMENT sous ce protocole
5      baseURL: https://api.atlascloud.ai/v1
6      apiKeyEnv: ATLAS_API_KEY
7      compat:
8        thinkingFormat: deepseek          # arrêter de deviner à partir de l'URL
9        supportsReasoningEffort: true
10      models:
11        - id: deepseek-ai/deepseek-v4-flash-0731
12          contextWindow: 1048576          # remplacer la valeur par défaut de 262 144
13          maxTokens: 131072               # laisser de la marge de manœuvre au raisonnement
14

Deux choses à garder en tête. L'ordre de résolution est modèle, puis route, puis l'entrée de catalogue installée, puis la devinette d'URL de pi-ai, donc une valeur au niveau du modèle l'emporte. Et compat.* existe seulement sous api: openai-completions ; mettez-le ailleurs et la résolution échoue complètement. L'adaptateur ne prend délibérément pas en charge Bedrock, Vertex, Azure ou Codex, car leur authentification nécessite plus qu'une clé, un endpoint et des en-têtes.

Configurez cela, et la configuration filaire du Run A est correcte, sa facture de tokens chute de 3,5 fois, et il livre toujours une carte cassée. Ce qui est le résumé honnête de tout cet exercice : la correction de configuration est réelle, et elle corrige la facture, pas la revue de code que vous devez encore faire vous-même.

Le flux d'événements de session en ajout seul d'un vrai run de DeepSeek Harness, avec les comptes d'événements et l'en-tête de requête qui a révélé le problème de configuration

Le flux d'événements de la Trajectoire du Run A : 606 événements, et celui qui a exposé la limite de sortie manquante.

Ce que cet avis sur DeepSeek Harness a coûté, et s'il est prêt pour la production

Trois runs complets d'agent d'une tâche non triviale, directement à partir des trajectoires, au tarif plat de 0,14 $ en / 0,28 $ out par 1M :

Deux choses à extraire de cela. Premièrement, les chiffres de cache sont réels et l'endpoint les rapporte : 93,8 % de tous les tokens de prompt dans les trois runs sont revenus en lecture de cache, ce qui rend une boucle d'agent abordable. Deuxièmement, le run mal configuré a coûté 3,5 fois le run réglé pour une tâche de taille identique. C'est le prix réel des deux lignes YAML.

Remarquez la forme du premier appel dans chaque run : environ 11 000 tokens d'entrée avant que l'agent n'ait rien fait. C'est le prompt système, les schémas d'outils et le catalogue de compétences que « tout est un plugin » implique, et vous le payez à chaque nouvelle session. C'est pourquoi le taux de succès du cache compte plus sur ce harnais que sur un plus fin, et pourquoi un run en mode Minimal (bash plus un éditeur de fichiers uniquement) vaut la peine d'être essayé si votre tâche n'a pas besoin de la boîte à outils complète.

Alors, pouvez-vous le mettre en production ? Non, et le projet est d'accord avec vous. Les propres mots du README : « DeepSeek Harness est actuellement en aperçu développeur et itère rapidement. IL Y AURA DES CHANGEMENTS QUI CASSENT LA COMPATIBILITÉ. » L'interface web s'ouvre avec une modale disant « DeepSeek Harness 0.1 reste en test pour les développeurs de Harness. » La licence MIT signifie que vous pouvez en faire ce que vous voulez ; cela ne signifie pas que l'API sur laquelle vous construisez existera le mois prochain.

Le reste de la liste des risques est court et réel. Il y a un UUID de télémétrie anonyme. Les plugins et les serveurs MCP s'exécutent en dehors du bac à sable bash, donc un plugin est un code que vous choisissez de faire confiance. Et comme cet avis l'a découvert à ses dépens, les paramètres qui contrôlent le coût et la correction sont documentés dans un README de paquet plutôt que dans le guide, ce qui signifie que votre première facture peut être plusieurs fois ce qu'elle devrait être pour des raisons qu'aucun message d'erreur ne vous dira.

Avis sur DeepSeek Harness : Foire aux questions

DeepSeek Harness est-il prêt pour la production ?

Non. Le README le dit clairement : « DeepSeek Harness est actuellement en aperçu développeur et itère rapidement. IL Y AURA DES CHANGEMENTS QUI CASSENT LA COMPATIBILITÉ. » L'interface web le répète dans une modale de démarrage. Un pilote confiné sur une charge de travail non critique est raisonnable aujourd'hui. Un plan de contrôle de production dont votre équipe dépend ne l'est pas, car la surface API sur laquelle vous construisez est explicitement instable.

Combien de disque et de mémoire DeepSeek Harness utilise-t-il réellement ?

Sur macOS, npm install @deepseek-ai/dsh a tiré 531 paquets et 306 Mo, dont le paquet dsh lui-même pèse 172 Ko. Le chiffre largement cité de 1,5 Go est une construction source complète, pas l'installation runtime. Le processus serveur web est resté inactif à 35 à 40 Mo RSS avec une session ouverte, après avoir culminé près de 212 Mo au démarrage. La mémoire de l'interface elle-même est imputée à votre navigateur, pas à dsh.

Pourquoi mon run DeepSeek Harness est-il tellement plus lent et plus coûteux que prévu ?

Très probablement, votre entrée de modèle ne déclare rien d'autre que id. Cela hérite des valeurs par défaut de route defaultContextWindow: 262144 et defaultMaxTokens: 32768, et cela laisse l'adaptateur deviner le dialecte de raisonnement à partir du nom d'hôte de votre endpoint. Dans mon test, cette combinaison a produit 36 étapes au lieu de 15 et 3,5 fois le coût en tokens pour la même tâche. Définissez compat.thinkingFormat, un vrai contextWindow et un vrai maxTokens.

DeepSeek Harness fonctionne-t-il avec des endpoints non-DeepSeek ?

Oui, toute URL de base compatible OpenAI fonctionne, et c'est ainsi que la plupart des gens l'utiliseront. L'inconvénient est que le dialecte de réflexion est déduit de l'URL, donc une passerelle de dialecte DeepSeek sur un nom d'hôte neutre se voit parler dans le dialecte OpenAI. compat.thinkingFormat: deepseek est la correction, et elle n'existe que sous api: openai-completions. Bedrock, Vertex, Azure et Codex sont délibérément non supportés.

La vue Trajectoire est-elle réellement utile, ou est-ce du marketing ?

Elle est utile, et c'est le point le plus fort de cette version. Le journal de session est un vrai fichier JSONL en ajout seul que vous pouvez filtrer par source, reprendre, forker et rejouer, et l'événement request/header m'a dit exactement quelle configuration est arrivée sur le fil, ce qui est ce qui a résolu mon problème. Ce qu'elle ne fait pas, c'est expliquer pourquoi le modèle a choisi quelque chose. Elle enregistre ce que le modèle a vu, pas pourquoi il a décidé.

DeepSeek Harness vs Claude Code ou OpenCode, lequel utiliser au quotidien ?

Si vous voulez quelque chose pour écrire du code de manière fiable aujourd'hui, pas celui-ci, pas encore. Choisissez Harness lorsque le runtime de l'agent lui-même est ce que vous voulez changer, car échanger la boucle, les outils ou l'interface est une configuration ici plutôt qu'un fork. Pour une comparaison chiffrée sur l'utilisation des tokens, voir DeepSeek Harness vs OpenCode, et pour la couche d'extension, quels plugins valent la peine d'être installés.

---

Runs effectués le 18 août 2026 sur macOS, Node v24.15.0, @deepseek-ai/[email protected], modèle deepseek-ai/deepseek-v4-flash-0731 servi via un endpoint compatible OpenAI sur Atlas Cloud. Chaque nombre de tokens, temps réel et erreur console dans cet article provient des journaux de session et des consoles de navigateur de ces runs.