Gonka AI x Kilo
Оригинал: Gonka AI x Kilo

GonkaGate x Кило
Привет всем,
Мы собрали небольшую утилиту настройки для Kilo:
npx @gonkagate/kilo-setup
Цель проста. Если вы уже используете kilo и у вас уже есть ключ API GonkaGate, установка займет минуту или две. Это не должно превращаться в «откройте три вкладки документации, выясните, где Kilo хочет получить конфигурацию провайдера, а затем надейтесь, что вы случайно не оставили секрет в репозитории».
Для этого и нужен @gonkagate/kilo-setup.
Краткая версия: это небольшой CLI, который подключает локальный kilo к GonkaGate, сохраняет секрет в локальной конфигурации репо и проверяет полученный результат перед отправкой вас обратно в обычный kilo .
Почему мы это сделали
Ручную настройку поставщика можно выполнить один раз. После этого он быстро стареет.
Раздражает не сам API. Раздражает все вокруг: где должен находиться секрет, какому слою конфигурации что должно принадлежать, можно ли безопасно зафиксировать конфигурацию проекта и действительно ли Kilo использует конфигурацию, которую вы только что написали, вместо чего-то еще из текущей оболочки.
Нам нужен был короткий путь, который бы правильно выполнял скучную работу и оставался честным в отношении своих ограничений.
Краткая версия
Интерактивный
npx @gonkagate/kilo-setup
Неинтерактивный
С GONKAGATE_API_KEY:
GONKAGATE_API_KEY= " $GONKAGATE_API_KEY " npx @gonkagate/kilo-setup --scope project --yes
С стандартным вводом:
printf ' %s ' " $GONKAGATE_API_KEY " | npx @gonkagate/kilo-setup --api-key-stdin --scope project --yes
При очистке кэша на уровне проекта:
printf ' %s ' " $GONKAGATE_API_KEY " | npx @gonkagate/kilo-setup --api-key-stdin --scope project --clear-kilo-model-cache --yes
После установки
Вернитесь к простым килограммам.
килограмм
Что на самом деле делает установщик
На высоком уровне он делает четыре вещи:
- Выясняет местную ситуацию с Кило.
- Пишет минимально безопасный конфиг.
- Сохраняет секрет в области пользователя, а не в репозитории.
- Проверяет разрешенный результат вместо того, чтобы доверять записи в файл.
Более конкретно:
он обнаруживает килограмм или возвращается к килокоду
он поддерживает точный исследованный профиль Kilo: @kilocode/cli@7.2.0
он принимает ключ API через скрытую подсказку GONKAGATE_API_KEY или --api-key-stdin
он отклоняет простой --api-key
он хранит управляемый секрет в ~/.gonkagate/kilo/api-key
- он записывает определение провайдера.gonkagate на уровне пользователя и каноническую привязку {file:~/.gonkagate/kilo/api-key}
он автоматически выбирает рекомендуемую область действия
внутри репозитория git обычно это означает проект
вне репо, это обычно означает, что пользователь
- при повторных запусках он запрашивает область действия только тогда, когда предыдущая область, управляемая установщиком, больше не соответствует новой рекомендации.
в рамках проекта он записывает только настройки активации в .kilo/kilo.jsonc
он создает резервные копии отката перед заменой файлов, управляемых установщиком
- он сохраняет несвязанную конфигурацию Kilo там, где это возможно.
он проверяет устойчивый результат простого килограмма с помощью локального преобразователя
- если на текущую оболочку все еще влияют KILO_CONFIG, KILO_CONFIG_DIR или KILO_CONFIG_CONTENT, она сообщает об этом отдельно
- для установок проекта он также может очистить текущий глобальный кеш модели пользовательского интерфейса Kilo.
Последняя часть имеет большее значение, чем кажется. Записать конфигурацию легко. Правильно решенная конфигурация — это та часть, которая действительно имеет значение.
Пара важных для нас деталей
объем проекта намеренно узок. Репозиторий получает только активацию. Определение поставщика и секретная привязка остаются в конфигурации пользователя. Это по умолчанию обеспечивает безопасность коммитов .kilo/kilo.jsonc и позволяет избежать обычной проблемы «почему в git существует секретный путь».
Нам также не нужна была команда установки, которая с радостью распечатывала бы или распространяла секрет. Установщик не записывает в auth.json, не генерирует файлы .env и не трогает профили оболочки.
Другая важная часть — проверка. Среда выполнения рассматривает эффективную конфигурацию Kilo как настоящий залог успеха. Если длительная установка прошла успешно, но текущая оболочка по-прежнему переопределяется переменными окружения Kilo, предназначенными только для среды выполнения, инструмент говорит об этом, вместо того, чтобы притворяться, что все чисто.
Текущая модель и транспорт
Сейчас публичный дефолт намеренно небольшой:
пакет: @gonkagate/kilo-setup
идентификатор провайдера: gonkagate
базовый URL: https://api.gonkagate.com/v1
транспорт: чат/дополнения
проверенный профиль Kilo: точный @kilocode/cli@7.2.0
текущая проверенная модель: qwen/qwen3-235b-a22b-instruct-2507-fp8
управляемые лимиты: limit.context = 262144, limit.output = 8192
Мы рассматриваем поддержку моделей как тщательно подобранный список, а не как расплывчатое обещание «вероятно, это сработает».
На что мы не претендуем
Нынешние границы установлены намеренно:
никаких претензий в поддержку, кроме точного @kilocode/cli@7.2.0
сегодня нет поддержки /v1/responses
нет простого --api-key
нет генерации .env
нет редактирования профиля оболочки
нет прямой записи в auth.json
пока нет готовых к производству собственных заявлений Windows
не утверждаю, что одной только конфигурации проекта достаточно на новой машине
- не утверждается, что живая конфигурация отладки килограммов реального пути по пользовательским путям является верификатором по умолчанию для производства
Если поддержка /v1/responses появится позже, это должна быть настоящая миграция, а не то, что подразумевается в маркетинговом тексте.
Ссылки
Проект
Репозиторий (https://github.com/GonkaGate/kilo-setup)
пакет npm (https://www.npmjs.com/package/@gonkagate/kilo-setup)
Проблемы и отзывы (https://github.com/GonkaGate/kilo-setup/issues)
Журнал изменений (https://github.com/GonkaGate/kilo-setup/blob/main/CHANGELOG.md)
Сайт GonkaGate (https://gonkagate.com/en)
Получите ключ API GonkaGate (https://gonkagate.com/en/register)
Документация GonkaGate (https://gonkagate.com/en/docs)
Документы
README (https://github.com/GonkaGate/kilo-setup/blob/main/README.md)
Руководство пользователя (https://github.com/GonkaGate/kilo-setup/blob/main/docs/user-guide.md)
Как это работает (https://github.com/GonkaGate/kilo-setup/blob/main/docs/how-it-works.md)
Примечания по безопасности (https://github.com/GonkaGate/kilo-setup/blob/main/docs/security.md)
Устранение неполадок (https://github.com/GonkaGate/kilo-setup/blob/main/docs/troubleshooting.md)

GonkaGate x Kilo
Hi everyone,
We put together a small setup utility for Kilo:
npx @gonkagate/kilo-setup
The goal is simple. If you already use kilo and already have a GonkaGate API key, setup should take a minute or two. It should not turn into "open three docs tabs, figure out where Kilo wants provider config, then hope you didn't leave a secret in the repo by accident."
That is what @gonkagate/kilo-setup is for.
Short version: this is a small CLI that wires local kilo to GonkaGate, keeps the secret out of repo-local config, and verifies the resolved result before sending you back to plain kilo .
Why we made it
Manual provider setup is manageable once. It gets old fast after that.
The annoying part is not the API itself. The annoying part is everything around it: where the secret should live, which config layer should own what, whether project config is safe to commit, and whether Kilo is actually using the config you just wrote instead of something else from the current shell.
We wanted a short path that does the boring work correctly and stays honest about its limits.
The short version
Interactive
npx @gonkagate/kilo-setup
Non-interactive
With GONKAGATE_API_KEY :
GONKAGATE_API_KEY= " $GONKAGATE_API_KEY " npx @gonkagate/kilo-setup --scope project --yes
With stdin:
printf ' %s ' " $GONKAGATE_API_KEY " | npx @gonkagate/kilo-setup --api-key-stdin --scope project --yes
With project-scope cache cleanup:
printf ' %s ' " $GONKAGATE_API_KEY " | npx @gonkagate/kilo-setup --api-key-stdin --scope project --clear-kilo-model-cache --yes
After setup
Go back to plain kilo .
kilo
What the installer actually does
At a high level, it does four things:
- Figures out the local Kilo situation.
- Writes the minimum safe config.
- Keeps the secret in user scope, not in the repository.
- Verifies the resolved result instead of trusting file writes.
More concretely:
it detects kilo , or falls back to kilocode
it supports the exact investigated Kilo profile: @kilocode/cli@7.2.0
it accepts the API key through a hidden prompt, GONKAGATE_API_KEY , or --api-key-stdin
it rejects plain --api-key
it stores the managed secret at ~/.gonkagate/kilo/api-key
it writes the user-level provider.gonkagate definition and canonical {file:~/.gonkagate/kilo/api-key} binding
it chooses the recommended scope automatically
inside a git repo, that usually means project
outside a repo, that usually means user
on reruns, it only asks about scope when the previous installer-managed scope no longer matches the new recommendation
in project scope, it writes only activation settings into .kilo/kilo.jsonc
it creates rollback backups before replacing installer-managed files
it preserves unrelated Kilo config where it can
it verifies the durable plain- kilo result with the local resolver
- if the current shell is still affected by KILO_CONFIG , KILO_CONFIG_DIR , or KILO_CONFIG_CONTENT , it reports that separately
for project installs, it can also clear Kilo's current global UI-model cache
That last part matters more than it sounds. A config write is easy. A correct resolved config is the part that actually counts.
A couple of details that mattered to us
project scope is intentionally narrow. The repository gets activation only. The provider definition and secret binding stay in user config. That keeps .kilo/kilo.jsonc commit-safe by default and avoids the usual "why is there a secret-related path in git" problem.
We also did not want a setup command that happily prints or spreads the secret around. The installer does not write to auth.json , does not generate .env files, and does not touch shell profiles.
The other important part is verification. The runtime treats effective Kilo config as the real success gate. If the durable install is fine but the current shell is still overridden by runtime-only Kilo env vars, the tool says so instead of pretending everything is clean.
Current model and transport
Right now the public default is deliberately small:
package: @gonkagate/kilo-setup
provider id: gonkagate
base URL: https://api.gonkagate.com/v1
transport: chat/completions
validated Kilo profile: exact @kilocode/cli@7.2.0
current validated model: qwen/qwen3-235b-a22b-instruct-2507-fp8
managed limits: limit.context = 262144 , limit.output = 8192
We are treating model support as a curated list, not as a vague "it probably works" promise.
What we are not claiming
The current boundaries are deliberate:
no support claim beyond exact @kilocode/cli@7.2.0
no /v1/responses support today
no plain --api-key
no .env generation
no shell profile edits
no direct writes to auth.json
no production-ready native Windows claim yet
no claim that project config alone is enough on a brand-new machine
no claim that live real-path kilo debug config against user paths is the production default verifier
If /v1/responses support shows up later, that should be a real migration, not something implied by marketing copy.
GonkaGate x Кило
Привет всем,
Мы собрали небольшую утилиту настройки для Kilo:
npx @gonkagate/kilo-setup
Цель проста. Если вы уже используете kilo и у вас уже есть ключ API GonkaGate, установка займет минуту или две. Это не должно превращаться в «откройте три вкладки документации, выясните, где Kilo хочет получить конфигурацию провайдера, а затем надейтесь, что вы случайно не оставили секрет в репозитории».
Для этого и нужен @gonkagate/kilo-setup.
Почему мы это сделали
Ручную настройку поставщика можно выполнить один раз. После этого он быстро стареет.
Раздражает не сам API. Раздражает все вокруг: где должен находиться секрет, какому слою конфигурации что должно принадлежать, можно ли безопасно зафиксировать конфигурацию проекта и действительно ли Kilo использует конфигурацию, которую вы только что написали, вместо чего-то еще из текущей оболочки.
Нам нужен был короткий путь, который бы правильно выполнял скучную работу и оставался честным в отношении своих ограничений.
Краткая версия
Интерактивный
npx @gonkagate/kilo-setup
Неинтерактивный
С GONKAGATE_API_KEY:
GONKAGATE_API_KEY= " $GONKAGATE_API_KEY " npx @gonkagate/kilo-setup --scope project --yes
С стандартным вводом:
printf ' %s ' " $GONKAGATE_API_KEY " | npx @gonkagate/kilo-setup --api-key-stdin --scope project --yesПри очистке кэша на уровне проекта:
printf ' %s ' " $GONKAGATE_API_KEY " | npx @gonkagate/kilo-setup --api-key-stdin --scope project --clear-kilo-model-cache --yesПосле установки
Вернитесь к простым килограммам.
килограмм
Что на самом деле делает установщик
На высоком уровне он делает четыре вещи:
Более конкретно:
он обнаруживает килограмм или возвращается к килокоду
он поддерживает точный исследованный профиль Kilo: @kilocode/cli@7.2.0
он принимает ключ API через скрытую подсказку GONKAGATE_API_KEY или --api-key-stdin
он отклоняет простой --api-key
он хранит управляемый секрет в ~/.gonkagate/kilo/api-key
он автоматически выбирает рекомендуемую область действия
внутри репозитория git обычно это означает проект
вне репо, это обычно означает, что пользователь
в рамках проекта он записывает только настройки активации в .kilo/kilo.jsonc
он создает резервные копии отката перед заменой файлов, управляемых установщиком
он проверяет устойчивый результат простого килограмма с помощью локального преобразователя
Последняя часть имеет большее значение, чем кажется. Записать конфигурацию легко. Правильно решенная конфигурация — это та часть, которая действительно имеет значение.
Пара важных для нас деталей
объем проекта намеренно узок. Репозиторий получает только активацию. Определение поставщика и секретная привязка остаются в конфигурации пользователя. Это по умолчанию обеспечивает безопасность коммитов .kilo/kilo.jsonc и позволяет избежать обычной проблемы «почему в git существует секретный путь».
Нам также не нужна была команда установки, которая с радостью распечатывала бы или распространяла секрет. Установщик не записывает в auth.json, не генерирует файлы .env и не трогает профили оболочки.
Другая важная часть — проверка. Среда выполнения рассматривает эффективную конфигурацию Kilo как настоящий залог успеха. Если длительная установка прошла успешно, но текущая оболочка по-прежнему переопределяется переменными окружения Kilo, предназначенными только для среды выполнения, инструмент говорит об этом, вместо того, чтобы притворяться, что все чисто.
Текущая модель и транспорт
Сейчас публичный дефолт намеренно небольшой:
пакет: @gonkagate/kilo-setup
идентификатор провайдера: gonkagate
базовый URL: https://api.gonkagate.com/v1
транспорт: чат/дополнения
проверенный профиль Kilo: точный @kilocode/cli@7.2.0
текущая проверенная модель: qwen/qwen3-235b-a22b-instruct-2507-fp8
управляемые лимиты: limit.context = 262144, limit.output = 8192
Мы рассматриваем поддержку моделей как тщательно подобранный список, а не как расплывчатое обещание «вероятно, это сработает».
На что мы не претендуем
Нынешние границы установлены намеренно:
никаких претензий в поддержку, кроме точного @kilocode/cli@7.2.0
сегодня нет поддержки /v1/responses
нет простого --api-key
нет генерации .env
нет редактирования профиля оболочки
нет прямой записи в auth.json
пока нет готовых к производству собственных заявлений Windows
не утверждаю, что одной только конфигурации проекта достаточно на новой машине
Если поддержка /v1/responses появится позже, это должна быть настоящая миграция, а не то, что подразумевается в маркетинговом тексте.
Ссылки
Проект
Репозиторий (https://github.com/GonkaGate/kilo-setup)
пакет npm (https://www.npmjs.com/package/@gonkagate/kilo-setup)
Проблемы и отзывы (https://github.com/GonkaGate/kilo-setup/issues)
Журнал изменений (https://github.com/GonkaGate/kilo-setup/blob/main/CHANGELOG.md)
Сайт GonkaGate (https://gonkagate.com/en)
Получите ключ API GonkaGate (https://gonkagate.com/en/register)
Документация GonkaGate (https://gonkagate.com/en/docs)
Документы
README (https://github.com/GonkaGate/kilo-setup/blob/main/README.md)
Руководство пользователя (https://github.com/GonkaGate/kilo-setup/blob/main/docs/user-guide.md)
Как это работает (https://github.com/GonkaGate/kilo-setup/blob/main/docs/how-it-works.md)
Примечания по безопасности (https://github.com/GonkaGate/kilo-setup/blob/main/docs/security.md)
Устранение неполадок (https://github.com/GonkaGate/kilo-setup/blob/main/docs/troubleshooting.md)