DeepSeek Super-Agent : ce que coûte un agent de code proactif

Mis à jour November 2, 2026 · première publication November 2, 2026

Le Super-Agent de DeepSeek (dsh-superagent) est un prototype de recherche sous licence MIT qui interroge GitHub, transforme les demandes de personnes autorisées en tickets, et confie à une session de travail l'ouverture d'une pull request. Il limite le nombre de workers en parallèle (3 par défaut) mais n'a aucun plafond de jetons ni de dépenses : la facture du modèle n'est donc contrôlée que par votre clé de fournisseur et vos réglages.

Cet article a d'abord été publié le 2 novembre 2026 à partir du README et de la presse, puis réécrit le même jour après lecture du dépôt lui-même (sa documentation, ses prompts et son code source). Les faits proviennent du dépôt du projet et de Help Net Security. Bloomberg a rapporté la sortie comme un défi à Claude Code ; DeepSeek n'a publié aucun benchmark face à lui, il faut donc y voir un positionnement, pas un résultat.

Que fait-il ?

• Collecte : il interroge GitHub via la ligne de commande gh, par défaut toutes les 60 secondes. Il n'y a pas de webhooks. Les mentions, les issues et pull requests suivies, les commentaires de revue et les résultats de CI arrivent ainsi. Le chat Feishu est un plugin optionnel distinct, désactivé par défaut ; une installation limitée à GitHub est la configuration documentée par défaut.
• Admission : une demande est explicite lorsqu'une personne autorisée s'adresse à l'agent. Tout le reste est un candidat déduit qu'un modèle doit évaluer. Tant qu'aucune personne ne figure sur la liste d'autorisation, aucune demande ne peut devenir un ticket.
• Travail : une petite session de routage décide quoi faire de chaque déclencheur. Chaque ticket accepté reçoit sa propre session de travail persistante dans son propre répertoire, en général un git worktree. Le worker implémente, vérifie, commit, pousse et ouvre une pull request sous le propre compte GitHub de l'agent, puis suit la CI et la revue.
• Statut : le README le décrit comme un « prototype de recherche à titre de référence uniquement, et non un produit officiel de DeepSeek » et demande de le traiter comme du code de recherche, pas comme un logiciel prêt pour la production.

Où va l'argent ?

Interroger GitHub ne consomme pas de jetons de modèle. Les dépenses commencent quand un modèle est appelé. Dans le code, cela se produit à trois endroits :

1. La session de routage lit chaque déclencheur admis et l'oriente. Chaque demande explicite coûte donc au moins un tour de routage avant que le travail ne commence.
2. L'évaluateur juge les candidats déduits. Cela compte pour le réglage par défaut : en mode observe, l'agent exécute quand même l'évaluation et se contente d'enregistrer « accepterait » au lieu d'agir. Le mode observe est un mode fantôme pour les actions, pas pour le coût. Par défaut, l'agent ne reçoit que les messages qui lui sont adressés ; les messages non adressés n'atteignent donc l'évaluateur que si vous activez les interrupteurs d'observation à l'échelle du dépôt pour les issues, pull requests, commentaires ou la CI.
3. Les sessions de worker font le vrai travail : lire le code, éditer, lancer les vérifications, réessayer après des échecs et gérer les tours de revue. Chaque worker a son propre contexte, là où part l'essentiel des jetons.

Le modèle du routeur/évaluateur et celui des workers se règlent séparément, et le modèle d'un worker est fixé à la création de sa session. Le code n'a ni compteur de jetons, ni plafond par ticket, ni registre des dépenses, et le panneau n'affiche ni usage ni coût. Le seul code lié au budget détecte une erreur « budget exceeded » du fournisseur pendant les nouvelles tentatives et l'affiche comme un avertissement de santé ; il n'arrête pas le travail. La documentation de DeepSeek n'indique aucun coût par pull request.

Quelles limites existent ?

Un emplacement de worker reste occupé tant que ses tâches de fond tournent : le plafond de workers est donc aussi un plafond de dépenses de jetons simultanées, mais pas un plafond de ce que dépense chaque worker.

De quoi a-t-il besoin, et quels sont les risques ?

• Un compte utilisateur GitHub dédié pour l'agent, avec accès en écriture. Une GitHub App ne peut pas être l'agent, car l'agent lit les notifications. Il lui faut aussi l'environnement DeepSeek Harness (dsh), Node, pnpm, git, tmux et gh.
• Accès complet. Les sessions de worker tournent avec le préréglage de permissions complet, sous l'utilisateur système de l'opérateur. Le projet indique que ses enveloppes de commandes sont des valeurs par défaut, pas une frontière de sécurité. Exécutez-le sur une machine ou un compte isolé.
• L'état grossit sans limite. Les notes d'architecture précisent que les anciens enregistrements ne sont pas encore supprimés.

Comment budgétiser un essai ?

Utilisez le journal des demandes qui auraient été acceptées pour dimensionner le travail, puis chiffrez-le avec vos propres mesures. Les dépenses mensuelles valent les éléments de travail acceptés x le coût facturé moyen par élément, ce coût comprenant le tour de routage, toute évaluation, chaque appel de worker, chaque nouvelle tentative et chaque essai abandonné. Divisez les dépenses totales par le nombre d'éléments devenus des changements acceptés, comme dans le coût par tâche réussie.

Illustration avec des données supposées, pas des données DeepSeek : 200 éléments de travail par mois à un coût facturé moyen supposé de 4 $ chacun font 800 $. Si seulement 140 produisent un changement accepté, le coût par changement accepté est de 800 $ / 140 = 5,71 $, et non 4 $. L'écart est le prix du travail abandonné et rejeté.

Quels contrôles régler en premier ?

• Gardez la liste d'autorisation courte et n'y ajoutez des personnes que délibérément. C'est la première barrière de dépense.
• Laissez désactivés les interrupteurs « tout recevoir » tant que vous n'avez pas lu le journal des acceptations hypothétiques, car ce sont eux qui envoient le trafic non adressé à l'évaluateur.
• Réglez maxWorkers bas pour un essai, et placez le vrai plafond de dépenses sur la clé de votre fournisseur de modèle ou sur votre passerelle, puisque le projet n'en a pas. Voir trois budgets d'agent et les garde-fous de dépenses en production.
• Étiquetez les dépenses par dépôt et par ticket afin de relier une pull request à sa facture.
• Laissez la fusion aux personnes et traitez le prompt de livraison comme un fichier de politique avec un responsable.

Comment se compare-t-il aux autres agents GitHub ?

Trois autres options transforment une demande GitHub en pull request. Ce qui diffère, c'est l'endroit où apparaît la dépense et ce qui la plafonne. Vérifié le 2 novembre 2026 ; confirmez sur la page de chaque éditeur.

La différence pratique, c'est que les options hébergées s'inscrivent dans une facture que vous gouvernez déjà (une allocation Actions, une clé d'API avec des limites d'espace de travail) et documentent des plafonds de tours ou de durée, alors que Super-Agent vous laisse tout cela à gérer. Pour des comparaisons de coûts au niveau des outils, voir le coût de Cursor, Copilot et Claude Code.

Faut-il le déployer maintenant ?

Pour la production, non : DeepSeek dit lui-même qu'il n'est pas prêt pour la production. Pour un essai circonscrit sur un dépôt non critique, sur une machine isolée, avec une clé plafonnée, c'est un moyen peu coûteux d'apprendre ce que coûtent les agents proactifs à votre équipe, car le code est gratuit et la dépense est visible chez votre propre fournisseur. La mesure de décision est le coût par pull request acceptée rapporté à l'attention économisée, pas le titre selon lequel il concurrence un autre outil.

À lire aussi

• Qu'est-ce que DeepSeek Harness ?
• Éclatement de sous-agents et limites de concurrence
• Agents d'arrière-plan et compteur de coûts
• Coût de Cursor, Copilot et Claude Code

Vous souhaitez appliquer cela à votre plateforme ? Transmettez vos factures fournisseurs, journaux de passerelle et principaux workflows ; nous cartographierons les coûts et les économies possibles. Demander un audit gratuit →

Retour à finopsllm.com