agentacct

agentacct est un outil local-first d'« intelligence du travail des agents » qui répond à une question pratique : que font réellement mes agents de codage, et combien cela a-t-il coûté ? Il lit les journaux de session locaux des agents de codage et présente l'activité récente, les appels d'outils, les étapes enregistrées, les vérifications, les jetons et le coût estimé à travers les projets et les clients. Les clients pris en charge mentionnés incluent Claude Code, Codex, Kimi Code, OpenCode, Hermes et d'autres, avec une matrice de couverture documentée évaluant chaque capacité séparément. Le README note que Claude Code et Codex disposent actuellement des reçus les plus complets. L'installation se fait via pipx (Python >= 3.11 sur macOS ou Linux ; Windows uniquement via WSL), avec une application macOS signée également proposée. La configuration exécute `agentacct onboard` une fois par machine pour détecter les agents, créer un stockage local et démarrer un enregistreur ; `agentacct tui` ouvre une application terminal. Une installation limitée au projet conserve tout à l'intérieur du dépôt. L'interface s'articule autour d'une vue Sessions et d'un « reçu de travail » par tâche, combinant les sessions participantes, le résultat enregistré, le coût estimé, les affirmations et les résultats des vérifications, ainsi qu'une chronologie d'activité. Une distinction clé est faite entre Rapporté et Vérifié : le « terminé » d'un agent n'est que Rapporté, tandis que Vérifié exige des vérifications actuelles réussies après le dernier changement enregistré. Les tentatives échouées restent visibles dans l'historique. Les groupes de travail permettent de pointer vers un dossier de projet et de voir quels agents y ont travaillé, avec les détails des sessions et une chronologie partagée entre agents. Le tableau de bord affiche le dernier travail enregistré avec le client, l'heure, le résultat, les preuves et le coût, et conserve les vérifications échouées et les blocages historiques dans une zone distincte « Problèmes enregistrés » plutôt que d'en faire l'ordre de tri par défaut. Les vues d'utilisation filtrent indépendamment par date, agent, modèle et fournisseur, avec des totaux par plage par agent et modèle, un graphique quotidien avec bascules de jetons Frais/Tous, et des ventilations séparant les lectures et écritures en cache. Les jetons proviennent des enregistrements clients ; les coûts sont des estimations issues de grilles tarifaires marquées ≈ et ne constituent explicitement pas des factures. Les fenêtres de quota signalées par le fournisseur et les heures de réinitialisation apparaissent sur la même page. L'interface terminal propose des reçus, l'utilisation, la capacité et un aperçu de révision, y compris un onglet Travail ancré sur un dossier avec une chronologie inter-agents navigable au clavier. Le projet met l'accent sur l'honnêteté et la confidentialité : les estimations sont étiquetées, les données manquantes sont affichées comme un vide plutôt qu'un zéro, chaque jointure entre l'utilisation et le travail enregistré porte une étiquette de confiance (exacte, élevée, moyenne, faible), et le support est décrit par capacité plutôt que par logo. Il enregistre les métadonnées de travail telles que les noms et catégories d'outils, les fichiers touchés, les commandes expurgées des identifiants, les codes de sortie, les jetons et les étapes enregistrées, mais pas les invites, les réponses du modèle ni les transcriptions. Il lit uniquement les fichiers de session locaux, n'écoute que sur 127.0.0.1, et ne stocke ni ne demande jamais de clés API de fournisseur. Sur le plan architectural, il maintient deux flux de preuves séparés : ce qui a été utilisé (à partir des fichiers de session client) et ce qui a été fait (à partir des étapes et vérifications enregistrées via MCP plus des vérifications machine telles que les exécutions de tests), joints sur de véritables identifiants clients avec une confiance étiquetée. Claude Code lie les identifiants via un pont de crochets installé ; Codex et OpenCode sont appariés à partir de leurs propres journaux au moment de l'importation ; Hermes ne se joint que sur des identifiants explicitement transmis. Les étapes de désinstallation arrêtent les processus gérés, suppriment le démarrage automatique s'il est installé, désinstallent le paquet et suppriment éventuellement le stockage local et les entrées de configuration client. La documentation couvre le matériel de référence, la matrice de couverture, l'architecture, les limites de sécurité, le modèle de menace pour la confidentialité, des exemples détaillés et une démonstration complète.