FuXi : un agent de codage en terminal, sous licence propriétaire

Le problème visé : un agent qui agit sur un dépôt réel

Un modèle de langage seul répond à des questions. FuXi part de ce constat et ajoute la couche qui manque : lire les fichiers d'un projet, les modifier, exécuter des commandes et vérifier le résultat. Le README résume la position en une phrase : le modèle est le moteur, FuXi est le véhicule. Le public visé est donc le développeur qui travaille déjà dans un terminal et qui veut déléguer des tâches concrètes (corriger un test qui échoue, étendre un module, préparer un commit) sans quitter son shell.

Le projet se présente aussi comme une alternative agnostique côté fournisseur : n'importe quel modèle compatible OpenAI, Gemini, Bedrock ou Vertex, avec sa propre clé. C'est un choix de positionnement clair face aux agents liés à un fournisseur unique. La contrepartie est immédiate : c'est à vous de choisir le modèle, d'en payer l'usage et d'assumer la qualité du résultat.

Think, Act, Verify : ce que le README décrit vraiment

La boucle annoncée s'appelle Think, Act, Verify. Le README la présente comme le coeur du produit et affirme qu'elle permet à un modèle compatible OpenAI de « performer au-dessus de son benchmark brut ». Cette affirmation est adossée à un rapport interne, benchmark/REPORT.md, que le README qualifie lui-même de petit jeu de tâches auto-administré, et non de benchmark tiers. Il précise que la mesure porte sur la boucle de l'agent, pas sur les scores bruts du modèle.

Ce que le matériel ne dit pas : le détail de l'implémentation de cette boucle. On sait qu'il existe plus de 50 outils intégrés (lecture, écriture et édition de fichiers, shell bash ou PowerShell, recherche ripgrep, récupération web, diagnostics LSP, Jupyter, usage du navigateur, tâches d'arrière-plan, sous-agents parallèles). On sait aussi que les sessions sont persistées sur disque, que des checkpoints permettent de reprendre, d'annuler ou de dupliquer une session, et que les longues conversations se compactent automatiquement pour économiser des jetons. La façon dont ces briques s'enchaînent dans la boucle n'est pas documentée dans le README. C'est une zone d'ombre réelle pour qui veut auditer le comportement avant de le laisser écrire dans un dépôt.

Routage, garde-fous et mémoire entre sessions

Deux mécanismes méritent l'attention. Le premier est le routage sensible au coût, avec bascule automatique entre fournisseurs. Le README ne publie ni la politique de routage, ni les seuils, ni la façon dont le coût est estimé avant l'appel. Un outil qui décide à votre place quel modèle traite quelle requête est pratique, mais rend le coût final difficile à prévoir sans lire le code.

Le second est le classifieur de sûreté AST. Selon le README, chaque commande shell passe par ce classifieur avant exécution, complété par des permissions fines et une journalisation d'audit. C'est le garde-fou le plus concret du produit, et c'est aussi celui qu'il faut tester en premier : un classifieur AST travaille sur la structure de la commande, pas sur son effet. Une commande construite dynamiquement, un script invoqué indirectement ou un appel réseau restent des angles morts plausibles. Le README ne donne pas la liste des motifs bloqués.

S'y ajoute une consolidation de mémoire en arrière-plan pendant les périodes d'inactivité, décrite sous le nom de dreaming. Elle agrège la mémoire entre sessions. Utile sur un projet long, discutable sur un poste partagé, d'autant que le README ne précise pas où ces données sont stockées ni comment les purger autrement qu'en supprimant ~/.fuxi.

Installation et premiers contrôles

L'installation tient en une commande par plateforme. Sur macOS et Linux :

curl -fsSL https://fuxicode.com/install.sh | bash

Sur Windows en PowerShell :

irm https://fuxicode.com/install.ps1 | iex

Le script installe dans ~/.local/bin (%USERPROFILE%\.local\bin sous Windows) et ajoute ce répertoire au PATH utilisateur s'il n'y est pas. Relancer la même commande met à jour une installation existante. Une version précise peut être épinglée en passant un argument, par exemple ./bootstrap.sh 0.1.2.

Vient ensuite la vérification, qui est la partie la plus utile de la documentation :

fuxi --version fuxi doctor

fuxi doctor contrôle l'environnement (configuration, clé d'API, git, ripgrep). Le README mentionne aussi fuxi verify pour confirmer la connexion au fournisseur. La désinstallation est manuelle : suppression du binaire, puis éventuellement de ~/.fuxi pour effacer configuration et état. Aucun paquet système, aucun gestionnaire de dépendances : le binaire est statique, ce qui simplifie le retrait autant que la pose.

Ce que le projet reconnaît ne pas avoir mesuré

C'est la section la plus honnête du README, et elle mérite d'être lue avant l'installation. FuXi ne publie aucun score sur les benchmarks tiers cités nommément : SWE-bench, Terminal-Bench, le benchmark polyglotte d'Aider. L'équipe assume ce choix et préfère renvoyer vers une méthode d'auto-évaluation.

La comparaison avec Claude Code est présentée comme un duel mesuré, mais le README la tempère dans la même section : petit jeu de tâches, auto-administré, pas tiers, et il mesure l'agent plutôt que le modèle. Autrement dit, le graphique de comparaison ne doit pas servir d'argument d'adoption. Le README fournit le rapport complet, les versions d'environnement et les commandes exactes, ce qui permet de rejouer la mesure, mais rien n'indique qu'un tiers l'ait reproduite.

Deuxième limite, plus structurelle : le fichier LICENSE n'est pas inclus dans le matériel dont je dispose, et le badge du README porte la mention Proprietary. Le README affirme par ailleurs que l'outil est gratuit pour les individus, les équipes et les entreprises. Gratuité d'usage et licence propriétaire ne sont pas contradictoires, mais la redistribution, le fork et l'usage en entreprise dépendent du texte réel, que je ne peux pas citer ici. Sur un sujet de conformité, c'est le premier document à ouvrir.

Face à un agent open source écrit en Python

L'alternative la plus directe est un agent de codage en terminal publié sous licence open source, par exemple du côté de l'écosystème Python. La différence n'est pas cosmétique. Un agent Python s'installe dans un environnement avec ses dépendances, s'étend en écrivant un outil dans le même langage, et se lit ligne à ligne quand un comportement surprend. FuXi prend le chemin inverse : un binaire Go statique, sans dépendance d'exécution, avec un mécanisme d'extension séparé (client MCP, hooks, skills, plugins, slash commands rechargeables à chaud).

Le compromis est net. Le binaire statique simplifie le déploiement et la mise à jour, mais l'extension passe par des interfaces prévues, pas par une modification du code. Et quand un classifieur de sûreté bloque une commande légitime, ou quand le routage choisit un modèle inattendu, vous n'avez pas de source à lire pour comprendre pourquoi. C'est le prix d'un produit distribué comme binaire propriétaire, et il faut l'accepter avant d'adopter.

Mises à jour, coût de suivi et périmètre de licence

La cadence de publication est rapide : trois versions entre le 5 août et le 7 septembre 2026, dont une 0.1.6 le jour même du dernier push. Le projet est en 0.1.x, ce qui veut dire que les interfaces et les clés de configuration peuvent encore bouger. Le README ne fournit pas de politique de compatibilité ascendante, et la commande fuxi update remplace le binaire en cours d'exécution après vérification de la somme de contrôle. Sur un poste de développement, cela implique de vérifier soi-même la compatibilité après chaque montée de version.

Le coût de suivi se répartit en deux postes. D'abord le coût des appels aux modèles, puisque vous apportez votre clé : le routage et la compaction automatique visent à le réduire, mais le README ne donne aucun ordre de grandeur. Ensuite le coût humain : lire le CHANGELOG à chaque version, rejouer fuxi doctor après une mise à jour, et vérifier que les permissions shell et les hooks survivent à la migration.

Côté licence, deux points factuels ressortent du matériel : le dépôt est marqué NOASSERTION et le badge du README affiche Proprietary. Le README promet la gratuité d'usage pour les individus, les équipes et les entreprises, et cite une connexion via FuXi OAuth en plus de la clé personnelle. Ce que la gratuité couvre exactement (usage commercial, nombre de postes, télémétrie éventuelle liée à OAuth) ne peut pas être déterminé à partir du README. Je ne peux que constater l'écart entre l'étiquette de licence et la promesse de gratuité, et renvoyer au texte de LICENSE.

Conclusion éditoriale

FuXi s'adresse aux développeurs qui veulent un agent de codage en terminal, agnostique côté fournisseur, et qui acceptent un binaire propriétaire : le README annonce un usage gratuit pour les individus, les équipes et les entreprises, mais le fichier LICENSE n'est pas fourni dans le matériel dont je dispose. À vérifier avant tout déploiement en équipe : le texte exact de LICENSE, la portée des permissions shell et le contenu de benchmark/REPORT.md.

Sources officielles

1. fuxicodex/Fuxi on GitHub
2. Issues
3. Project website
4. README
5. Releases