Atomic Agent : un agent local-first qui pilote votre machine via llama.cpp
Atomic Agent is a local-first AI agent. Runs open-weight models on your own machine via llama.cpp.
En bref
- De quoi s’agit-il ?
- Atomic Agent exécute la boucle de contrôle et tout l'état sur votre poste, avec des modèles quantifiés via llama.cpp. Le dépôt annonce 69,8 % sur GAIA L1 avec un qwen-3.6-35b-a3b local, mais le projet se présente lui-même comme une developer preview aux API mouvantes.
- À qui s’adresse-t-il ?
- Atomic Agent convient aux développeurs qui veulent un agent dont la boucle de contrôle et l'état restent sur leur poste, avec un modèle quantifié servi par llama.cpp, et qui acceptent de figer une version : le README qualifie lui-même le projet de developer preview. Ceux qui ont besoin d'une intégration stable, ou qui visent des tâches exigeant un très grand modèle, devraient regarder ailleurs.
- Puis-je l’utiliser commercialement ?
- Oui. MIT 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. Le dépôt a reçu de nouveaux commits au cours des dernières 24 heures.
- En quel langage est-il écrit ?
- Principalement TypeScript, 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 : un agent dont l'état ne quitte pas la machine
La plupart des agents codent en dur un appel à une API distante. Chaque étape de raisonnement, chaque fichier lu, chaque commande exécutée transite par un service tiers. Atomic Agent prend le contrepied : le README affirme que la boucle de contrôle et tout l'état restent sur votre poste. Concrètement, cela veut dire que la mémoire de session, l'historique des tâches, les traces et les modèles téléchargés vivent dans un répertoire d'état local, et que l'inférence passe par llama.cpp plutôt que par un endpoint hébergé.
Le public visé est précis. Il faut être à l'aise avec un terminal, disposer d'une machine capable de faire tourner un modèle quantifié, et vouloir un agent qui édite des fichiers, pilote un navigateur et exécute des commandes shell avec approbation. Le README mentionne aussi une intégration dans vos propres applications via HTTP ou un sidecar Tauri, ce qui élargit la cible au-delà du seul usage interactif. En revanche, si vous cherchez un assistant web sans installation, ce n'est pas le sujet.
Le projet revendique un avantage de débit grâce à un fork llama.cpp maison, TurboQuant, annoncé à +30-50 % sur les petits modèles locaux. C'est une affirmation du README, non reproduite ici : elle n'est accompagnée d'aucun protocole de mesure dans le matériel fourni.
Ce que la boucle fait réellement : navigateur, fichiers, shell, MCP
Le README énumère les capacités de l'agent : naviguer, lire et éditer des fichiers, exécuter des commandes shell approuvées, inspecter des documents, mémoriser le contexte entre sessions, planifier des relances et appeler des outils externes via MCP. Le pilotage du navigateur s'appuie sur Playwright, présent dans les topics du dépôt, et le contrôle des sorties structurées sur GBNF, le format de grammaire de llama.cpp, également listé.
L'architecture visible dans le matériel est celle d'un CLI TypeScript qui sert de point d'entrée, avec un TUI comme interface principale. Le binaire installé embarque des ressources de support : un répertoire grammars/, des prebuilds natifs et un ripgrep fourni. Ce dernier point mérite l'attention : l'agent ne dépend pas du ripgrep de votre système, il en apporte un. C'est cohérent avec un objectif de reproductibilité, mais cela alourdit l'archive et crée une seconde copie de l'outil sur le disque.
Le README décrit deux surfaces d'intégration, HTTP et sidecar Tauri, sans détailler les routes ni le protocole. C'est une lacune réelle pour quiconque voudrait construire dessus : la documentation publique ne permet pas, à elle seule, de savoir ce qu'on peut attendre de l'API embarquée.
Installation et mise à jour : ce que les commandes font vraiment
L'installation tient en une ligne par plateforme. Sur macOS et Linux :
curl -fsSL https://atomicagent.io/install | sh
Sur Windows, en PowerShell :
irm https://atomicagent.io/install.ps1 | iex
Le README précise que l'installeur télécharge l'archive de release, vérifie la somme de contrôle, puis installe le CLI avec ses ressources. Une fois installé, le binaire se met à jour lui-même : atomic-agent update relance l'installeur en place, atomic-agent update --check se contente de sonder les nouvelles versions, et atomic-agent update --version <tag> épingle une release précise. Après une mise à jour, le TUI demande un redémarrage. Point important : seul le binaire installé peut s'auto-mettre à jour, un checkout de développement passe par git.
Le lancement se fait par atomic-agent, ou par l'alias atag déposé à côté du binaire. À l'intérieur du TUI, Ctrl+N (ou /window) ouvre une nouvelle fenêtre de terminal avec un agent neuf dans le même répertoire.
La désinstallation est traitée avec un soin inhabituel. atomic-agent uninstall supprime le répertoire d'état (config, mémoire, sessions, tâches, traces, modèles téléchargés), le binaire et son alias, les répertoires d'assets adjacents, et la ligne PATH ajoutée au fichier rc du shell. La commande affiche ce qu'elle va supprimer avec les tailles, puis demande de taper le mot uninstall. Les variantes --dry-run, --keep-data et --yes couvrent respectivement la prévisualisation, la conservation des données et l'absence d'invite en script.
Le chiffre GAIA et ce qu'il ne dit pas
Le README met en avant une comparaison sur GAIA validation Level 1, 53 tâches, avec le même modèle local qwen-3.6-35b-a3b servi par llama-server en UD-Q4_K_XL, le même budget d'étapes et le même délai. Résultat annoncé : 37/53, soit 69,8 %, contre 31/53 et 58,5 % pour Hermes, avec environ 217 secondes par tâche contre 351. Le README indique 15 victoires exclusives à Atomic Agent contre 9 à Hermes.
Ce qu'il faut noter, c'est que la variable isolée est la boucle d'agent, pas le modèle. C'est un choix de protocole défendable, et il rend la comparaison plus honnête que la plupart des tableaux de ce genre. Mais GAIA L1 reste un niveau d'entrée, et 53 tâches laissent une marge statistique notable : l'écart de 6 tâches n'est pas confortable. Aucune répétition, aucun intervalle de confiance, aucun détail sur le harnais d'évaluation n'apparaît dans le matériel fourni. Le tableau de scaling, lui, est plus informatif : 52,8 % avec qwen-3.5-9b en Q4_K_M, 45,3 % avec gemma-4-12b. Le point intéressant est le temps : le modèle 12B met environ 423 secondes par tâche, soit presque le triple du 9B, pour un score inférieur. Autrement dit, plus gros ne veut pas dire plus utile ici.
Migration depuis un autre agent : le pari de la reprise
Atomic Agent mise sur l'import comme argument d'entrée. Au premier lancement, l'outil propose de récupérer vos données depuis Hermes, OpenClaw, Claude Code ou Codex : skills, mémoire, serveurs MCP, sessions, tâches cron et, en opt-in, les clés de fournisseur. Le README insiste sur un point : une prévisualisation en dry-run s'affiche avant toute écriture. Par la suite, /import dans le TUI ou atomic-agent import <hermes|openclaw|claude-code|codex> en ligne de commande relance l'opération.
C'est un choix stratégique lisible : réduire le coût de sortie d'un concurrent en rendant la reprise de contexte mécanique. Mais la promesse a une limite structurelle. Ce qui se transpose bien, ce sont les fichiers et les sessions. Ce qui se transpose mal, c'est tout ce qui dépend du format interne d'un autre agent : les skills sont probablement traduits, pas copiés, et une traduction partielle ne se voit qu'à l'usage. Le dry-run est donc moins une commodité qu'un prérequis, et il faut le lire ligne à ligne plutôt que le survoler.
Le fait que le README liste nommément quatre agents concurrents, dont Hermes, l'adversaire du benchmark, indique que la migration est un axe de développement actif et non un script annexe.
Là où Atomic Agent n'est pas le bon outil
Le README ouvre par un avertissement explicite : developer preview, avec des API, commandes, configuration et comportements encore mouvants, et une recommandation d'épingler une release si vous avez besoin d'un point d'intégration stable. Prenez cette phrase au sérieux. Un projet qui publie trois versions en huit jours, comme le montrent v0.5.4, v0.5.5 et v0.5.6, n'a pas encore de contrat de stabilité. Si votre intégration dépend de la surface HTTP ou du sidecar Tauri, vous construisez sur du sable tant que ces interfaces ne sont pas documentées.
La contrainte matérielle est l'autre limite. Les builds annoncés couvrent macOS Apple Silicon, Linux x64 et arm64, et Windows x64. Rien sur les Mac Intel, rien sur les architectures exotiques. Et la qualité du résultat dépend directement du modèle que votre machine peut servir : le tableau de scaling montre qu'un 9B plafonne autour de la moitié des tâches GAIA L1. Si votre travail exige un raisonnement que seuls de grands modèles tiennent, un agent local-first n'est pas la bonne réponse, quelle que soit la qualité de la boucle.
Enfin, l'exécution de commandes shell approuvées reste une exécution de commandes shell. Le README ne décrit pas de bac à sable, de politique de permissions granulaire ni de journal d'audit au-delà des traces mentionnées dans le répertoire d'état. C'est un manque à combler avant tout déploiement sur une machine qui compte.
Face à Hermes : deux philosophies de boucle
La comparaison la plus utile n'est pas le score, c'est l'architecture sous-jacente. Hermes apparaît dans le matériel à la fois comme concurrent au benchmark et comme source d'import. Les deux agents peuvent piloter le même modèle local servi par llama-server, ce qui signifie que leur différence ne réside pas dans l'inférence mais dans la manière d'enchaîner les étapes.
Le README attribue l'écart de performance à la seule boucle d'agent, sans expliquer ce qui la distingue. On peut raisonnablement supposer que le contrôle des sorties par grammaires GBNF joue un rôle : forcer le modèle à produire des appels d'outil syntaxiquement valides réduit les tours perdus. C'est une hypothèse de lecture, pas une affirmation du dépôt, qui ne détaille pas ce point.
Le reste de l'écart tient au positionnement. Atomic Agent se veut une plateforme : CLI, TUI, HTTP, sidecar Tauri, MCP, planification. Hermes, d'après ce que le matériel en montre, sert de référence dans un face-à-face à modèle constant. Si vous voulez un agent que vous pouvez embarquer dans une application, la surface d'intégration d'Atomic Agent est l'argument décisif. Si vous voulez seulement la meilleure boucle pour un modèle donné, le tableau GAIA L1 est le seul élément de comparaison disponible ici, et il porte sur 53 tâches.
Coût de maintenance et licence
Le rythme de publication est rapide : trois versions en huit jours selon les releases listées. Pour un utilisateur du TUI, cela se traduit par des redémarrages après mise à jour. Pour un intégrateur, cela se traduit par un travail de vérification à chaque bump, sauf à épingler une version avec atomic-agent update --version <tag>. La commande atomic-agent update --check permet de sonder sans installer, ce qui donne un moyen concret de mesurer la fréquence avant de s'engager.
Le coût disque n'est pas trivial. Le répertoire d'état contient la config, la mémoire, les sessions, les tâches, les traces et les modèles téléchargés. Les modèles quantifiés pèsent lourd, et la désinstallation les supprime par défaut. La commande --keep-data existe précisément pour éviter de retélécharger plusieurs gigaoctets après une réinstallation. Prévoyez cet espace avant de commencer.
Le projet est sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution avec conservation de l'avis de licence. Un point mérite attention sans relever du conseil juridique : le binaire embarque un fork llama.cpp nommé TurboQuant et un ripgrep fourni. Ces composants ont leurs propres licences, et la licence MIT du dépôt ne les couvre pas nécessairement. Vérifiez les fichiers de licence des composants tiers avant toute redistribution d'un binaire modifié.
Conclusion éditoriale
Atomic Agent convient aux développeurs qui veulent un agent dont la boucle de contrôle et l'état restent sur leur poste, avec un modèle quantifié servi par llama.cpp, et qui acceptent de figer une version : le README qualifie lui-même le projet de developer preview. Ceux qui ont besoin d'une intégration stable, ou qui visent des tâches exigeant un très grand modèle, devraient regarder ailleurs. Avant de vous engager, lancez atomic-agent uninstall --dry-run pour voir ce que l'outil considère comme son emprise, puis atomic-agent update --check pour juger du rythme de publication, et vérifiez que votre matériel figure parmi les plateformes annoncées.
Notes de la communauté