OpenFox : l'agent de code qui prend les modèles locaux au sérieux

Niveau DébutantTemps estimé 30 minÀ lire avant Une passerelle pour tous vos modèles, et trois façons dont un modèle local gèle vos agentsUn mot inconnu ? Lexique

OpenFox est l'agent que nous ouvrons en premier, chaque jour. Pas parce qu'il est gratuit, mais parce qu'il a été pensé pour ce qu'est vraiment un modèle local : rapide, économique, un peu distrait, et qui a besoin d'un cadre. Là où les agents pensés pour le cloud espèrent que le modèle restera sur les rails, OpenFox écrit les rails, les vérifie à chaque pas, et ne s'arrête pas avant d'arriver. Avec un modèle de 9B ou de 27B sur votre propre carte, ça change tout.

Ce que vous y gagnez. Un agent de code complet dans votre navigateur, pour n'importe quel moteur local (llama.cpp, Ollama, vLLM, SGLang), libre sous licence MIT, sans coût au jeton. Ici, il tourne sur le serveur qui porte les cartes graphiques, et l'appli Inari pilote ses sessions depuis n'importe où.

Trois agents de code, trois rôles. OpenFox pilote les modèles locaux pour les sessions de tous les jours. Claude Code tourne des deux façons : sur l'abonnement comme agent d'exploitation, et sur les modèles locaux comme junior isolé. Kimi Code prend les tâches longues ou lourdes sur son propre abonnement. Tous rejoignent les modèles par la même passerelle ou par leur fournisseur, jamais par une clé privée dans un script.

1. Ce qui le distingue : un contrat, pas un espoir

Planifier, puis construire. Vous découpez la tâche avec l'agent ; ensuite il l'implémente seul.
Les critères d'acceptation sont un contrat. Une fois le plan accepté, ses critères sont immuables : l'agent ne peut pas redéfinir en douce ce que veut dire « fini ».
Il boucle jusqu'à ce que chaque critère passe. Construire, vérifier, corriger, vérifier encore. Les petits modèles se trompent ; c'est cette boucle qui en fait du travail livré.
Un retour immédiat du serveur de langage : une modification invalide est attrapée tout de suite, pas trois étapes plus tard.
Des workflows : des enchaînements déclarés de tours d'agent, de sous-agents, de commandes shell et de validations humaines, avec une phase de relecture de code dans le cycle construire–vérifier.

2. Fait pour votre propre matériel

Il détecte votre moteur au premier lancement et se configure seul.
Des mesures en direct : temps de lecture du prompt, vitesse de génération, contexte utilisé. Vous voyez votre carte travailler, et vous voyez le contexte se remplir.
La vue pour tous les modèles : les images sont décrites avant chaque tour, si bien que même un modèle texte seul « voit » une capture d'écran.
Des modifications parallèles sûres : un verrou par fichier, pour que deux sous-agents n'écrivent jamais le même fichier en même temps.
Des greffons pour d'autres fournisseurs, outils et commandes, installables depuis l'interface sans redémarrer.

3. L'installer en une soirée

npm install -g openfox      # Node 24 ou plus récent
openfox                     # ouvre l'interface ; le premier lancement détecte votre moteur

Pointez-le sur votre passerelle de modèles plutôt que sur un serveur de modèle : la passerelle sait quel modèle est sur quelle carte, OpenFox n'a besoin que d'une adresse stable. Faites-le tourner sur la machine qui porte les cartes, et atteignez-le depuis le portable ou le téléphone par votre réseau privé.

OPENFOX_LLM_URL=http://votre-passerelle:4000/v1 \
OPENFOX_MAX_CONTEXT=65536 openfox --no-browser

Déclarez la vraie fenêtre de votre modèle avec OPENFOX_MAX_CONTEXT. La valeur par défaut suppose 200 000 jetons ; un modèle local à 64k déborderait bien avant qu'OpenFox ne compacte.

4. Le faire tourner en service sur le serveur

Le nôtre tourne en service utilisateur sur la machine qui porte les cartes, à l'écoute du seul réseau privé, si bien que le portable et le téléphone atteignent les mêmes sessions :

[Service]
Environment=OPENFOX_HOST=<l'adresse du serveur sur le réseau privé>
Environment=OPENFOX_LLM_URL=http://127.0.0.1:4000/v1
Environment=OPENFOX_MAX_CONTEXT=180224
Environment=OPENFOX_LLM_TIMEOUT=900000
Environment=OPENFOX_WORKDIR=/srv/devlab
Environment=OPENFOX_DEFAULT_AGENT=fh-coder
ExecStart=%h/.local/bin/openfox

Un long délai (15 minutes) laisse la place à un gros modèle qui lit un long prompt ; le dossier de travail cantonne les projets à une seule arborescence ; l'agent par défaut est le nôtre (voir FH Coder). Agents, workflows et skills vivent en simples fichiers dans ~/.config/openfox/, faciles à versionner.

5. Ce que nous avons ajouté autour

Il suit la carte. Un petit suiveur lit le modèle déclaré par chaque carte et réécrit le modèle par défaut d'OpenFox en conséquence : la configuration de l'agent suit le matériel, jamais l'inverse.
Une jauge de contexte dans la barre d'état du portable (voir trois petits outils).
Des clients téléphone et bureau : Inari et FoxDesk ouvrent, suivent et valident ses sessions.

Pièges

Gardez la liste d'outils courte. Notre premier tour pesait 8 455 jetons avant le moindre mot, surtout des descriptions d'outils : un seul serveur d'outils permanent au lieu de cinq, des outils chargés à la demande.

Ne laissez jamais deux processus écrire son fichier de configuration en même temps : deux enregistrements parallèles nous ont laissé un config.json corrompu. Gardez une copie avant de le modifier.

Testez-le là où il sert. Un modèle qui répond à un curl n'est pas un agent qui marche ; la preuve, c'est une session où il appelle un outil et se sert du résultat.

Sources

OpenFox, official repository

Utile ? Dites-nous ce qu'il faut mesurer ensuite.