opencode

opencode читает провайдеров из объединённых JSON-слоёв конфигурации, а не из переменных окружения, поэтому здесь нет слота вроде ANTHROPIC_BASE_URL, который можно просто подменить. ocx opencode закрывает этот пробел: он убеждается, что прокси запущен, строит блок провайдера из видимого каталога и внедряет его через inline runtime layer OpenCode (OPENCODE_CONFIG_CONTENT).

Быстрый старт

ocx opencode

Команда убеждается, что прокси запущен, и запускает opencode, внедряя для этого процесса только сгенерированный блок provider.opencodex. Дополнительные аргументы передаются дальше: ocx opencode run "hello".

Маршрутизируемые модели появляются в picker под провайдером opencodex:

opencodex/kiro/glm-5
opencodex/gpt-5.6-sol      # native slugs stay unprefixed

Ваша собственная конфигурация никогда не меняется

Лончер не копирует и не переписывает ~/.config/opencode/opencode.json, проектные opencode.json / opencode.jsonc и любые другие конфигурационные слои на диске. Он может читать глобальную или проектную конфигурацию, чтобы обнаружить override provider.opencodex, но ваши существующие провайдеры, агенты, keybind’ы, записи MCP и относительные ссылки {file:…} продолжают разрешаться из исходных файлов.

Только для этого запуска opencodex добавляет сгенерированный блок provider.opencodex через inline runtime layer OpenCode. Этот слой сливается после глобальной/custom/project-конфигурации и переопределяет только конфликтующие ключи дочернего процесса.

Слой	Поведение с `ocx opencode`
Global / custom / project config	Остаётся на диске ровно в том виде, в каком вы её записали
Inline runtime (`OPENCODE_CONFIG_CONTENT`)	Получает только сгенерированный блок `provider.opencodex`
Relative `{file:…}` paths	Всё так же разрешаются относительно конфигурационного файла, где были определены

Если глобальная или проектная конфигурация тоже определяет provider.opencodex, лончер печатает информационное замечание: runtime layer из ocx opencode переопределяет её только для этого запуска.

Как перенести блок в свою конфигурацию

ocx opencode внедряет блок провайдера только на один запуск, поэтому обычный opencode по-прежнему ничего не знает о прокси. Если вы хотите, чтобы маршрутизируемые модели были доступны и из обычного opencode — либо из расширения редактора, которое никогда не проходит через этот лончер, — ocx export напечатает тот же блок провайдера, чтобы вы сами слили его в свою конфигурацию:

ocx export --client opencode

Прокси должен быть запущен. Команда печатает конфиг, канонический путь назначения (~/.config/opencode/opencode.json, либо каталог под XDG_CONFIG_HOME, если он задан), предупреждение о merge и строку export для переменной окружения. Она никогда не трогает этот файл — всё сказанное выше остаётся верным, и перенос блока в вашу конфигурацию является именно вашим действием.

Слейте блок provider.opencodex со своей существующей конфигурацией. Если заменить им весь файл, вы уничтожите остальные провайдеры, агенты, keybind’ы и записи MCP. Именно поэтому ocx export --out отказывается перезаписывать существующий файл, так что указывайте --out на временный путь и потом переносите только нужный блок:

ocx export --client opencode --out ~/opencodex-opencode.json

В отличие от runtime-блока лончера, слитый блок — это статический снимок: он не следует за вашим каталогом. После добавления провайдера или изменения видимости моделей заново выполните ocx export.

После merge экспортируйте admission key перед запуском opencode — если только прокси не работает на loopback, где ключ не нужен:

export OPENCODEX_OPENCODE_API_KEY=<your key>

Admission key не пишется на диск

Когда прокси требует API-ключ, inline runtime config содержит ссылку {env:…} opencode, а не сам секрет. На loopback эта ссылка используется как apiKey; на не-loopback привязке она уходит только через x-opencodex-api-key, чтобы admission прокси оставался отделённым от любого upstream-заголовка Authorization.

Пример для loopback:

"options": {
  "baseURL": "http://127.0.0.1:10100/v1",
  "apiKey": "{env:OPENCODEX_OPENCODE_API_KEY}"
}

Пример для не-loopback:

"options": {
  "baseURL": "http://192.168.1.10:10100/v1",
  "headers": {
    "x-opencodex-api-key": "{env:OPENCODEX_OPENCODE_API_KEY}"
  }
}

Реальное значение передаётся только через окружение дочернего процесса. OPENCODEX_API_AUTH_TOKEN имеет приоритет, затем идёт hardened service token file, затем настроенный API key — именно он требуется для не-loopback-привязки.

Loopback-привязка (127.0.0.1, по умолчанию) не требует аутентификации, поэтому ссылка {env:…} остаётся инертной, и переменную можно не задавать. Она важна только когда hostname выходит за пределы loopback; см. Удалённый доступ. Этот admission key относится к самому opencodex и не связан с upstream-ключами провайдеров, настраиваемыми в Провайдерах.

Откат

Откатывать нечего — под ~/.opencodex никакой сгенерированный конфиг-файл не создаётся. Запустите обычный opencode, и он прочитает вашу собственную конфигурацию ровно в прежнем виде.

Ограничения по моделям

limit.context записывается только тогда, когда каталог сообщает авторитетное контекстное окно; если нет, весь блок limit опускается, и opencode использует собственные значения по умолчанию.

Схема opencode отвергает блок limit, в котором есть context, но нет output, а в каталоге нет авторитетного per-model поля output, поэтому рядом записывается output с бюджетом 32000, ограниченным сверху значением context window, чтобы у модели с маленьким контекстом никогда не получалось output > context. Эта цифра существует только для удовлетворения схемы — она не утверждает ничего о реальном максимуме какой-либо модели.

Блок провайдера opencodex пересобирается при каждом запуске, поэтому внесённые вами правки внутри него не сохранятся. Для пользовательских записей держите отдельный provider key.

Требования

opencode должен быть установлен и доступен в PATH:

npm install -g opencode-ai