Claude получил плагин Keystone для установки LLM-шлюза
Keystone выпустил плагин для Claude Code, который помогает поставить self-hosted LLM-шлюз без угадывания переменных и флагов. Для разработчиков и DevOps это способ быстрее подключить сервисы к одному шлюзу и не светить ключи в чате.
Что умеет плагин для Claude Code
Keystone сделал для Claude Code плагин из восьми скиллов и MCP-сервера. Идея простая: агент не придумывает команды и переменные окружения, а опирается на реальные команды, флаги и поля конфига Keystone.
Это особенно полезно, когда нужно быстро развернуть LLM-шлюз в рабочем проекте. Агент может подсказать, с чего начать, как выбрать между Compose и Helm, где хранить секреты, как настроить первый запуск и как перевести сервисы с прямых SDK-вызовов на шлюз.
Зачем вообще нужен Keystone
Keystone, или KTMS, — это self-hosted LLM-шлюз на Go. Он даёт сервисам одну точку входа для работы с моделями, хранит ключи вендоров, выбирает модель по правилам, умеет переключаться при сбоях и помогает держать расходы под контролем.
Для команды это означает меньше хаоса в коде и конфигурации: ключи не размазаны по нескольким сервисам, правила маршрутизации собраны в одном месте, а изменения можно планировать и проверять до выката. Это особенно удобно, если у вас микросервисы, несколько провайдеров и разные лимиты по бюджету.
Как это выглядит на практике
В статье показан демо-проект с тремя сервисами: бот поддержки на OpenAI SDK с моделью gpt-4o в двух местах, поисковый сервис на Anthropic SDK с эмбеддингами OpenAI и ночной воркер, который обращается к Gemini около 40 000 раз за ночь. В составе уже были Postgres, Redis и Prometheus.
Сначала команда /ktms:assess просто читает код и деплой, находит все LLM-вызовы с файлами и строками и пишет, что именно изменится после подключения Keystone. В примере он заметил, что все три vendor keys попадают в каждый сервис через env_file, а ещё выделил ночной воркер как главный источник расходов и риска.
Дальше /ktms:deploy помогает подготовить конфиг без передачи ключей в чат. Один шаг всё же остаётся за человеком: ktms init запускают в своём терминале, чтобы ключи вендоров и админский ключ не попадали в переписку. Потом /ktms:configure работает с файлом ktms.yaml почти как Terraform: сначала план, потом согласование, и только после этого применение.
Есть и /ktms:integrate — он собирает клиентский модуль с адресом, ключом, таймаутами, ретраями и атрибуцией. Важная деталь: Keystone сразу показывает, что часть параметров OpenAI-совместимый API не учитывает, например temperature, top_p, stop и seed. Это помогает не ловить сюрпризы после миграции.
Кому это пригодится
Плагин будет полезен разработчикам, DevOps-специалистам, тимлидам и владельцам небольших команд, где уже есть несколько сервисов и разные модели. Он экономит время на ручной настройке и снижает риск ошибок, когда агент начинает импровизировать вместо того, чтобы следовать реальным командам.
В статье Keystone отдельно подчёркивает: если у вас один сервис, одна модель и нет лимитов расходов, шлюз может быть лишним. Но если есть несколько провайдеров, ночные батчи, лимиты и необходимость быстро понять, что именно ломается, такой слой контроля может окупиться довольно быстро.