Chidori : des agents TypeScript durables sur un cœur Rust
The agent framework where every run is durable, replayable, and resumable by default.
En bref
- De quoi s’agit-il ?
- Chidori enregistre chaque effet de bord d'un agent comme un host call, ce qui rend toute exécution rejouable sans appel LLM et reprenable après un crash. Le point à trancher est le prix de cette garantie : un binaire Rust, un moteur JavaScript embarqué, et un journal de calls à traiter comme un artefact de test.
- À qui s’adresse-t-il ?
- Chidori vise les équipes qui écrivent déjà des agents en TypeScript et dont le coût principal est le débogage ou la reprise après incident, pas la latence d'un premier appel. Il faut l'éviter si vous dépendez d'un écosystème Node complet, de bindings natifs ou d'un moteur de graphes pour la visualisation.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 6 jours.
- En quel langage est-il écrit ?
- Principalement Rust, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème visé : un agent qui échoue trois exécutions plus loin
Le README pose le diagnostic sans détour : les agents sont non déterministes, coûteux et longs. Un bug n'apparaît qu'à la troisième exécution et devient irreproductible. Chaque cycle de débogage refacture les mêmes tokens. Un crash au milieu d'un enchaînement de plusieurs étapes efface tout. Et une attente d'approbation humaine impose de garder un processus vivant pendant des heures. Chidori s'adresse donc aux développeurs qui ont déjà écrit un agent en TypeScript et qui ont découvert que la partie difficile n'est pas l'appel au modèle mais tout ce qui l'entoure : rejouer une exécution, la reprendre, la tester sans dépenser. Le projet ne se présente pas comme un orchestrateur de plus posé au-dessus du désordre, mais comme une tentative de le supprimer à la source, en imposant un point de passage unique.
Un seul point de passage : le host call
Le mécanisme tient en une frontière. Tout effet de bord, appel LLM, appel d'outil ou requête HTTP, traverse le runtime sous forme de host call enregistré. L'agent ne touche jamais le monde directement. Le runtime exécute l'effet, l'inscrit dans un journal d'appels, et c'est ce journal qui devient la matière première de tout le reste : cache, replay, pause, reprise. La documentation insiste sur la conséquence : comme le runtime voit chaque effet de bord, il peut le journaliser, le mettre en cache, le rejouer, s'y interrompre et repartir de là. Les exécutions sont checkpointées à chaque safepoint. Tuer le processus au milieu d'une exécution puis reprendre dans un nouveau processus fonctionne en rejouant le journal jusqu'au point de pause, puis en continuant en direct. La déterminisme est présenté comme une politique du runtime (horloge fixe, aléatoire avec graine), pas comme une approximation : le README affirme qu'un replay produit une sortie identique octet pour octet et zéro appel LLM. C'est la revendication centrale, et elle découle entièrement de cette frontière unique.
Installation : un binaire, puis le SDK si besoin
Le runtime est un binaire autonome. Le chemin le plus court, donné dans le README, est le script d'installation :
curl -fsSL https://raw.githubusercontent.com/ThousandBirdsInc/chidori/main/scripts/install.sh | sh
Il télécharge le binaire correspondant à macOS (Apple Silicon ou Intel) ou Linux (x86_64 ou arm64) depuis la dernière release GitHub, le place dans ~/.chidori/bin et affiche la ligne de PATH à ajouter si nécessaire. La vérification se fait avec chidori --version. Deux autres voies existent : cargo install chidori, qui compile depuis les sources et exige une toolchain Rust stable 1.95 ou plus récente, et un build depuis un checkout (git clone, puis cargo build --release, le binaire se retrouvant dans ./target/release/chidori). Cette dernière voie est aussi celle qui donne accès aux examples/ fournis. Une distinction à ne pas manquer : le paquet npm @1kbirds/chidori et le paquet PyPI chidori sont les SDK, des clients optionnels qui pilotent le runtime en HTTP. Le README précise qu'aucun binding natif n'est nécessaire, et que Node, Deno et V8 ne sont pas requis puisque le moteur JavaScript embarqué est écrit en Rust.
Pause humaine et checkpoint versionné
Deux primitives sortent du lot. chidori.input() et les signaux nommés suspendent l'exécution sur disque. Un humain, ou un autre agent, répond minutes ou jours plus tard, et l'exécution reprend exactement là où elle s'était arrêtée, sans maintenir de processus ouvert. C'est la réponse directe au cas de l'approbation qui bloque une machine pendant des heures. La seconde primitive est moins spectaculaire mais plus intéressante pour une équipe : un checkpoint peut être committé dans git et servir de test. On affirme alors que le comportement de l'agent n'a pas dérivé, avec un test d'intégration qui coûte zéro et s'exécute en millisecondes selon le README. Le journal d'appels cesse d'être un fichier de débogage pour devenir un artefact versionné. C'est un choix de conception fort, et il a un revers : tout changement de prompt, d'outil ou de modèle censé modifier la sortie fera échouer ce test jusqu'à ce que le checkpoint soit régénéré. La dérive détectée est parfois voulue.
Ce que la durabilité par défaut impose
L'argument commercial du projet est clair : pas d'annotations d'étapes, pas de définition d'activités, chaque await chidori.* est un safepoint durable et rejouable. La contrepartie est structurelle. Un effet de bord qui ne passe pas par le runtime n'est pas enregistré, donc il casse la promesse de replay identique. Une bibliothèque qui ouvre elle-même une connexion réseau, un client HTTP instancié directement, un accès fichier hors des primitives : tout cela reste invisible pour le journal. Le README ne décrit pas de mécanisme de détection de ces fuites, et je n'ai pas trouvé dans la matière fournie de garde-fou annoncé pour les signaler. C'est la limite à évaluer en premier, car elle transforme la garantie en discipline d'équipe. Autre contrainte : le moteur JavaScript est embarqué et pur Rust, ce qui signifie que l'écosystème Node n'est pas disponible tel quel. Un agent qui dépend d'un module natif ou d'une API Node spécifique devra être adapté, et le projet n'est alors pas le bon outil.
Face à un moteur de workflow classique
La comparaison la plus utile est celle avec un moteur de workflow durable de type Temporal. Dans ce modèle, on écrit des workflows et des activités, et la durabilité vient de la séparation entre les deux : le code de workflow doit rester déterministe, les effets de bord vivent dans les activités, et l'orchestrateur rejoue l'historique d'événements pour reconstruire l'état. Chidori prend le problème par l'autre bout. Il n'y a pas de découpage workflow/activité à écrire, pas de graphe à déclarer, et l'agent reste du TypeScript asynchrone ordinaire avec if, for et try. La durabilité est obtenue en interceptant les appels sortants plutôt qu'en imposant une architecture en deux couches. La différence pratique est double : Chidori hérite des primitives LLM (cache de prompt structurel, marquage automatique des préfixes stables pour le cache du fournisseur) que Temporal ne fournit pas, et il ne propose pas la même séparation nette entre logique et effets, ce qui est précisément ce qui rend le second plus difficile à écrire et plus facile à raisonner sur les rejeux. À l'inverse, un framework d'agents sans durabilité, où l'on écrit des chaînes d'appels, laisse entier le problème du crash et du test gratuit.
Maintenance, licence et coût de mise à jour
Le rythme de publication est régulier : v3.6.0 en juillet 2026, v3.7.0 en août, v3.8.1 fin août, et un dernier push en septembre 2026. Une numérotation qui atteint 3.8.1 en quelques mois signale des évolutions fréquentes, donc un coût de suivi réel pour qui épingle une version. Le projet est sous Apache-2.0, une licence permissive qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation des mentions de copyright et de licence, et une clause de brevets. Rien dans la matière fournie ne décrit de politique de compatibilité entre versions mineures ni de durée de support des branches. Le README mentionne un cache de prompt dont le coût est estimé à environ 10 pour cent du tarif d'entrée de base chez Anthropic, et un replay gratuit. Ces chiffres portent sur la facturation du fournisseur, pas sur le coût d'exploitation du binaire. Pour le reste, je ne peux pas confirmer depuis ces éléments ce que coûte une montée de version majeure du journal de calls, ni si un checkpoint enregistré reste lisible par une version ultérieure. C'est la question à poser avant de committer des checkpoints dans un dépôt.
Conclusion éditoriale
Chidori vise les équipes qui écrivent déjà des agents en TypeScript et dont le coût principal est le débogage ou la reprise après incident, pas la latence d'un premier appel. Il faut l'éviter si vous dépendez d'un écosystème Node complet, de bindings natifs ou d'un moteur de graphes pour la visualisation. Avant d'adopter, vérifiez deux choses concrètes : que le binaire publié couvre votre plateforme (macOS Apple Silicon ou Intel, Linux x86_64 ou arm64 selon le script d'installation) et que vos appels LLM passent bien par chidori.*, sinon ils échapperont au journal et le replay ne sera pas identique octet pour octet.
Notes de la communauté