Gonka GitHub Mirror · Discussion #1095

Gonka AI x Kilo

Отдельная страница дискуссии с русским переводом и параллельным режимом RU / Original с точным сопоставлением предложений.

Как пользоваться: включите RU / Original и кликните по предложению — соответствующее предложение в другой колонке доскроллится и подсветится.
Discussion #1095

Gonka AI x Kilo

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

Dankosik avatar
DankosikАвтор
2026-04-21

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)

Русский перевод
Dankosik avatar
DankosikАвтор
2026-04-21

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)

Оригинал
Dankosik avatar
DankosikАвтор
2026-04-21

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.

Links

Project

Repository (https://github.com/GonkaGate/kilo-setup)

npm package (https://www.npmjs.com/package/@gonkagate/kilo-setup)

Issues and feedback (https://github.com/GonkaGate/kilo-setup/issues)

Changelog (https://github.com/GonkaGate/kilo-setup/blob/main/CHANGELOG.md)

GonkaGate website (https://gonkagate.com/en)

Get a GonkaGate API key (https://gonkagate.com/en/register)

GonkaGate docs (https://gonkagate.com/en/docs)

Docs

README (https://github.com/GonkaGate/kilo-setup/blob/main/README.md)

User guide (https://github.com/GonkaGate/kilo-setup/blob/main/docs/user-guide.md)

How it works (https://github.com/GonkaGate/kilo-setup/blob/main/docs/how-it-works.md)

Security notes (https://github.com/GonkaGate/kilo-setup/blob/main/docs/security.md)

Troubleshooting (https://github.com/GonkaGate/kilo-setup/blob/main/docs/troubleshooting.md)