Le plugin Keystone apprend à Claude Code à installer une passerelle LLM : 8 skills, des clés hors du chat

Si vous demandez à un agent d'« installer une passerelle LLM », il inventera avec aplomb des variables d'environnement qui n'existent pas, et vous passerez ensuite une heure à chercher pourquoi la configuration ne fonctionne pas. Une passerelle LLM est un point d'entrée unique par lequel tous vos services appellent OpenAI, Anthropic, Gemini et les autres fournisseurs : elle stocke les clés, choisit le modèle et bascule en cas de panne. Les auteurs de la passerelle self-hosted Keystone (KTMS, écrite en Go) ont réglé le problème par l'ingénierie plutôt que par des consignes dans le prompt.

Ils ont publié un plugin pour Claude Code avec 8 skills, c'est-à-dire des instructions prêtes à l'emploi qui connaissent les vraies commandes, les flags et les champs de configuration, ainsi qu'un serveur MCP par lequel l'agent voit ce qui est réellement en cours d'exécution. Les clés, elles, n'entrent pas dans le chat.

Ce que savent faire les 8 skills

L'installation tient en deux commandes : ajouter la marketplace ai-process/ktms, puis installer le plugin ktms@ai-process. Il faut par ailleurs le CLI ktms dans le PATH (depuis l'archive de la release ou via go install). La version du plugin correspond à celle de Keystone.

Les skills couvrent tout le parcours : assess (évaluation du système et verdict sur la nécessité d'une passerelle), deploy (Compose ou Helm, secrets, ordre du premier lancement), integrate (bascule des appels LLM d'un service vers la passerelle), configure (routage, clés et limites dans ktms.yaml, avec un plan des changements), migrate (migration depuis une autre passerelle ou depuis des appels directs aux SDK), node (nœud GPU local avec repli vers le cloud), usage-reports (coûts, rapports, alertes) et production-review (vérification avant et après la mise en production). Inutile de retenir les noms : l'agent choisit lui-même le skill adapté, et une commande slash permet de le lancer explicitement.

Pour que les skills ne deviennent pas obsolètes, la CI de Keystone lit chaque SKILL.md et échoue si celui-ci mentionne une commande, un flag, un outil MCP ou une section du README absents de cette version. Cela évite un travers classique : l'instruction cite un flag supprimé deux releases plus tôt, et l'agent se met à improviser.

À quoi cela ressemble sur un projet de démo

L'exemple comprend trois services : un bot de support sur le SDK OpenAI, un moteur de recherche sur le SDK Anthropic avec des embeddings OpenAI, et un worker nocturne qui appelle Gemini environ 40 000 fois par nuit. Le skill assess ne modifie rien : il trouve les cinq appels LLM, avec fichier et ligne, et relève ce qu'on ne lui avait pas demandé. Tous les services chargent le même env_file, si bien que chacun reçoit les trois clés des fournisseurs. La passerelle ignorera temperature=0.3 dans l'un des appels : il faut donc vérifier la qualité des réponses après la bascule. Le skill a aussi remarqué que rerank.ts ne réordonne rien et se contente d'expliquer les résultats.

Le verdict est honnête : la passerelle se justifie, mais si le système ne comptait que le bot de support sur gpt-4o, elle serait inutile. Le plan commence par le worker nocturne : c'est là que se concentrent l'essentiel des coûts et du risque, les utilisateurs ne voient pas l'appel, et une nuit ratée peut simplement être relancée.

Le skill integrate regroupe l'adresse, la clé, les timeouts, les retries et l'attribution des coûts dans un petit module client unique. Il remplace le modèle codé en dur par un niveau de complexité, accompagné d'une justification en une ligne : low pour la classification et les réponses courtes, medium pour la génération ordinaire, high pour le raisonnement et les longs documents. Il désactive les retries du SDK et implémente une seule fois le contrat d'erreurs : attendre Retry-After en cas de 429, temporiser en cas de 503, ne pas réessayer les erreurs de configuration.

La vérification finale s'appuie sur le routage réel : la commande ktms route explain (sortie de Keystone 1.3.6) affiche la chaîne de modèles.

Si elle se termine par le statut kept, tout va bien ; no_vendor_key signifie qu'il manque une clé, et on le voit avant même le déploiement du service.

Où passe la frontière de confiance

L'agent laisse volontairement la commande ktms init à l'humain : dans votre terminal, elle demande sans écho la clé d'administration et les clés des fournisseurs, écrit ktms.yaml avec les modèles et les règles par défaut, affiche le plan et l'applique.

Ensuite, configure fonctionne comme Terraform : modification, ktms config plan, présentation du plan à l'humain, application uniquement après accord. Les garde-fous sont intégrés aux outils, pas au prompt :

• le serveur MCP est en lecture seule par défaut, et les outils d'écriture n'apparaissent qu'avec le flag --allow-write ;
• config_plan renvoie un plan_id, et config_apply applique exactement ce plan, une seule fois, et refuse si la configuration a changé entre-temps ;
• la clé d'un fournisseur n'est lue que depuis les variables KTMS_VENDOR_KEY_*, si bien que l'agent ne peut pas glisser dans la configuration la clé d'administration ou un autre secret ;
• les noms et valeurs provenant de Keystone sont marqués comme des données, et non comme des instructions.

Limites et ce qu'il faut en retenir en pratique

C'est le plugin des auteurs de la passerelle eux-mêmes, et il ne fonctionne qu'avec Keystone. L'API de la passerelle, compatible OpenAI, ignore temperature, top_p, stop et seed, et les embeddings exigent l'identifiant exact du modèle : une partie des appels ne se transpose donc pas à l'identique. Les exemples proviennent d'un projet de démo, et non d'un environnement de production tiers.

La leçon dépasse la passerelle elle-même. Si vous voulez qu'un agent configure l'infrastructure, donnez-lui des skills vérifiés en CI par rapport à la version du produit, un MCP en lecture seule par défaut et un plan à valider plutôt qu'une écriture directe. Gardez les secrets pour l'humain. Les skills sont de simples Agent Skills, c'est-à-dire des dossiers contenant un SKILL.md : on peut donc les copier dans Codex, Cursor ou tout autre agent qui les lit, et y brancher deux serveurs MCP. Pour les assistants sans skills ni MCP, les mêmes instructions existent sous forme de prompts.