dao-code : un agent de codage en terminal construit autour du cache de préfixe DeepSeek

Le coût comme contrainte de conception, pas comme argument marketing

La plupart des agents de codage se contentent d'appeler un modèle et d'empiler l'historique. dao-code part d'une contrainte de facturation : chez DeepSeek, un token d'entrée servi depuis le cache de préfixe coûte environ 1/120 du prix d'un token manqué. Toute la conception découle de là. Si le préfixe système, la table d'outils et la mémoire restent identiques octet pour octet d'un appel à l'autre, ces portions ne sont pas refacturées au prix fort. Si un seul octet change, le cache tombe et le coût repart à la hausse. Le README présente donc l'objectif ainsi : construire l'expérience sur le rapport prix-performance de DeepSeek plutôt que sur un modèle haut de gamme. Le public visé est précis. Des développeurs qui travaillent en terminal, qui paient à l'usage, et pour qui l'accès à un fournisseur depuis la Chine continentale compte. Le README cite Claude Code comme nécessitant un compte Anthropic et un accès réseau, et le plan de codage de GLM comme ayant des quotas difficiles à obtenir. dao-code se positionne comme une alternative accessible et bon marché, sous licence MIT.

Ce qui reste stable en octets, et ce qui tourne sur des forks

Le mécanisme central est la stabilité en octets du préfixe. Le système, la table d'outils et la mémoire sont assemblés de manière déterministe, puis réutilisés tels quels. La couche de réflexion et la mémoire ne sont pas injectées dans ce préfixe. Elles tournent sur des forks qui réutilisent le cache principal, ce qui évite de casser le préfixe tout en bénéficiant du tarif réduit. C'est le point le plus intéressant du projet : une fonctionnalité habituellement coûteuse (relire son propre travail, se souvenir du projet) est déplacée vers un chemin qui touche le cache au lieu de le casser. Le README décrit trois niveaux d'intervention quand le contexte approche de la limite : une nouvelle tentative réactive, l'effacement en place des résultats d'outils devenus obsolètes, un résumé incrémental, et un repli en troncature dure si le résumé échoue. Les sorties trop volumineuses partent sur disque, ne laissant qu'un pointeur dans le contexte. Cette architecture a un revers : toute modification qui touche le préfixe a un coût mesurable. Ajouter un outil, changer l'ordre des messages système ou reformater la mémoire ne sont pas des opérations neutres.

Mémoire auto-vérifiée : la promesse et sa zone d'ombre

La mémoire de dao-code ne se contente pas d'accumuler. En fin de session, l'agent distille préférences, conventions de projet et faits clés. Au démarrage suivant, il vérifie ces éléments contre le code courant : les faits périmés sont supprimés, les faits modifiés sont signalés. Un ramasse-miettes par décroissance élimine les souvenirs morts, et le modèle peut appeler memory_read à la demande. Le README résume la différence avec les autres agents par une formule : ils se souviennent, mais se souviennent mal. La vérification déterministe au démarrage est la partie crédible. Le nettoyage par décroissance l'est moins : le README ne précise pas les seuils, ni la façon dont un fait est jugé mort plutôt que dormant. Un utilisateur qui compte sur cette mémoire pour des conventions anciennes mais toujours valides n'a aucun moyen documenté de l'empêcher d'être évincée. C'est une limite réelle, pas un détail.

Installation et commandes réellement documentées

Le paquet est publié sur npm sous le nom dao-code, avec la commande dao. Le README indique Node ≥ 20, ce que confirme le badge du dépôt et le fichier .nvmrc. Le dépôt expose plusieurs scripts npm. npm run accept:cache lance une conversation multi-tours contre l'API réelle pour observer le taux de frappe du cache monter depuis un démarrage à froid jusqu'à un régime stable. Le README précise que cette commande sert à démontrer le mécanisme, et que les chiffres de coût publiés viennent de la suite d'évaluation, pas de cette commande. Deux commandes intégrées à l'agent sont documentées : /cost affiche le taux de frappe et la dépense, et /audit cache identifie ce qui a cassé le cache au moyen d'une empreinte à quatre dimensions. Les traces d'évaluation sont conservées dans evals/runs/<task>/run-1/agent.log, ce qui rend les chiffres rejouables. La compatibilité de configuration avec Claude Code est annoncée, ainsi que le support des Skills, de MCP et des Hooks. Le README ne montre pas de fichier de configuration complet ni de variables d'environnement, et c'est une lacune pour qui veut évaluer l'intégration avant d'installer.

Les chiffres du README, et ce qu'ils ne disent pas

Sur sept tâches de type SWE-bench issues de valibot, date-fns, es-toolkit, sqlglot et hono, le README annonce 3,89 millions de tokens d'entrée et un taux de frappe de cache global de 95,8 pour cent, entre 85,4 et 97,7 pour cent selon la tâche. Au tarif DeepSeek V4 Pro indiqué, une fonctionnalité complète (lecture, édition, test, auto-revue) reviendrait entre 0,07 et 0,21 yuan, avec une moyenne de 0,15, et 1,07 yuan pour les sept. Le README indique aussi 13/14 résolues sur un benchmark de corrections réelles, et 70/89 sur Terminal-Bench 2.1. Ces chiffres proviennent du projet lui-même. Ils sont traçables, ce qui est mieux que la moyenne, mais ils restent des chiffres de l'auteur, sur un jeu de tâches choisi par l'auteur, avec des tarifs datés de juin 2026. Le taux de frappe de 95,8 pour cent est le point sensible : il dépend du type de tâche. Une session courte avec beaucoup d'outils différents et peu de tours répétés aura un taux bien plus bas, et le coût par fonctionnalité suivra. Le README note d'ailleurs que la tâche à 85,4 pour cent de frappe est aussi la moins chère en absolu, ce qui montre que les deux variables ne se lisent pas isolément.

Quand dao-code est le mauvais outil

Le projet cible explicitement DeepSeek V4. Si vous êtes déjà engagé sur un autre fournisseur, ou si vous avez besoin d'un modèle non-DeepSeek pour des raisons de conformité, l'essentiel de l'ingénierie de dao-code perd sa valeur : le préfixe stable n'achète rien sans la tarification de cache correspondante. Autre cas défavorable : les sessions très courtes. Si vous ouvrez l'agent pour une correction de trois lignes, le coût de démarrage de la mémoire et de la vérification au lancement n'est pas amorti, et l'agent ajoute de la latence pour un gain nul. Le README ne documente pas de mode sans mémoire, ce qui rend ce cas encore moins confortable. Enfin, un agent qui lit le code, écrit le code et exécute des commandes derrière une barrière d'approbation reste une surface de risque. Le README décrit une hiérarchie de type constitution, où la sécurité et la vérité passent avant l'instruction courante, avant la politique interne, avant les Skills et la mémoire. C'est un garde-fou déclaré, pas une preuve. Un Skill tiers peut changer la façon de travailler, mais pas ce socle, affirme le README. Sur ce point, la documentation reste déclarative.

Face à un agent qui mise sur la qualité du modèle

La comparaison la plus utile n'est pas entre dao-code et un autre agent open source, mais entre deux façons de dépenser. Un agent adossé à un modèle frontal comme Claude Code achète l'expérience avec un modèle plus cher, en s'appuyant sur la qualité brute du modèle et sur un cache de lecture facturé à 0,1 fois le prix normal. dao-code achète la même expérience en réduisant le volume de tokens facturés au prix fort, via un préfixe stable et des forks. Le README chiffre l'écart en repriçant la même trace de tokens aux tarifs officiels de chaque fournisseur, en créditant Claude du taux de frappe élevé de dao-code : environ 30 fois moins cher qu'Opus 4.8, 18 fois moins cher que Sonnet 4.6. Le raisonnement est honnête sur un point : il accorde à Claude un avantage qu'il n'aurait pas nécessairement. Mais il compare des tokens, pas des résultats. La vraie question reste de savoir si DeepSeek V4 résout vos tâches. Le score de 70/89 sur Terminal-Bench 2.1 et de 13/14 sur le benchmark interne donne un ordre de grandeur, pas une garantie sur votre base de code.

Maintenance, licence et coût de mise à jour

Le dépôt est sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver l'avis de licence. Le README ne signale aucune clause additionnelle, mais rien dans le matériel fourni ne traite des questions de brevets ou de responsabilité au-delà du texte standard de la MIT. Le projet n'est pas archivé. La dernière poussée sur master date du 9 septembre 2026, après la sortie v0.4.7 du 18 juillet 2026. Les versions publiées s'enchaînent vite : v0.4.0 le 29 juin, v0.4.1 le 8 juillet, v0.4.7 le 18 juillet. Ce rythme a une conséquence pratique. Une mise à jour qui touche l'assemblage du préfixe ou la table d'outils peut faire chuter votre taux de frappe, et donc augmenter votre facture, sans que rien ne casse visiblement. C'est le coût de maintenance propre à ce projet : il ne se mesure pas en bugs, mais en points de pourcentage de cache. La commande /audit cache existe précisément pour ce diagnostic, et la commande /cost pour constater la dépense après coup. Le README ne décrit pas de politique de compatibilité entre versions mineures, ni de mécanisme de migration pour les mémoires existantes.

Conclusion éditoriale

dao-code s'adresse aux développeurs qui paient à l'usage chez DeepSeek et qui veulent un agent en terminal avec mémoire persistante sans que cette mémoire coûte cher en tokens. Il ne convient pas à ceux qui ont besoin d'un modèle non-DeepSeek, qui refusent un agent capable de lancer des commandes, ou qui cherchent un IDE plutôt qu'un shell. Avant d'adopter, vérifiez deux choses concrètes : que le paquet npm dao-code correspond bien au dépôt, et que /audit cache ne signale pas de rupture de préfixe après l'installation de vos Skills et serveurs MCP. Le vrai test est là : un taux de cache élevé dans votre propre usage, pas celui des évaluations.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. tigicion/dao-code on GitHub