dsh-baton délègue les longues tâches de Claude Code à DeepSeek : 3,16 $ au lieu de 14,18 $

Une scène familière : nous sommes jeudi, le quota hebdomadaire du développeur agentique est presque épuisé, et il reste encore deux sessions de travail. L’auteur d’une publication sur X décrit la situation avec l’ironie de quelqu’un qui la vit régulièrement. Il présente aussitôt l’une des solutions possibles : l’utilitaire dsh-baton.

De quel outil s’agit-il ?

L’idée est simple. Un modèle coûteux comme Claude Code ou Codex ne devrait pas traiter lui-même chaque longue tâche. Il la transmet à DeepSeek, moins cher et exécuté sur votre machine, puis se contente de vérifier le résultat. Cela ressemble à un ingénieur senior qui délègue l’implémentation routinière à un junior avant d’effectuer la revue.

Cette approche correspond bien à la manière dont les quotas sont consommés. La majeure partie des tokens ne sert pas à prendre des décisions complexes, mais à exécuter de longues boucles : écrire le code, lancer les tests, corriger, puis relancer. Vérifier le résultat coûte nettement moins cher que d’effectuer l’ensemble de ce cycle.

Ce que promettent les chiffres

Le README du projet donne l’exemple d’une petite application kanban. La réaliser entièrement avec Opus coûte 14,18 $. Avec dsh-baton et DeepSeek comme exécutant, la facture tombe à 3,16 $. Cela représente environ 78 % d’économies, soit un coût environ 4,5 fois inférieur. Dans les deux cas, la suite de tests réussit intégralement : 55 sur 55.

L’auteur de la publication souligne immédiatement le revers de la médaille : le temps d’exécution passe de 39 à 93 minutes. C’est 2,4 fois plus long. Il s’agit donc d’un arbitrage classique entre argent et temps, parfaitement raisonnable pour de nombreuses tâches. Si l’agent travaille la nuit ou en arrière-plan, une heure supplémentaire ne gêne personne. Si vous attendez le résultat devant l’écran, l’intérêt diminue fortement.

Comment interpréter ces résultats

Il faut garder à l’esprit qu’il s’agit d’un seul exemple tiré du README du projet lui-même, et non d’un benchmark indépendant. Une application kanban dotée de 55 tests est une tâche claire et relativement peu complexe. Aucune donnée ne montre comment cette approche se comporterait sur une grande base de code, avec des dépendances peu évidentes ou des tests instables. La publication elle-même n’a obtenu aucune vue, si bien qu’il n’existe encore ni discussion ni vérification par la communauté.

Il existe également des risques cachés. Des tests au vert indiquent uniquement que ce qu’ils couvrent fonctionne. Si le modèle chargé de la vérification ne regarde que le résultat final, les erreurs que les tests ne détectent pas peuvent passer inaperçues. Toute délégation entraîne en outre des coûts indirects : transfert du contexte, relances et erreurs potentielles du modèle exécutant.

Que faire en pratique

La démarche la plus raisonnable n’est pas d’adopter entièrement ce schéma, mais de le tester sur vos propres tâches. Les bons candidats sont les suivants :

• des tâches volumineuses, mais clairement décrites et bien couvertes par des tests ;
• des traitements en arrière-plan pour lesquels le temps n’est pas critique : migrations, refactorisations suivant un modèle, génération de tests ;
• des projets où le quota du modèle coûteux est régulièrement épuisé avant l’échéance.

Comparez trois chiffres sur une même tâche : le coût, le temps et le nombre de corrections nécessaires après la revue. Si les économies restent de plusieurs fois et que les corrections sont peu nombreuses, cette approche peut devenir permanente. Si le temps augmente au-delà de ce que vous êtes prêt à accepter, réservez les tâches complexes au modèle coûteux et ne confiez au modèle bon marché que les opérations routinières et répétitives.

La tendance générale est claire : le marché des développeurs agentiques s’éloigne du modèle unique chargé de tout faire au profit d’une combinaison dans laquelle le modèle coûteux planifie et vérifie, tandis que le modèle bon marché exécute. dsh-baton constitue un exemple précoce et encore peu éprouvé de cette approche, mais sa logique est claire et mérite d’être expérimentée.