forge : une couche de fiabilité pour le tool-calling en local

Le problème visé : un modèle local qui rate ses appels d'outils

Un modèle de 8B auto-hébergé sait souvent décrire l'outil à appeler, mais produit un JSON incomplet, ajoute une phrase avant l'objet, ou invente un nom de paramètre. Dans une boucle agentique, ces erreurs ne se contentent pas de dégrader la réponse : elles interrompent le flux. forge se présente comme une couche de fiabilité posée sur ce point précis. Le README annonce faire passer un modèle local de 8B de « single digits » à 84 % sur la suite d'évaluation maison en 26 scénarios (version 0.7.0), et Sonnet 4.6 de 85 % à 98 % sur la même charge (mesures Anthropic de la v0.6.0, non rejouées en 0.7.0 pour des raisons de coût). Ces chiffres proviennent du projet et de son propre jeu de tests : ils indiquent une direction, pas une garantie transposable à votre domaine. Le public visé est clair : équipes qui hébergent leur inférence et veulent des appels d'outils exploitables sans changer de modèle.

Ce que forge refuse d'être

Le README écarte deux malentendus. forge n'est pas un orchestrateur d'agents : les graphes multi-agents, les planificateurs en DAG et la coordination entre agents sortent du périmètre. Il vit à l'intérieur d'une seule boucle agentique. Il n'est pas non plus un harnais de codage : le projet se dit agnostique au domaine, et propose le mode proxy pour surcharger un harnais existant (opencode, aider, Cline, Claude Code) sans réécriture. Cette délimitation est utile, car elle évite d'attendre de forge une planification qu'il ne fournit pas. La structure de workflow reste optionnelle : required_steps, prerequisites et terminal_tool contraignent la boucle quand c'est nécessaire, mais les garde-fous s'appliquent aussi sans aucune étape obligatoire.

Trois points d'entrée, un même empilement de garde-fous

Le premier point d'entrée est un serveur proxy qui parle à la fois l'API chat-completions d'OpenAI et l'API Messages d'Anthropic sur /v1/messages. Un client compatible OpenAI ou Claude Code s'y connecte et forge applique ses garde-fous de façon transparente : le client croit parler à un modèle plus performant. Le README le désigne comme le point d'entrée le plus courant. Le deuxième est WorkflowRunner, qui prend en charge le cycle complet : prompts système, exécution des outils, compaction du contexte et garde-fous. SlotWorker s'y ajoute pour donner un accès en file de priorité à un slot d'inférence partagé, avec préemption automatique, dans les architectures où plusieurs workflows spécialisés se partagent un GPU. Le troisième est la pile de garde-fous seule, utilisable comme middleware dans votre propre boucle : vous gardez le contrôle, forge valide les réponses, rattrape les appels malformés et impose les étapes requises. Côté backends, le projet cite les endpoints compatibles OpenAI, Ollama, llama-server, Llamafile, vLLM et Anthropic.

Installation : deux distributions qui ne se recouvrent pas

La distribution autonome du proxy vise les machines sans Python. Sous Linux et macOS, l'installation passe par curl -fsSL https://raw.githubusercontent.com/antoinezambelli/forge/main/install.sh | sh ; sous Windows PowerShell, par irm https://raw.githubusercontent.com/antoinezambelli/forge/main/install.ps1 | iex. Elle embarque forge, son runtime Python privé et le SDK Anthropic. Le README précise ce qu'elle n'installe pas : ni exécutable de backend, ni modèle, ni pile GPU, ni service, ni identifiants, ni configuration client. Ensuite, forge-proxy init crée un profil et forge-proxy check le valide. La bibliothèque Python s'installe séparément avec pip install forge-guardrails, ou pip install "forge-guardrails[anthropic]" pour le client Anthropic. Elle exige Python 3.12 ou plus récent et un backend en fonctionnement. Point de conception à retenir : le paquet Python n'installe volontairement pas de commande globale forge-proxy. Son implémentation proxy se lance avec python -m forge.proxy, et l'installateur autonome reste le seul propriétaire du cycle de mise à jour et de désinstallation. Si vous mélangez les deux, vous aurez deux chemins de maintenance pour le même composant.

Le mécanisme : un contexte budgété et une compaction par paliers

L'exemple du README montre la mécanique. Un Workflow regroupe un nom, une description, un dictionnaire d'outils et un prompt système. Chaque outil associe un ToolSpec, dont les paramètres sont décrits par un modèle Pydantic, à une fonction Python ordinaire. Le runner reçoit un client (ici LlamafileClient, avec un chemin GGUF, mode "native" et recommended_sampling=True) et un ContextManager. Ce dernier porte la contrainte la plus concrète du cadre : une stratégie TieredCompact avec keep_recent=2 et un budget_tokens de 8192. La compaction ne se déclenche donc pas au hasard, elle répond à un plafond explicite. C'est là que se joue la différence avec un simple wrapper : le contexte est traité comme une ressource finie, pas comme un historique qui grandit. Le README indique aussi que la validation des réponses, les relances de retry et le parsing de secours s'appliquent même quand required_steps est vide.

Le proxy comme contournement d'un harnais existant

Le mode proxy mérite qu'on s'y arrête, parce qu'il déplace le problème. Au lieu d'intégrer la bibliothèque, vous interposez forge entre un client déjà installé et votre serveur de modèle local. Le client continue de fonctionner comme avant, y compris Claude Code via /v1/messages. Le coût de cette approche est un processus supplémentaire dans la chaîne, avec son propre cycle de vie géré par l'installateur autonome. L'avantage est de ne pas réécrire un harnais dont la valeur tient à autre chose que la robustesse des appels d'outils. Le README note que la v0.9.3 a corrigé un problème de propriété de commande dans le proxy : signe que cette couche a un historique de maintenance actif, et qu'il faut suivre les versions plutôt que d'épingler une build ancienne.

Limites et cas où forge n'est pas le bon outil

La limite la plus nette est énoncée par le projet lui-même : forge ne coordonne pas plusieurs agents. Si votre architecture repose sur un planificateur, un graphe de tâches ou une répartition entre agents spécialisés, forge n'en fera pas partie, sauf comme brique de fiabilité à l'intérieur de chaque boucle. Deuxième limite : les gains annoncés sont mesurés sur la suite d'évaluation de forge, en 26 scénarios, et les chiffres Anthropic n'ont pas été rejoués en 0.7.0. Un domaine métier aux schémas d'outils plus complexes peut se comporter autrement. Troisième point : le choix du backend n'est pas neutre. Le README recommande llama-server et indique que les dix meilleures configurations d'évaluation tournent dessus, Ollama étant présenté comme plus simple à installer mais « slightly weaker on harder workloads ». Enfin, la bibliothèque Python impose Python 3.12 ou plus récent, ce qui exclut les environnements plus anciens. Si vous utilisez déjà un agent de codage abouti, le mode proxy suffit ; réécrire votre boucle avec WorkflowRunner n'apporterait rien de plus.

Alternatives et maintenance

L'alternative la plus évidente est le harnais que vous utilisez déjà : opencode, aider ou Cline gèrent leur propre boucle d'appels d'outils et leur propre politique de relance. La différence d'approche est nette. Ces outils raisonnent en termes de tâche de développement et de fichiers ; forge raisonne en termes de validité d'un appel d'outil, indépendamment du domaine, et s'insère soit comme proxy, soit comme middleware. Si votre besoin est de coder, le harnais existant avec forge en proxy est le chemin le plus court. Si votre besoin est une boucle métier avec des outils que vous définissez, WorkflowRunner et son ContextManager budgété sont plus directs. Côté maintenance, le rythme de publication est soutenu : v0.9.3, v0.9.4 et v0.9.5 sont sorties en l'espace de quelques jours fin août 2026, avec des correctifs ciblés (propriété de commande du proxy, capture du raisonnement Anthropic, compatibilité de double authentification). Un rythme aussi serré signifie qu'il faut lire les notes de version avant de mettre à jour en production. La licence est MIT, ce qui autorise l'usage commercial et la modification ; le projet ne fournit aucun avis juridique et vous devez conserver la notice de licence. Le paquet s'appelle forge-guardrails sur PyPI, à ne pas confondre avec la commande forge-proxy de la distribution autonome.

Conclusion éditoriale

Adoptez forge si vous faites tourner un modèle local de 8B et que vos appels d'outils échouent sur des sorties malformées, en gardant en tête que l'évaluation à 84 % vient du jeu de tests du projet lui-même. Vérifiez d'abord que votre backend expose bien le template de chat attendu, puis lancez forge-proxy check avant de brancher un client existant.

Sources officielles

1. antoinezambelli/forge on GitHub
2. Issues
3. License: MIT
4. README
5. Releases