DeepSeek Harness : compaction et baisse des coûts en 2026

Une session DeepSeek Harness affiche un cache souvent bien rempli, mais les tokens et le temps de réponse continuent d’augmenter.

La solution la plus rapide consiste à mesurer séparément l’historique, les résultats d’outils, les sorties du modèle et les champs de cache, puis à appliquer la compaction uniquement après avoir sauvegardé un état vérifiable.

Dernière mise à jour : 18 août 2026. Les données de facturation et les champs usage ont été vérifiés dans la documentation officielle de la tarification et la documentation officielle du cache de contexte. Les fonctions de Compaction et leurs conditions d’activation peuvent encore évoluer dans les versions de prévisualisation de Harness.

Cet article s’adresse :

• aux développeurs qui voient le Token consommé augmenter à chaque tour ;
• aux équipes qui font fonctionner des Agents pendant plusieurs heures et veulent limiter le coût comme le délai de réponse ;
• aux responsables techniques qui doivent comparer le coût de l’API, de l’environnement d’exécution et du temps passé à restaurer une tâche interrompue.

SECTION 01Pourquoi une session longue continue-t-elle à grossir ?

Le premier piège consiste à regarder uniquement la dernière réponse. Une boucle Agent ne paie pas seulement le nouveau message de l’utilisateur. À chaque appel, le client peut renvoyer une combinaison de quatre blocs :

1. la nouvelle instruction ;
2. l’historique des échanges précédents ;
3. le contexte système, les règles et les outils disponibles ;
4. la réponse produite lors du tour courant.

Le champ prompt_tokens correspond au volume total de l’entrée envoyée pour une requête. Il est égal à la somme de prompt_cache_hit_tokens et prompt_cache_miss_tokens, tandis que total_tokens additionne l’entrée et la sortie du modèle. Cette distinction est documentée dans la référence officielle du champ usage.

Autrement dit, une session peut produire une réponse courte tout en renvoyant un historique de plus en plus lourd. Le coût ne doit donc pas être estimé à partir du nombre de caractères affichés dans la dernière réponse, ni à partir du seul nombre de tours. Il faut conserver, pour chaque appel, les valeurs suivantes :

entrée totale = prompt_tokens
entrée servie par le cache = prompt_cache_hit_tokens
entrée non servie par le cache = prompt_cache_miss_tokens
sortie générée = completion_tokens
total facturé en tokens = total_tokens

Le problème est particulièrement visible dans les tâches de développement. Vous demandez d’abord une analyse d’architecture, puis une modification de fichier, ensuite une correction de test, puis une nouvelle vérification. Si le Harness conserve chaque message, chaque extrait de code et chaque sortie de commande, les tours suivants héritent de cette accumulation.

La croissance n’est pas nécessairement linéaire. Une commande qui renvoie un long journal, suivie d’une analyse de ce journal, puis d’un correctif qui inclut à nouveau le journal, peut faire entrer plusieurs fois la même information dans le contexte.

Pourquoi le cache peut-il être élevé alors que la consommation de tokens reste importante ?

Le cache réduit le coût appliqué à une partie déjà reconnue du préfixe, mais il ne supprime pas la taille logique de l’entrée. La documentation précise que le cache fonctionne sur des préfixes qui se recouvrent et qu’il dépend d’une correspondance complète avec une unité de préfixe déjà persistée. Une modification placée trop tôt dans le prompt peut donc empêcher une partie du cache de correspondre, tandis que les blocs ajoutés en fin de session restent à analyser.

Le diagnostic correct est alors : « le cache fonctionne sur une portion du préfixe, mais l’entrée totale continue de grossir », et non : « la requête est devenue presque gratuite ».

SECTION 02DeepSeek Harness : compaction et baisse des coûts, sans perdre l’état utile

Dans l’implémentation Harness visée par ce guide, Compaction sert à remplacer une longue séquence par un résumé contrôlé. Ce résumé peut préserver le but, les décisions, les fichiers concernés et les prochaines actions, tandis que les détails redondants sont retirés du contexte actif.

Compaction n’est toutefois pas un bouton universel de réduction de facture. Elle doit être traitée comme une transformation d’état. Si le résumé oublie une contrainte utilisateur, un test qui échoue ou une modification déjà appliquée, l’Agent peut repartir dans une mauvaise direction avec une session apparemment plus légère.

Avant d’utiliser la compression du contexte, vous devez distinguer ce qui peut être condensé de ce qui doit rester vérifiable.

Résultats généralement compressibles

• les étapes de raisonnement déjà remplacées par une décision finale ;
• les répétitions d’un même fichier ou d’une même commande ;
• les journaux dont seule la cause d’échec est utile ;
• les recherches exploratoires qui n’ont pas produit de décision ;
• les échanges de clarification devenus obsolètes.

Éléments à conserver sous forme de preuve externe

• le diff ou le contenu final des fichiers modifiés ;
• la commande exacte qui a échoué ;
• la sortie complète d’un test important ;
• les versions, variables d’environnement et paramètres d’exécution ;
• les contraintes de sécurité ou de livraison imposées par le demandeur ;
• les identifiants d’incident, rapports ou artefacts nécessaires à un audit.

Attention : un résumé disant « les tests échouent encore » ne remplace pas le nom du test, la commande utilisée et la sortie utile. Si l’Agent doit reprendre l’analyse, gardez ces éléments dans un fichier ou un artefact séparé.

Le bon modèle est donc « contexte court + état externe complet », plutôt que « contexte court + suppression définitive de l’historique ».

SECTION 03Les résultats d’outils sont-ils la principale source d’excès ?

Dans une session de code, l’outil est souvent plus volumineux que la question qui l’a déclenché. Les journaux de compilation, les résultats de recherche, les fichiers minifiés, les traces audio ou vidéo, les dépendances et les sorties de tests peuvent remplir le contexte en quelques appels.

Pour chaque outil, ajoutez une règle de restitution adaptée à sa nature :

• journal de compilation : conserver les erreurs, avertissements associés et quelques lignes de contexte ; enregistrer le journal complet dans un artefact ;
• recherche textuelle : limiter les correspondances aux fichiers et lignes pertinentes, puis demander une lecture ciblée ;
• lecture de fichier : préférer les plages de lignes ou les fonctions concernées à l’envoi du fichier entier ;
• résultat de test : conserver le statut, le nom du test et la trace d’échec ; archiver la sortie complète ailleurs ;
• fichier audio ou vidéo : transmettre des métadonnées, des timecodes ou une transcription ciblée plutôt que le contenu intégral ;
• résultat de conception : conserver les dimensions, contraintes et décisions de version, sans réinjecter toutes les variantes rejetées.

Le filtrage et le résumé ne remplissent pas le même rôle. Le filtrage retire les éléments manifestement inutiles avant leur entrée dans le contexte. Le résumé intervient après lecture pour transformer un ensemble de faits en état exploitable. Si vous résumez trop tôt un journal sans conserver l’original, vous perdez la possibilité de vérifier l’interprétation.

Comment réduire l’occupation du contexte quand un outil renvoie trop de données ?

Appliquez une politique en trois niveaux :

1. aperçu : nombre de résultats limité, noms de fichiers, première erreur ou métadonnées ;
2. inspection ciblée : récupération de lignes, objets ou segments liés à l’anomalie ;
3. artefact complet : stockage local ou distant, avec chemin et empreinte transmis à l’Agent.

Cette méthode évite de choisir entre deux mauvaises options : injecter un journal entier à chaque tour ou supprimer toute trace utile. Elle est aussi adaptée aux usages créatifs. Pour une production vidéo, l’Agent peut recevoir le codec, la durée, les pistes concernées et les timecodes en erreur, tandis que le rapport complet reste disponible pour une vérification ultérieure.

SECTION 04Le cache masque-t-il la véritable facture ?

Le cache modifie le chemin de facturation de l’entrée, mais il ne transforme pas une session interminable en session courte. La formule générale reste :

coût d’entrée =
(prompt_cache_hit_tokens × tarif cache)
+
(prompt_cache_miss_tokens × tarif hors cache)

coût total =
coût d’entrée
+
(completion_tokens × tarif de sortie)

Les tarifs doivent être lus le jour de l’analyse, car la page officielle précise qu’ils peuvent évoluer. Au moment de la vérification du 18 août 2026, la page de tarification indiquait, pour les modèles affichés à cette date, un prix d’entrée cache de 0,0028 $ par million de tokens pour le modèle Flash et de 0,003625 $ par million pour le modèle Pro ; les prix hors cache et de sortie étaient également distincts. Utilisez toujours les valeurs de la grille tarifaire officielle actuelle, plutôt qu’une capture communautaire ou un tableau recopié.

Le champ de cache doit être analysé avec le volume total. Par exemple, une requête peut présenter une grande part de prompt_cache_hit_tokens, tout en envoyant un nouveau suffixe important à chaque tour. La facture peut alors augmenter parce que la partie non réutilisée, la sortie ou le nombre total d’appels augmente.

Ne mélangez pas trois sources de vérité :

• la réponse API, qui fournit les champs usage ;
• l’interface Harness, qui peut agréger ou reformater les appels ;
• un analyseur tiers, qui peut déduire des estimations avec ses propres règles.

Pour une comparaison sérieuse, exportez les réponses brutes, associez chaque appel à un identifiant de tâche et recalculez le coût avec les tarifs du jour. La documentation officielle sur les tokens rappelle d’ailleurs que la quantité réellement traitée doit être lue dans les résultats du modèle, car les conversions entre caractères et tokens varient selon la tokenisation.

SECTION 05Quand faut-il compacter, découper ou repartir de zéro ?

La décision dépend moins de la longueur brute de la session que de la stabilité de son objectif et de la qualité de l’état récupérable.

À quel moment vaut-il mieux compacter la session que la recréer ?

Compacter est généralement préférable lorsque le but reste identique, que les fichiers de travail n’ont pas changé de périmètre et que vous pouvez produire un état de référence vérifiable. Créez plutôt une nouvelle session lorsque l’objectif change, que le premier contexte contient des hypothèses abandonnées ou que plusieurs erreurs ont été accumulées sans diagnostic fiable.

La session doit être recréée si l’Agent ne sait plus répondre précisément à ces questions :

• quel est l’objectif courant ;
• quels fichiers ont été modifiés ;
• quelles modifications sont déjà appliquées ;
• quels tests ont échoué et pour quelle raison ;
• quelles contraintes ne doivent pas être violées ;
• quelle action doit être exécutée ensuite.

SECTION 06Vérification de Compaction : la checklist avant de continuer

Ne validez pas la réduction du contexte sur la seule baisse du nombre de tokens. Faites reprendre la même tâche par l’Agent après Compaction et comparez ses réponses avec l’état sauvegardé.

• [ ] Enregistrer les champs prompt_tokens, prompt_cache_hit_tokens, prompt_cache_miss_tokens, completion_tokens et total_tokens pour chaque appel.
• [ ] Sauvegarder le diff des fichiers avant la compression.
• [ ] Conserver les tests échoués avec leur commande et leur sortie utile.
• [ ] Écrire un résumé contenant l’objectif, les décisions et les contraintes non négociables.
• [ ] Indiquer les fichiers modifiés et leur état : à créer, modifié, validé ou en attente.
• [ ] Relancer après Compaction une question sur l’objectif et la prochaine action.
• [ ] Demander à l’Agent de citer les fichiers déjà modifiés.
• [ ] Vérifier qu’il restitue les tests échoués sans inventer de résultat.
• [ ] Rejouer une action limitée, par exemple une inspection ciblée ou un test non destructif.
• [ ] Revenir à l’historique complet ou ouvrir une nouvelle session si une information critique manque.
• [ ] Comparer le coût et le délai sur une tâche identique, pas sur deux travaux différents.
• [ ] Noter la mémoire du processus, l’espace disque et le temps humain consacré à la récupération.

Cette validation est indispensable pour les tâches de développement, mais aussi pour le design et la création multimédia. Une compaction qui oublie le format de sortie, le profil colorimétrique, les dimensions ou les contraintes de diffusion peut produire un résultat techniquement propre, mais inutilisable.

Expérience de runbook : si la session compactée sait résumer l’intention mais ne sait plus identifier le dernier artefact validé, ne lui confiez pas directement une modification destructive. Restaurez l’état ou repartez d’un contexte plus propre.

SECTION 07Mesurer le coût réel avec l’environnement d’exécution

Le coût de l’API n’est qu’une partie de l’équation. Une longue session peut également maintenir un processus, un dépôt, des caches locaux, des journaux et un environnement de test pendant plusieurs heures. Si plusieurs Agents travaillent en parallèle, les interférences peuvent provoquer des relances qui augmentent indirectement le nombre d’appels.

Suivez au minimum :

• les tokens d’entrée et de sortie par tâche ;
• la part cache et hors cache ;
• le nombre de requêtes et de reprises après erreur ;
• le délai entre l’envoi et le premier résultat utile ;
• la mémoire du processus Harness ;
• la croissance du stockage occupé par les journaux et artefacts ;
• le temps humain nécessaire pour vérifier ou restaurer une compaction.

Pour comparer deux stratégies, utilisez exactement le même dépôt, les mêmes fichiers de départ, le même modèle, les mêmes outils et le même objectif. Mesurez une première exécution de référence, puis une exécution avec filtrage, une avec Compaction et, si nécessaire, une exécution répartie sur plusieurs sessions. Une seule requête moins chère ne suffit pas à prouver une amélioration stable.

La décision budgétaire peut être formulée ainsi :

• continuer si l’état est récupérable, le coût par étape reste prévu et les ressources locales sont disponibles ;
• ajuster si les outils renvoient trop de données, si le cache varie fortement ou si les réponses deviennent plus lentes ;
• séparer si plusieurs tâches se concurrencent, si l’environnement reste occupé inutilement ou si la restauration coûte plus cher que la création d’un nouveau contexte.

Le guide de tarification de MACNOX peut servir de point de comparaison lorsque vous devez inclure l’environnement Mac dans votre estimation, mais il ne remplace pas le calcul des appels API. La bonne question n’est pas « quelle session affiche le meilleur taux de cache ? », mais « quelle stratégie termine la tâche avec le moins de tokens non réutilisables, de reprises et de temps de récupération ? ».

SECTION 08Le choix entre environnement local et Mac loué

Si votre environnement actuel est un Mac local utilisé en permanence, trois limites apparaissent rapidement : il reste occupé par les tâches longues, les sessions concurrentes se disputent la mémoire et le stockage des journaux, et une interruption peut bloquer à la fois le développement interactif et l’exécution de l’Agent. Une machine virtuelle généraliste ou un poste distant mal séparé ajoute souvent de la latence, des problèmes d’accès aux fichiers et une gestion moins claire des fenêtres d’occupation.

Dans ce cas, la location d’un Mac avec MACNOX peut offrir un environnement isolé pour tester une stratégie DeepSeek Harness, exécuter une tâche longue ou séparer les travaux audio, vidéo et développement sans immobiliser votre poste principal. Elle n’est pas automatiquement préférable pour une charge stable et intensive sur une longue période, ni si vous avez besoin d’un accès physique permanent à des périphériques spécifiques. En revanche, pour une période de test, un pic de charge ou une équipe qui doit éviter les collisions entre sessions, la séparation de l’environnement peut rendre le coût total plus prévisible.

Consultez d’abord les options Mac disponibles chez MACNOX, puis comparez la durée prévue, le nombre de tâches simultanées et le coût de restauration d’une session interrompue. Vous pourrez ensuite décider s’il faut compacter, créer plusieurs sessions ou déplacer temporairement l’exécution vers un environnement dédié.

SECTION 09Pour aller plus loin

• Comparer les performances et les tarifs de DeepSeek V4 Flash
• Suivre l’évolution des prix des modèles d’IA pour mieux maîtriser les coûts