El plugin de Keystone enseña a Claude Code a instalar un gateway de LLM: 8 skills y claves fuera del chat

Si le pides a un agente «instálanos un gateway de LLM», inventará con total seguridad variables de entorno que no existen, y luego pasarás una hora buscando por qué no funciona la configuración. Un gateway de LLM es un único punto por el que todos tus servicios acceden a OpenAI, Anthropic, Gemini y otros proveedores: guarda las claves, elige el modelo y conmuta cuando hay fallos. Los autores de Keystone (KTMS, escrito en Go), un gateway self-hosted, no atacaron el problema con persuasión en el prompt, sino con ingeniería.

Lanzaron un plugin para Claude Code con 8 skills, es decir, instrucciones ya preparadas que conocen los comandos, flags y campos de configuración reales, y un servidor MCP a través del cual el agente ve qué está en ejecución. Las claves, además, no llegan al chat.

Qué hacen los 8 skills

La instalación requiere dos comandos: añadir el marketplace ai-process/ktms e instalar el plugin ktms@ai-process. Aparte, hace falta el CLI ktms en el PATH (desde el archivo de la release o mediante go install). La versión del plugin coincide con la de Keystone.

Los skills cubren todo el recorrido: assess (evaluación del sistema y veredicto sobre si hace falta un gateway), deploy (Compose o Helm, secretos, orden del primer arranque), integrate (migrar las llamadas a LLM de un servicio al gateway), configure (enrutamiento, claves y límites en ktms.yaml, con un plan de cambios), migrate (paso desde otro gateway o desde llamadas directas al SDK), node (nodo GPU local con fallback a la nube), usage-reports (gastos, informes, alertas) y production-review (revisión antes y después del lanzamiento). No hace falta memorizar los nombres: el agente elige por sí mismo el skill adecuado, y un comando slash lo lanza de forma explícita.

Para que los skills no se queden obsoletos, el CI de Keystone lee cada SKILL.md y falla si menciona un comando, un flag, una herramienta MCP o una sección del README que no existen en esa versión. Esto evita un problema habitual: la instrucción nombra un flag eliminado hace dos releases y el agente empieza a improvisar.

Cómo se ve en un proyecto de demostración

El ejemplo tiene tres servicios: un bot de soporte con el SDK de OpenAI, un buscador con el SDK de Anthropic y embeddings de OpenAI, y un worker nocturno que llama a Gemini unas 40 000 veces por noche. El skill assess no cambia nada: encuentra las cinco llamadas a LLM, con archivo y línea, y detecta cosas por las que nadie había preguntado. Todos los servicios cargan un env_file común, así que cada uno recibe las tres claves de los proveedores.

El parámetro temperature=0.3 de una de las llamadas lo ignorará el gateway, por lo que hay que comprobar la calidad de las respuestas tras el cambio. El skill también observó que rerank.

ts no reordena nada, solo explica los resultados.

El veredicto es honesto: el gateway se justifica, pero si el sistema solo tuviera el bot de soporte con gpt-4o, no haría falta. El plan empieza por el worker nocturno: ahí está la mayor parte del gasto y del riesgo, los usuarios no ven la llamada y una noche fallida se puede simplemente reiniciar.

El skill integrate reúne la dirección, la clave, los timeouts, los reintentos y la atribución de gastos en un pequeño módulo de cliente. Sustituye el modelo fijado en el código por un nivel de complejidad con una justificación de una línea: low para clasificación y respuestas cortas, medium para generación habitual, high para razonamiento y documentos largos. Desactiva los reintentos del SDK e implementa una sola vez el contrato de errores: esperar Retry-After ante un 429, retroceder ante un 503 y no repetir los errores de configuración.

La verificación final se hace sobre el enrutamiento real: el comando ktms route explain (salida de Keystone 1.3.6) muestra la cadena de modelos.

Si termina con el estado kept, todo está en orden; no_vendor_key significa que falta una clave, y eso se ve antes de desplegar el servicio.

Dónde está el límite de la confianza

El comando ktms init el agente lo deja a propósito en manos de la persona: en tu terminal pide, sin eco, la clave de administrador y las claves de los proveedores, escribe ktms.yaml con los modelos y las reglas por defecto, muestra el plan y lo aplica.

A partir de ahí, configure funciona como Terraform: edición, ktms config plan, plan mostrado a la persona y aplicación solo tras su aprobación. Las restricciones están integradas en las herramientas, no en el prompt:

• el servidor MCP solo lee por defecto; las herramientas de escritura aparecen con el flag --allow-write;
• config_plan devuelve un plan_id, y config_apply aplica exactamente ese plan una sola vez y lo rechaza si la configuración ha cambiado entretanto;
• la clave del proveedor se toma únicamente de las variables KTMS_VENDOR_KEY_*, por lo que el agente no puede colar en la configuración la clave de administrador ni otro secreto;
• los nombres y valores que llegan desde Keystone se marcan como datos, no como instrucciones.

Limitaciones y qué llevarse a la práctica

Es un plugin de los propios autores del gateway y funciona solo con Keystone. La API del gateway, compatible con OpenAI, ignora temperature, top_p, stop y seed, y los embeddings necesitan el id exacto del modelo, de modo que parte de las llamadas no se migra de forma idéntica. Los ejemplos se obtuvieron en un proyecto de demostración, no en producción ajena.

La lección va más allá del propio gateway. Si quieres que un agente configure infraestructura, dale skills verificados en el CI contra la versión del producto, MCP en modo lectura por defecto y un plan con confirmación en lugar de escritura directa. Los secretos, déjalos a la persona. Los skills son Agent Skills estándar, es decir, carpetas con SKILL.md, así que se pueden copiar a Codex, Cursor u otro agente que los lea, y conectar los dos servidores MCP. Para asistentes sin skills ni MCP, las mismas instrucciones están disponibles como prompts.