opencode

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

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

ocx opencode

Команда убеждается, что прокси запущен, и запускает opencode, внедряя для этого процесса только сгенерированные блоки provider.opencodex и providers.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 или providers.opencodex, но ваши существующие провайдеры, агенты, keybind’ы, записи MCP и относительные ссылки {file:…} продолжают разрешаться из исходных файлов.

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

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

Если глобальная или проектная конфигурация тоже определяет provider.opencodex или providers.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 и providers.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 использует собственные значения по умолчанию.

Лимит вывода берётся из каталога или сгенерированных метаданных модели. Значение 32000 используется только при неизвестном лимите. Лимит всегда ограничен окном контекста; известные значения ниже 32000 сохраняются.

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

Требования

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

npm install -g opencode-ai