Cindy : un client open source qui orchestre Claude Code et Codex dans un seul agent local

Ce que c'est : un client local qui orchestre plusieurs agents de code

Cindy (makecindy/cindy) est un client d'agent IA open source, avec pour devise « Consider it done ». L'idée est simple. Au lieu de vous faire passer sans cesse de Claude Code à Codex et à d'autres agents de code, il réunit plusieurs « harnesses » (les environnements d'exécution des agents), plusieurs modèles et plusieurs outils dans un seul agent. Cet agent tourne sur votre propre machine, avec vos vrais fichiers et vos applications déjà connectées. Le dépôt est sous licence Apache-2.0 et forme un monorepo pnpm. Il contient une application de bureau Electron, une application mobile Expo / React Native et des paquets partagés : authentification, liaison d'appareils, orchestration d'agents, fournisseurs de modèles.

Un point passe avant tout le reste. Ce dépôt ne contient que le client. Le README précise que le service backend se trouve dans un autre dépôt et ne fait pas partie de ce monorepo. Ici, « open source » désigne le code du client, pas l'ensemble du service cloud.

Architecture centrale : harness, modèle et outils découplés

D'après le README, la conception sépare trois éléments. Le premier est le harness. Claude Code et Codex sont les premiers harnesses pris en charge. Le projet indique que d'autres arrivent et qu'un harness natif est en préparation. Les répertoires apps/*-bin contiennent les binaires d'outils livrés avec l'application de bureau. Les binaires claude-code, codex et ripgrep sont téléchargés par plateforme lors de pnpm install. Les platform-tools d'Android sont récupérés à une version fixée, avec vérification sha256, avant l'empaquetage Windows. Cindy ne réécrit donc pas un agent de code. Il embarque des CLI d'agents existantes et les traite comme des moteurs d'exécution interchangeables.

Le deuxième est le modèle. Modèles et harnesses se combinent librement, et l'on peut en changer en cours de tâche. Le README décrit quatre façons d'apporter ses modèles : se connecter au service officiel Cindy, dont la consommation est déduite de façon transparente ; autoriser un abonnement Coding Plan de Claude Code ou de Codex que l'on paie déjà, sans double facturation ; brancher ses propres clés d'API ; ou utiliser des modèles locaux. Le troisième est l'environnement de travail, qui reste continu d'un moteur à l'autre. L'espace de travail, la mémoire, les compétences et les outils persistent quand on change de harness ou de modèle. C'est la partie la plus précieuse du projet, et la plus difficile à réussir. Chaque agent a ses conventions pour le contexte, le format des appels d'outils et la description des compétences. Conserver l'état lors d'un changement de moteur exige une couche d'abstraction propre à Cindy.

Travail multi-agents : planifier, exécuter en parallèle, relire

Selon le README, une même tâche peut être planifiée, exécutée en parallèle puis relue par des agents tournant sur des combinaisons différentes de harness et de modèle. Cela correspond à une pratique devenue courante en ingénierie multi-agents : un modèle découpe la tâche, plusieurs exécutants travaillent en parallèle sur des périmètres qui ne se recoupent pas, puis un modèle d'une autre famille relit le résultat de façon indépendante. On réduit ainsi les angles morts d'un modèle qui relit son propre travail. Cindy en fait une fonction du produit, sans que l'utilisateur ait à assembler des scripts à la main.

Au-delà du code, Cindy peut piloter le navigateur, l'ordinateur et le téléphone. Il peut aussi recevoir du travail depuis la messagerie instantanée (IM) et depuis des planifications. L'ambition semble donc être un agent de travail généraliste et permanent, pas seulement un assistant de programmation.

La couche « à façonner » : mémoire, compétences, automatisation, MCP, plugins

Le projet regroupe ses points d'extension sous la formule « Yours to shape ». La mémoire : on corrige une fois, et l'agent s'en souvient, y compris d'un harness à l'autre. Les compétences : on enseigne une méthode une fois et on la réutilise partout ; le partage au sein d'une équipe est encore en préparation.

L'automatisation : les tâches récurrentes se planifient, s'exécutent et rendent compte seules. Le MCP : on branche les outils internes et les systèmes métier. Les plugins : ils sont censés circuler via une place de marché ouverte, elle aussi en préparation ; pour l'instant, on les installe via SkillHub ou à la main. Enfin, le code source peut être audité, forké, étendu et amélioré sous Apache-2.0.

Déploiement et modes d'utilisation

L'écran de connexion propose deux modes. Le service hébergé utilise un compte cloud Cindy. Le mode « Skip Sign-In » n'exige aucun compte et exécute des agents locaux ; l'application affiche alors « Non connecté » et les fonctions qui dépendent du serveur sont indisponibles. Par défaut, le client se connecte aux services cloud officiels.

Les manifestes de points d'accès sont config/endpoint.json et config/endpoint.global.json, et les mises à jour automatiques du bureau viennent du CDN officiel. Pour développer, on lance pnpm restart:desktop:remote --region=cn ou --region=global avec son propre compte Cindy. Les prérequis sont Node.js 22.x, pnpm 10.x (la version 11 n'est pas encore prise en charge) et Git LFS. Un guide d'installation existe pour Ubuntu, Arch Linux et Omarchy.

Performance et coût : aucun benchmark public

Il faut le dire clairement : le README ne publie aucun résultat de benchmark. Il ne donne ni latence, ni taux de réussite, ni comparaison de coût. On ne peut donc pas dire, à partir de cette source, de combien Cindy est plus rapide ou plus précis que Claude Code ou Codex utilisés seuls. Seule la structure des coûts est établie.

Avec un Coding Plan existant, il n'y a pas de double facture. Avec le service officiel, l'usage est déduit. Avec ses propres clés ou des modèles locaux, l'utilisateur supporte la dépense. La relecture parallèle par plusieurs agents multiplie la consommation de tokens, compromis commun à ce type de conception, dont les chiffres réels restent à mesurer.

Impact, limites et perspectives

Pour les développeurs, l'intérêt tient à moins de transferts de contexte entre outils d'agents et à une étape de relecture intégrée au flux de travail. Pour les entreprises, un client Apache-2.0, un code auditable et un mode local sur de vrais fichiers sont séduisants. Le chemin des données dépend toutefois de la source des modèles et de l'usage ou non du cloud officiel.

Les limites sont nettes. Premièrement, le backend n'est pas ouvert : le comportement du service hébergé ne peut pas être audité. Deuxièmement, un agent qui touche de vrais fichiers, des applications connectées et un téléphone dispose d'une surface de permissions très large ; l'injection de prompt et les erreurs d'action sont des risques que l'utilisateur doit évaluer et contenir. Troisièmement, la dépendance aux CLI amont (Claude Code, Codex) signifie que tout changement de leurs interfaces ou de leurs conditions de licence touche directement Cindy. Quatrièmement, le harness natif, le partage de compétences en équipe et la place de marché de plugins sont tous annoncés comme en préparation : la feuille de route n'est pas encore tenue. À suivre : la sortie du harness natif, l'ajout d'autres harnesses, des évaluations indépendantes et la documentation du modèle de sécurité.