Интеграции

Вкладка Подключение записывает блок провайдера opencodex в собственный файл конфигурации клиента и при необходимости удаляет его. Так работают следующие клиенты, у каждого свой переключатель:

В Windows переопределение, требующее абсолютного пути, должно содержать букву диска (C:\Users\me\client) или ресурс UNC (\\server\share\client). Формы \Users\me\client и /client/config отклоняются, поскольку зависят от текущего диска. Селекторы с документированной поддержкой ~ раскрывают его относительно действующего домашнего каталога; Gentle Shell не раскрывает ~.

Клиент	Файл конфигурации	Формат	Когда изменение начинает действовать	Учётные данные
OpenCode	~/.config/opencode/opencode.json	JSON	при следующем прямом запуске	OPENCODEX_OPENCODE_API_KEY
Pi	~/.pi/agent/models.json	JSON	в новых сессиях	заглушка для loopback
OMP	~/.omp/agent/models.yml	YAML	после перезапуска OMP	заглушка opencodex-loopback
Hermes	~/.hermes/config.yaml	YAML	в новых сессиях	OPENCODEX_HERMES_API_KEY
OpenClaw	~/.openclaw/openclaw.json	JSON5	сразу на работающем шлюзе	OPENCODEX_OPENCLAW_API_KEY
Kimi Code	~/.kimi-code/config.toml	TOML	после перезапуска или /reload	заглушка для loopback
gjc	~/.gjc/agent/models.yml	YAML	в новых сессиях или при открытии /model	несекретная заглушка для loopback
DeepSeek Harness (DSH)	$DSH_HOME/profiles/desktop/cordis.patch.yml (по умолчанию ~/.dsh/profiles/desktop/cordis.patch.yml); $DSH_HOME/settings.yaml, пока DSH Desktop не создал этот профиль	YAML	горячая перезагрузка	несекретная bearer-заглушка для loopback
MiniMax Code	~/.minimax/config.yaml	YAML	в новых сессиях или после открытия выбора модели	заглушка для loopback
Prime Agent	~/.prime/agent/models.json	JSON	в новых сессиях	заглушка для loopback
ZCode	~/.zcode/v2/provider_config.json (schemaVersion 1); резервный путь старого формата: ~/.zcode/v2/config.json	JSON	после перезапуска	заглушка для loopback
Aside	~/.aside/u/<account>/models.json	JSON	после полного закрытия и повторного открытия Aside	заглушка для loopback
Raycast	~/.config/raycast/ai/providers.yaml	YAML	сразу после сохранения — Raycast следит за файлом	нет — только loopback
omo	~/.omo/agent/models.json	JSON	в новых сессиях	заглушка для loopback
Cline CLI	~/.cline/data/settings/providers.json и соседний models.json	пара JSON	после остановки и повторного запуска Cline	заглушка для loopback
Kilo	первый существующий файл среди kilo.jsonc, kilo.json, opencode.jsonc, opencode.json и config.json в ~/.config/kilo (XDG_CONFIG_HOME переносит каталог; если файлов нет, создаётся kilo.jsonc)	JSONC	в новых сессиях	OPENCODEX_KILO_API_KEY
Command Code	~/.commandcode/providers.json (в Windows при использовании домашнего каталога по умолчанию: использовать HOME ?? USERPROFILE, только если значение не пустое, не состоит из пробелов и является абсолютным путём Windows, иначе homedir(); отдельно переданный домашний каталог сохраняется; добавить .commandcode\providers.json)	JSON	при следующем запуске Command Code	нет — loopback без ключа (apiKey: false)
Factory Droid	~/.factory/settings.json (%USERPROFILE%\.factory\settings.json в Windows)	JSON	сразу при изменении файла	loopback без ключа

Создаваемые каталоги включают только модели, включённые в настройках каждого провайдера. Это относится и к скачиваемым файлам, и к управляемым интеграциям, включая Pi и Aside. Список моделей управления по-прежнему показывает все модели, чтобы можно было включить дополнительные.

Для встроенных пресетов Gajae храните выбор маршрутизации в ~/.gjc/agent/config.yml:

modelProfile:
  proxyProvider: opencodex
  proxyMode: always

Сохраните выбранный modelProfile.default, чтобы он применялся при обычном запуске gjc. Управляемой интеграции принадлежит только providers.opencodex в models.yml; обновление или отключение провайдера не переписывает выбор пресета. После изменения экспортируемого набора моделей обновите интеграцию.

Модели GJC с поддерживаемыми уровнями усилия рассуждения экспортируют reasoning: true, thinking.levels и compat.supportsReasoningEffort, чтобы в GJC можно было выбрать уровень. Нативные модели Codex получают стандартные уровни, даже если каталог их не указывает. Без известных уровней эти поля не выводятся. none не отправляет уровень, а ultra при отправке становится max, поэтому их не предлагают. Обновите интеграцию, чтобы обновить параметры моделей.

Управляемой интеграции OpenCode принадлежат два фрагмента: provider.opencodex (opencode V1) и providers.opencodex (opencode V2). Оба блока несут одни и те же объявленные варианты effort и значения по умолчанию для каждой модели: в устаревшем блоке это значение по умолчанию в options модели и карта вариантов, в блоке V2 — settings модели и собственный массив вариантов, поэтому оба фрагмента записываются и поддерживаются синхронно. Они называют одни и те же id провайдера и моделей, а opencode V2 объединяет их в одну запись провайдера. Apply, Refresh, Disable и Restore действуют на оба фрагмента; другие ваши провайдеры, агенты, сочетания клавиш и записи MCP остаются без изменений. Оба фрагмента строятся из фактических канонических метаданных моделей — как и экспорт Kilo и запускатель ocx opencode. Явное пользовательское переопределение всегда выигрывает, а очищенная лестница остаётся пустой; лестница или значение по умолчанию никогда не выдумываются для модели, которая их не объявляет. Достоверный лимит контекста переносится вместе с лимитом выхода: известное значение выхода — явное или из метаданных каталога — выигрывает, иначе применяется обязательный по схеме запасной лимит 32000, ограниченный контекстом; без достоверного контекста весь блок limit опускается. Возможности, лестницы effort, значения по умолчанию и необязательный лимит входа записываются только известными. Собственный объект capabilities блока V2 требует известного значения tools, поэтому при неизвестной поддержке инструментов он опускается целиком, а не частично; объявления модальностей в устаревшем блоке остаются. Вместо выдуманной лестницы пишутся только элементы управления: блок V2 всегда несёт явный массив вариантов — пустой, если ничего не объявлено, потому что его отсутствие заставило бы OpenCode синтезировать low/medium/high, — а модель с известной фиксированной рассуждающей способностью, но без регулируемой лестницы получает вместо effort только неактивное подавление: и устаревший блок OpenCode, и Kilo отключают каждый id ступени, который клиент иначе сгенерировал бы. Ни один из них не добавляет выбираемый effort. Выбираемые варианты могут переопределить значение effort по умолчанию — включая none, и только если лестница самой модели его объявляет. Что бы ни выбрал клиент, закреплённая политика effort на прокси по-прежнему применяется к уходящему запросу.

Управляемая поддержка DSH требует как минимум DSH 0.1.0-rc.6. DSH 0.1.7 и новее читает маршруты из патча профиля Desktop, $DSH_HOME/profiles/desktop/cordis.patch.yml, и подхватывает изменения без перезапуска. Если профиль Desktop и его патч существуют, OpenCodex записывает только строку [id=llm-pi-ai].config.providers.opencodex. Если $DSH_HOME/profiles/desktop/package.json существует, но cordis.patch.yml отсутствует, Apply отказывает: создайте cordis.patch.yml с содержимым [] (пустой патч, который DSH записывает для нового профиля), затем снова включите интеграцию. Только при отсутствии профиля Desktop используется резервный вариант: llm-pi-ai.providers.opencodex в $DSH_HOME/settings.yaml. Apply и Refresh заменяют этот фрагмент, Disable удаляет только его, а Restore возвращает записанный снимок. Эти действия не меняют модель пользователя по умолчанию и нативного провайдера deepseek-official. Управляемая интеграция DSH пока работает только через loopback и никогда не записывает настоящие учётные данные.

MiniMax Code сначала учитывает MINIMAX_DATA_DIR, затем MAVIS_DATA_DIR, и лишь после этого использует ~/.minimax. Управляемому блоку принадлежит только custom_provider.opencodex. Он не меняет defaultModel, выбранный источник учётных данных MiniMax или вход пользователя в MiniMax. После подключения выберите в MCode запись custom_provider:opencodex/<provider/model>. Обновление интеграции также обновляет достоверные контекстные окна и варианты effort каждой модели; неизвестные возможности опускаются, а текущий effort, принадлежащий сессии MCode, сохраняется.

Prime Agent сначала учитывает PRIME_AGENT_CODING_AGENT_DIR, затем использует ~/.prime/agent. Относительное значение отклоняется, чтобы прокси и агент не разошлись во мнении о нужном файле. Управляемому блоку принадлежит только providers.opencodex, поэтому другие провайдеры и заданные вами modelOverrides не меняются. Prime Agent читает models.json при запуске сессии, так что после подключения начните новую сессию.

Aside хранит отдельный каталог моделей для каждого зарегистрированного профиля, в том числе локального. OpenCodex перечисляет все зарегистрированные профили, включая локальные, и может синхронизировать их вместе либо управлять одним за раз. Переключение интеграции никогда не меняет активный аккаунт Aside. После прежнего подключения Aside все профили включены по умолчанию; отдельные исключения сохраняются при последующих синхронизациях.

У Aside есть особенность: работающее приложение само переписывает models.json, поэтому после применения полностью закройте и снова откройте Aside, как при перезапуске Claude Desktop. Блок Aside работает только через loopback и никогда не содержит настоящих учётных данных.

Управляемая интеграция Raycast поддерживает macOS и Windows. Custom Providers — возможность Raycast Pro: на бесплатном плане файл тоже записывается, но ocx integration client status --client raycast и страница Подключение предупреждают, что Raycast его не прочитает. На macOS или Windows откройте Raycast → Settings → AI → Reveal Providers Config один раз, чтобы создался каталог ai. На поддерживаемых платформах opencodex использует этот каталог как признак установки и считает клиент неустановленным, пока каталога нет. Linux не поддерживается, даже если каталог существует.

Поле состояния aiDirPresent сообщает только о существовании ~/.config/raycast/ai, независимо от установки Raycast и поддержки платформы. Оно не доказывает, что Raycast установлен или пригоден к работе. CLI выводит plan отдельной строкой и добавляет инструкцию для macOS/Windows, когда aiDirPresent равно false; --json сохраняет исходное состояние, включая вложенный блок raycast. И на macOS, и на Windows Raycast читает ~/.config/raycast/ai/providers.yaml и не учитывает XDG_CONFIG_HOME, поэтому путь нельзя перенести.

Управляемый блок — один элемент id: opencodex в последовательности providers файла: name: OpenCodex, base_url: http://<host>:<port>/v1 и все маршрутизируемые модели с их abilities. Экспортёр устанавливает tools и system_message в true как условность экспорта клиента; vision следует входным модальностям каталога, reasoning_effort задаётся при наличии ступеней effort у модели, а temperature отключается для reasoning-моделей. Другие провайдеры сохраняются, и отключение удаляет только элемент OpenCodex. Raycast подхватывает изменение сразу после сохранения файла, без перезапуска; модели появляются в его списке под OpenCodex. Raycast допускает необязательные api_keys, но OpenCodex намеренно их опускает и отклоняет назначения вне loopback или с аутентификацией допуска: эта интеграция не умеет передать обязательный заголовок допуска OpenCodex.

Закрытая настройка macOS служит лишь подсказкой о плане Pro. Windows её не читает и сообщает неизвестный план. Определение плана не разрешает и не блокирует запись. В метаданных экспорта нет достоверного признака поддержки инструментов, поэтому tools: true не доказывает, что каждая маршрутизируемая модель поддерживает инструменты. Признаки изображений и effort следуют данным каталога; отключение temperature для ступеней effort — осторожное правило экспорта. Значения провайдера сохраняются, но сохранность форматирования и комментариев YAML не гарантируется. Формат описан на manual.raycast.com/ai/custom-providers.

Экспорт через Raycast CLI и скачивание из дашборда используют адрес и правила допуска работающего сервера, в том числе настроенный loopback-слушатель без аутентификации. ocx ensure не обновляет Raycast из сохранённого снимка конфигурации: он может отличаться от работающего сервера. Путями обновления каталога остаются запуск сервера и явная синхронизация.

Cursor имеет вкладку, но не входит в список переключателей. Обычный Cursor вызывает пользовательские эндпоинты со своего backend, поэтому loopback-прокси недоступен без публичного туннеля; отдельная сборка Cursor Private Inference настраивается внутри Cursor. Вкладка Cursor доступна только для чтения: она определяет установленную сборку, показывает Base URL и API Key для ввода в Cursor и последний запрос Cursor к прокси. Подробнее см. Cursor Private Inference.

Пути учитывают собственные переменные окружения каждого клиента, если они есть. Для OMP наличие OMP_PROFILE имеет приоритет над PI_PROFILE, даже когда значение явно пустое. Именованный профиль использует PI_CONFIG_DIR как имя каталога относительно домашнего каталога пользователя и игнорирует PI_CODING_AGENT_DIR; без именованного профиля побеждает PI_CODING_AGENT_DIR. OMP поддерживает заголовки уровня провайдера, но эта первая интеграция намеренно работает только через loopback; настройка удалённого x-opencodex-api-key отложена. Перенесённые пути HERMES_HOME, KIMI_CODE_HOME и XDG_CONFIG_HOME также учитываются, а не угадываются. В таблице приведены пути по умолчанию.

Для нативных моделей OpenAI созданный блок OMP выбирает Responses API на уровне модели, сохраняя входные изображения и настройки effort. Маршрутизируемые модели сохраняют диалект Chat Completions провайдера, чтобы их существующие адаптеры оставались совместимыми.

У OpenClaw несколько переменных, и они решают разные задачи. OPENCLAW_CONFIG_PATH выбирает файл; OPENCLAW_STATE_DIR, OPENCLAW_PROFILE и OPENCLAW_HOME выбирают каталог состояния, по которому также выполняется обнаружение. Поэтому профиль или перенесённый home всё равно считается установленным, а переопределение файла конфигурации переносит только файл. Прежняя структура .clawdbot тоже обнаруживается: современный каталог имеет приоритет, если существует; старый используется, только когда он один.

Эти пути должны быть абсолютными или начинаться с ~. Относительный путь отклоняется, а не разрешается от текущего каталога: разные процессы могли запуститься из разных мест. Путь хранится вместе с резервной копией, поэтому завтра он должен указывать на тот же файл, что и сегодня.

opencodex читает переменные из собственного окружения. Если ваш шлюз работает с профилем или перенесённым home, запустите opencodex с теми же переменными, иначе он корректно выберет другую установку.

Пять других интерфейсов не являются переключателями

API Keys управляет собственными учётными данными opencodex и вообще не является клиентом. Codex CLI подключается самим сервисом прокси: запуск opencodex применяет настройку, остановка возвращает нативную маршрутизацию. Поэтому переключать отдельный файл нечего. Claude сохраняет собственный флаг включения и сценарий Save/Apply для Desktop, а Grok Build — порядок «выбрать модель, затем применить» с ограничением набора моделей. Эти правила существовали раньше и не изменились. Cursor ничего не записывает: его вкладка показывает обнаружение, значения шлюза и последний замеченный запрос, а остальные действия выполняются внутри Cursor Private Inference.

Откат

Перед каждой успешной записью сначала создаётся снимок вашего файла, поэтому прежнее состояние всегда можно восстановить:

• Undo показывается для последней операции, если файл всё ещё совпадает с записанным нами.
• Restore this point… доступна для более ранних операций или если файл изменился после операции. При восстановлении поверх такого изменения система снова попросит подтверждение перед заменой новых правок и также сохранит их копию, чтобы восстановление можно было отменить.
• Для каждого клиента сохраняются десять резервных копий. После превышения этого числа старейшие файлы снимков удаляются, а записи истории получают отметку Backup expired.

Отключение удаляет только записи, которые opencodex пометил как свои. Если файл изменился после нашей записи, результат зависит от сохранности наших записей и формата файла. В строгом JSON (OpenCode, Pi) правка рядом с нашим блоком — например, добавление MCP-сервера или собственного провайдера — показывается как Update needed. Обновление объединяет изменения вокруг ваших записей и сохраняет их, хотя форматирование может нормализоваться. Исключение — то, что JSON нельзя точно перезаписать: неконечное число вроде 1e999, число, которое при записи округлится (очень большое целое или настолько малое, что станет нулём), -0, одинаковый ключ дважды в одном объекте либо вложенность глубже 1000 уровней. В этих случаях переключатель блокируется, чтобы ничего не изменилось или не потерялось незаметно. OMP, DSH и Hermes тоже не затрагивают соседние правки, но по другой причине: их средства записи меняют побайтно только собственные управляемые диапазоны провайдера и не переписывают остальную часть файла. Для остальных форматов с комментариями (OpenClaw, Kimi Code, gjc, MiniMax Code, Raycast — JSON5 и TOML при записи всего документа либо обычный YAML без сохранения исходника), а также при изменении наших собственных записей, переключатель блокируется и отключение отказывается угадывать, какие правки ваши.

Такая блокировка не является тупиком. Рядом с переключателем конфликтующего клиента, на общей карточке и его странице, появляется Replace. Действие заменяет текущие наши настройки блоком, который записал бы opencodex, но сначала спрашивает разрешение: диалог называет файл, указывает, что будет утрачено, и показывает снимок для отмены. Сам переключатель остаётся заблокированным, потому что он не знает, какие правки вы хотели сохранить; это можете решить только вы. Другие ограничения не ослаблены: файл, который нельзя разобрать или безопасно понять, по-прежнему отклоняется.

Исключение для Hermes: если в управляемый блок добавлено только session_affinity_header: session-id, изменение можно принять через Apply. Другие изменения управляемых полей остаются конфликтами. До применения обновления фоновое обновление списка моделей также приостановлено. Настройка действует для всех моделей provider и требует версии Hermes с поддержкой этой функции; доля попаданий в кеш не гарантируется. См. инструкцию по обновлению на английском.

Предпросмотр и подтверждение изменений

Apply, Replace, Disable и Restore теперь начинаются с предпросмотра. Диалог точно показывает, какие управляемые настройки изменятся, включая ограниченные пути и вид изменения: добавление, обновление или удаление. Проверьте план перед подтверждением.

Если план не содержит изменений, управляемый документ клиента уже находится в нужном состоянии. Для выбранного профиля Aside подтверждение всё равно может сохранить предпочтение синхронизации профиля без изменения документа.

Если файл изменится после просмотра, запись будет отклонена как устаревшая. Диалог заменит старый план новым и попросит подтвердить ещё раз; автоматического повтора записи не будет. Если предпросмотр временно недоступен, обычным способом обновите страницу и начните действие заново.

Для отдельного профиля Aside применяется тот же сценарий предпросмотра и подтверждения. Sync all profiles остаётся отдельным массовым действием без одного общего предпросмотра.

Чего ожидать на практике

Форматирование обычно не сохраняется. При применении конфигурация разбирается и записывается заново. Поэтому JSON, JSON5 и TOML могут получить другое форматирование, а комментарии JSON5 и TOML будут утрачены. Исключения — OMP, DSH и Hermes: их средства записи YAML меняют только управляемый фрагмент. Для OMP и Hermes это providers.opencodex; для DSH — [id=llm-pi-ai].config.providers.opencodex в патче Desktop или, только при отсутствии профиля Desktop, llm-pi-ai.providers.opencodex в settings.yaml. Комментарии и форматирование остальных провайдеров сохраняются побайтно. Если точный диапазон исходного файла нельзя безопасно определить, операция отказывается от записи. Для остальных клиентов используйте Restore, когда нужны прежние байты файла: снимок представляет собой точную копию.

Если значение нельзя точно перезаписать, переключатель отказывается от операции. Перезапись охватывает типы значений, обычно используемые этими форматами. Когда это невозможно — например, файл TOML содержит inf или nan, которые доступный парсер не может точно прочитать обратно, — применение останавливается с объяснением, а не записывает изменённое значение под видом успеха. Вы увидите имя файла, но данные на диске не сдвинутся. Ручное редактирование остаётся возможным; отказывается лишь автоматическая перезапись.

Даты и время TOML также исключают управляемую перезапись: объединение превратило бы типизированные значения в строки в кавычках. Это касается и значений в массивах и встроенных таблицах. Строки дат в кавычках поддерживаются; дату без кавычек сохраняйте ручным редактированием конфигурации.

Pi, Kimi Code, gjc, MiniMax Code, Prime Agent, Aside, Raycast, omo и управляемая интеграция DSH работают только с loopback-привязкой. У первых четырёх нет поля конфигурации для заголовка x-opencodex-api-key, обязательного при привязке вне loopback. У DSH есть общая карта заголовков, но rc.6 не документирует этот специальный заголовок допуска как поддерживаемый контракт интеграции. Поэтому управляемое средство записи закрывается отказом, а не угадывает. Блок провайдера Prime Agent принимает заголовки, но настройка удалённых учётных данных отложена после первого выпуска интеграции. Дайте им доступ к loopback через SSH-туннель или локальный посредник, добавляющий заголовок.

Создаваемая интеграция OMP тоже намеренно работает только через loopback. OMP поддерживает заголовки уровня провайдера, но эта первая интеграция не создаёт удалённую настройку учётных данных x-opencodex-api-key. Ручная удалённая конфигурация OMP пока вне управляемой интеграции.

Kimi Code не может хранить ссылку на переменную окружения, поэтому его конфигурация содержит заглушку opencodex-loopback вместо ключа. Настоящие учётные данные никогда не записываются в конфигурацию клиента.

При ocx opencode побеждают блоки провайдера, заданные запускателем. Запускатель внедряет provider.opencodex и providers.opencodex через OPENCODE_CONFIG_CONTENT, что имеет приоритет над такими же записями на диске. Остальная конфигурация opencode действует как обычно. Эти блоки строятся из тех же фактических канонических метаданных моделей, что и экспорты, поэтому запускатель и управляемая интеграция описывают одни и те же модели, лимиты и варианты effort. Переключатель на этой странице важен при прямом запуске opencode.

Из терминала

Те же действия доступны без графического интерфейса:

ocx integration client status
ocx integration client enable --client hermes
ocx integration client disable --client hermes
ocx integration client history --client hermes
ocx integration client restore --op <opId> [--confirm-drift]

--overwrite-conflict — терминальный эквивалент Replace:

ocx integration client enable --client zcode --overwrite-conflict

Как и --confirm-drift, он никогда не подразумевается: без него конфликт по-прежнему отклоняется. Флаг действует только для enable; принудительное отключение при конфликте удалило бы блок, который мы не записывали, поэтому такая комбинация отклоняется.

Для MiniMax Code один раз подключите провайдера и запускайте через проверяющую обёртку:

ocx integration client enable --client mcode
ocx mcode

После подключения ocx sync и POST /api/sync обновляют принадлежащие интеграции каталоги MCode, Pi, Aside, Raycast, omo, OpenCode и Kilo с текущим выбором моделей, контекстными окнами и ступенями effort. Запуск прокси обновляет принадлежащий ему каталог Raycast. Изменения видимости моделей, выбора провайдера или пресетов также обновляют подключённые каталоги Pi, Aside, Raycast, omo, OpenCode и Kilo. Отсутствующие, изменённые извне или небезопасные блоки остаются нетронутыми, как и ранее принадлежавшие интеграции блоки, удалённые вами вручную. Есть исключение для включённого профиля Aside: если каталог его аккаунта существует, но управляемого блока никогда не было, синхронизация может создать первый блок в пустом месте. Прежнее подключение Aside по умолчанию включает такое поведение для всех зарегистрированных профилей. Синхронизация не создаёт отсутствующие каталоги аккаунтов и не заменяет ручные блоки. Отказ или пересечение операций обновления сообщается отдельно для каждого клиента. Чтобы загрузить новый файл, начните новую сессию Pi, OpenCode или Kilo либо полностью закройте и откройте Aside. Обновление Aside требует совместимого работающего прокси.

Если Models показывает “Model selection saved” вместе с предупреждением об обновлении клиента, выбор уже сохранён, но один или несколько клиентских файлов не обновились. Предупреждение называет затронутого клиента и при необходимости профиль Aside и объясняет причину отказа. Перед новой сессией откройте Подключение и проверьте клиента или профиль. Исправьте указанную проблему, затем повторите ocx sync; сначала должна завершиться пересекающаяся операция. Если предупреждение содержит путь резервной копии или говорит о незавершённом восстановлении, проверьте это состояние до повтора. Само по себе успешное сохранение выбора не подтверждает восстановление клиентского файла.

Отдельный платформенный CLI MiniMax (mmx) не является интеграцией с переключателем файла. Его текстовые команды используют Anthropic-совместимый эндпоинт MiniMax, поэтому OpenCodex предоставляет изолированную по учётным данным обёртку, работающую только через loopback:

ocx mmx text chat --model anthropic/claude-opus-5 --message "Hello"
ocx mmx text repl --model openai/gpt-5.6-sol

Проксируются только mmx text chat и mmx text repl. Для нативных команд MiniMax — изображений, видео, речи, музыки, анализа изображений, поиска, квоты, входа, конфигурации, файлов и обновления — запускайте обычный mmx. Обёртка использует временную конфигурацию лишь с несекретной заглушкой loopback. Она никогда не загружает учётные данные OAuth или API-ключ из ~/.mmx и отклоняет переопределения --api-key, --base-url и --region. Полный сценарий и ограничения описаны в разделе Клиенты MiniMax.

--confirm-drift никогда не подразумевается. Если после восстанавливаемой операции файл изменился, команда откажется от записи и сообщит об этом: решение о замене новых правок принимает пользователь.

Подробности клиентов проверялись по формату конфигурации каждого проекта; исследовательские заметки о проверенном и её времени находятся в devlog/_fin/260802_client_toggle_api/002_client_toggle_matrix.md.

Управление профилями Aside

Элементы управления профилями Aside и их обновление через ocx sync требуют работающего прокси ocx с поддержкой API профилей Aside. Обновление одного CLI не обновляет уже работающий прокси. Если прокси недоступен или слишком стар, операция Aside не завершится; CLI не переключится на локальную запись файлов профиля Aside.

Обновите установку ocx, из которой запущен прокси, затем перезапустите его (или запустите, если он остановлен). Повторите ocx sync или команду профиля. После успешного обновления файлов профиля полностью закройте и снова откройте Aside, чтобы он загрузил новые каталоги.

ocx integration client status --client aside --json
ocx integration client enable --client aside
ocx integration client disable --client aside --profile 1
ocx integration client history --client aside --profile 1
ocx integration client restore --client aside --profile 1 --op <opId>

Номер профиля — id аккаунта из команды состояния. Если при переключении Aside не указать --profile, желаемое состояние применяется ко всем зарегистрированным профилям. Изменение одного профиля не затрагивает остальные. Желаемые настройки синхронизации сохраняются до изменений файлов; фактический результат и любой отказ сообщаются для каждого профиля. Частичный результат массовой операции не считается полным успехом, и CLI завершается с ненулевым кодом. Undo восстанавливает и намерение синхронизации выбранного профиля, и его файл, чтобы последующая синхронизация не отменила Undo незаметно.

API профилей возвращает HTTP 200 при успешной массовой операции и HTTP 207 с ok: false, если хотя бы один профиль отказал. Проверьте каждую запись в results: успешные профили не откатываются из-за ошибки другого. Желаемые настройки остаются сохранёнными, поэтому после исправления затронутого профиля повторите операцию, не предполагая, что всё действие не удалось. Если сохранить настройки не удалось, файлы профилей не меняются.

У каждого профиля свои владение и история. При существующих пользовательских правках, небезопасных путях и связанных каталогах операция отклоняется; сохраняются явные возможности перезаписи и подтверждения расхождения. Полностью закройте и снова откройте Aside для загрузки изменённых файлов моделей.

ZCode 3.14 и более поздние версии

Эти пути указаны по умолчанию. Абсолютный dataBaseDir в ~/.zcode/v2/setting.json, который всегда остаётся в домашнем каталоге по умолчанию, переносит хранилище в <dataBaseDir>/.zcode/v2/provider_config.json. ZCODE_DATA_DIR задаёт сам корень .zcode и имеет приоритет над настройкой; ZCODE_PERSONAL_PROVIDER_CONFIG_FILE имеет приоритет для файла провайдеров. Нечитаемая, некорректная или относительная настройка блокирует новое применение и обновление. Существующие записи владения и восстановления сохраняются. См. правила путей и восстановления на английском.

Начиная с ZCode 3.14 пользовательские провайдеры хранятся в ~/.zcode/v2/provider_config.json, а ~/.zcode/v2/config.json используется лишь для однократного импорта при отсутствии нового файла. ZCode создаёт новый файл при первом запуске, поэтому в уже запускавшейся установке импорт прошёл, и запись в config.json ни на что не влияет.

opencodex по возможности записывает напрямую в provider_config.json. Включение интеграции добавляет в него правило провайдера opencodex, обновление каталога меняет это правило, а отключение удаляет ровно записанное opencodex. Все прочие правила остаются нетронутыми, в том числе правило другого провайдера для id модели, также присутствующего у нас. Если правило с id opencodex записано не opencodex, это конфликт, а не повод забрать его: разрешите конфликт в ZCode или воспользуйтесь явной перезаписью.

Нечитаемое хранилище провайдеров или объект, не являющийся файлом, также отклоняет запись; он не считается отсутствующим хранилищем, позволяющим старый импорт.

Ещё в двух случаях запись отклоняется. Если блок opencodex применён до переноса хранилища ZCode, интеграция остаётся привязанной к config.json: сначала отключите её там, затем включите снова, чтобы записать новый файл. Если schemaVersion в provider_config.json не относится к версии, известной opencodex, объединение с файлом отклоняется. В нём хранятся все провайдеры ZCode; предположение о структуре заменило бы незаметное отсутствие действия незаметной потерей данных. Когда интеграция не пишет файл, состояние указывает, какой файл читает ZCode.

Во втором случае добавьте провайдера в собственных настройках ZCode: базовый URL http://127.0.0.1:10100/v1 (подставьте свой порт), любой непустой ключ и id моделей из ocx export --client zcode. Удалять provider_config.json ради повторного запуска импорта ZCode не поддерживается: это уничтожит всех провайдеров, которых ZCode хранит там.

Cline CLI

Интеграция предназначена для текущего хранилища провайдеров CLI/общего SDK Cline с нативной схемой version: 1. Прежнее хранилище расширения VS Code globalState/секретов не переносится и не определяется как эта интеграция. Один раз запустите Cline, чтобы создать каталог настроек.

Остановите Cline перед включением, синхронизацией, отключением или восстановлением интеграции. OpenCodex записывает providers.opencodex в providers.json и соседний models.json. Первый файл хранит подключение OpenAI Responses с несекретной заглушкой loopback; второй — отфильтрованный каталог маршрутизируемых моделей, включая доступные метаданные контекста и изображений. Существующие записи провайдеров и выбор провайдера по умолчанию не меняются.

ocx integration client list --json
ocx integration client enable --client cline
ocx integration client history --client cline
ocx integration client restore --op <operation-id>

После включения перезапустите Cline и выберите OpenCodex либо запустите cline --provider opencodex --model <provider/model>. Изменения внешнего каталога считываются при перезапуске Cline. Cline исключён из фонового обновления каталога: после изменения выбора маршрутизируемых моделей остановите Cline и выполните ocx sync либо снова включите интеграцию. Выбранная модель сохраняется, пока маршрутизируется, и сбрасывается при удалении из экспортируемого каталога.

CLINE_PROVIDER_SETTINGS_PATH переопределяет основной файл. Иначе CLINE_DATA_DIR выбирает каталог данных, затем CLINE_DIR — корневой каталог, а затем используется ~/.cline. Файл моделей всегда называется models.json и находится рядом с выбранным файлом провайдеров. Переопределения должны быть абсолютными или начинаться с ~. При запуске OpenCodex повторите локальные пути Cline --config через CLINE_PROVIDER_SETTINGS_PATH. Основной путь с именем models.json отклоняется: файлы должны различаться.

Замена каждого файла атомарна, но ни одна файловая операция не заменяет оба одновременно. Одна журнальная операция сохраняет снимки обоих исходных файлов; при сбое записи или учёта оба компенсируются. Прерванная операция оставляет закрытую запись восстановления. Состояние сообщает о незавершённом восстановлении как о небезопасном, а следующая явная операция восстанавливает данные лишь при отсутствии посторонних изменений любого файла или его владения. Если восстановление отказало, сохраните файлы и путь восстановления из сообщения операции; разрешите конфликт до повтора.

Undo восстанавливает оба исходных набора байтов, включая файл, которого изначально не было. Правки после операции требуют существующего явного флага --confirm-drift; изменённая пара сначала копируется. Занятая запись OpenCodex требует явного --overwrite-conflict. Отключение удаляет две управляемые записи; прежнюю чужую запись оно не возвращает. Для этого используйте Undo. Хранение и истечение снимков следуют общим правилам интеграций.

Скачиваемый cline-config-bundle.json содержит два нативных документа: settings для providers.json и catalog для models.json. Сам пакет не является файлом настроек Cline. Для объединения с журналом и возможности отката лучше использовать команду интеграции. Создаваемая интеграция не поддерживает удалённую настройку допуска и требует loopback-доступа без аутентификации.

Диалект Responses для omo (на базе Pi)

Управляемый блок omo на базе Pi по умолчанию использует диалект Chat (api: "openai-completions"). Chat отбрасывает рассуждения предыдущего шага между вызовами инструментов, и в длинных циклах инструментов omo это заметно. Чтобы подключение и каждое обновление записывали диалект Responses, добавьте в конфигурацию opencodex этот ключ, который задаётся только в файле конфигурации:

{ "omoClientExport": { "api": "openai-responses" } }

Перезапустите прокси, чтобы он загрузил изменённую конфигурацию (ocx service restart для установки как службы, иначе ocx stop, затем ocx start), и обновите интеграцию omo в Connect → omo на дашборде. Одно обновление использует конфигурацию запущенного прокси и не перечитывает файл. Настройка действует только для omo: Pi, Gentle Shell и другие клиенты формата Pi остаются на openai-completions. Чтобы вернуться к Chat, удалите ключ, так же перезапустите прокси и обновите Connect → omo. Неизвестное значение игнорируется. opencodex по-прежнему владеет только providers.opencodex в ~/.omo/agent/models.json, остальные провайдеры в этом файле не меняются.

Уровень рассуждений ролей omo (Codex / LazyCodex)

Когда обнаружен LazyCodex, в разделе omo (Codex / LazyCodex) на вкладке omo можно выбрать модель и уровень рассуждений для каждой роли из $CODEX_HOME/agents/*.toml и нажать Сохранить. Строка роли без закреплённой модели может сохранить только уровень; роль при этом продолжает наследовать модель. opencodex меняет в файле роли только корневые ключи model и model_reasoning_effort, а отсутствующие значения добавляет ближе к началу файла. Инструкции роли, остальные комментарии и ключи остаются без изменений. Сохранение, которое меняет только модель, не отправляет effort, поэтому оба значения уровня сохраняются. Выбор уровня добавляет или заменяет model_reasoning_effort в файле роли и, если LazyCodex поддерживает этот уровень, записывает его в [codex].agents.<role>.reasoning в ~/.omo/omo.jsonc (ultra остаётся только в файле роли, а прежний reasoning удаляется). В командной строке то же самое делает ocx agent roles set <role> <model> --effort <level>.

В каждой строке, включая роли с уже закреплённым уровнем, есть пункт Наследовать усилие. Если заменить им закреплённый уровень и сохранить, отправляется "effort": null: из файла роли удаляются корневая строка model_reasoning_effort и комментарий в конце этой строки, а из omo.jsonc — [codex].agents.<role>.reasoning. Закреплённая модель остаётся. Затем Codex определяет уровень так же, как для любой роли без собственного значения (явное значение при запуске, значение по умолчанию из [agents] или родительская сессия), а не берёт фиксированное значение модели по умолчанию. Удалить можно только существующее однострочное строковое значение; многострочное или нестроковое значение отклоняется с 409 unsupported_model_value, и оба файла остаются без изменений.

В PUT /api/codex-agent-roles/{role} без поля model закреплённая модель в файле роли и model в omo.jsonc остаются как есть: роль без закреплённой модели продолжает её наследовать, а её уровень меняется или сбрасывается. Для такой строки дашборд отправляет запрос только с уровнем, а если в omo.jsonc нет записи для роли, запись только с reasoning создаётся лишь при сохранении уровня, поддерживаемого LazyCodex. Значение model, равное null, отклоняется с 400 invalid_model, потому что сохранение никогда не удаляет закреплённую модель, а запрос без model и effort отклоняется с 400 empty_update ещё до чтения файла роли или omo.jsonc. ocx agent roles set всегда принимает модель.

Если ~/.omo/omo.jsonc отсутствует, он не создаётся. Если в нём есть комментарии, файл не изменяется, потому что сохранение удалило бы их; в этом случае задайте значение вручную. Пропуск зеркала не отменяет сохранение файла роли. Если файл роли сохранён, а запись omo.jsonc не удалась, кнопка в строке меняется на Повторить запись omo.jsonc и повторно отправляет тот же выбор уровня, включая сброс через Наследовать усилие (null). Пока повторная запись не выполнена успешно, последующее нажатие Сохранить или Применить в разделе Автоназначение для этой роли без изменения уровня также отправляет ожидающий выбор; явно выбранный уровень заменяет его.

Автоназначение предлагает уровень для каждой оценённой роли, у выбранной модели которой непустой список уровней, а Применить, Применить все или ocx agent roles suggest --apply добавляют или заменяют её значение model_reasoning_effort. Уровень выбирается из собственных уровней модели: самый низкий, уровень по умолчанию, на один выше уровня по умолчанию или самый высокий. Для пустого списка уровень не предлагается (proposedEffort: null); Применить тогда не отправляет effort и оставляет закреплённый уровень как есть. Предложение null никогда не сбрасывает закреплённый уровень.

Команда CLI ocx agent roles suggest --apply применяет не более 50 изменяемых ролей в одном пакете истории. Роли с уже совпадающими настройками, без оценки или без назначения не учитываются. При превышении лимита команда завершается с кодом 5 до отправки любого обновления роли. Просмотрите предложения без --apply, затем применяйте отдельные изменения через ocx agent roles set <role> <model> [--effort <level>]. Подтверждённые записи, запросы с неподтверждённым результатом и порядок повторной попытки описаны в контракте применения и восстановления CLI.

Kilo

Kilo CLI, VS Code и JetBrains используют общую глобальную конфигурацию. Интеграция записывает provider.opencodex в первый существующий файл среди kilo.jsonc, kilo.json, opencode.jsonc, opencode.json и config.json в ~/.config/kilo. Переменная XDG_CONFIG_HOME переносит этот каталог. Если файлов нет, создаётся kilo.jsonc. Конфигурация проекта не изменяется.

Kilo объединяет все эти глобальные файлы. Если другой файл-кандидат тоже определяет provider.opencodex, статус перечисляет конфликтующие файлы, а применение и замена отклоняются. Перед включением удалите provider.opencodex из этих файлов. Отключение уже принадлежащего OpenCodex блока доступно и при таком конфликте. Нечитаемый или небезопасный файл-кандидат также блокирует запись.

Интеграции принадлежит только provider.opencodex в формате OpenCode V1 (npm, options, models). Поле OpenCode V2 providers не создаётся; вместо этого варианты effort для каждой модели записываются в блоке провайдера как карта вариантов — из тех же фактических канонических метаданных, что и экспорт OpenCode. $schema, model, enabled_providers, MCP и прочие ключи остаются под управлением пользователя. После применения выберите в Kilo opencodex/<provider/model>.

Для loopback значение options.apiKey — {env:OPENCODEX_KILO_API_KEY}. При привязке не к loopback авторизация переносится в options.headers["x-opencodex-api-key"]; настоящий ключ не записывается. Применение переписывает весь глобальный файл как форматированный JSON, поэтому комментарии и завершающие запятые в других ключах не сохраняются. Kilo входит в автоматическое обновление каталога: ocx sync, POST /api/sync и изменения видимости, провайдера или пресетов обновляют принадлежащий блок Kilo по тем же безопасным правилам «только свои блоки», что и остальные клиенты, а новая сессия Kilo загружает обновлённый файл.

ocx integration client enable --client kilo
ocx export --client kilo --out ./kilo.jsonc

Приложение GitHub Copilot

Настольное приложение GitHub Copilot может использовать opencodex как совместимого с OpenAI поставщика моделей. Это ручная настройка клиента без переключателя на вкладке Подключение. Она не связана с upstream-провайдером github-copilot, который использует подписку Copilot как backend для opencodex.

1. Запустите opencodex и убедитесь, что он отвечает:

   curl http://127.0.0.1:10100/healthz
   curl http://127.0.0.1:10100/v1/models

2. В приложении Copilot откройте Settings → Model providers → Add provider и укажите:

   Поле	Значение
   Имя	Любая подпись, например OpenCodex
   Base URL	http://127.0.0.1:10100/v1 (измените порт в соответствии с привязкой)
   API key	Оставьте пустым для loopback-подключения

3. Синхронизируйте модели с endpoint либо добавьте модель по ID provider/model и выберите её.

Для получения списка моделей приложение использует GET /v1/models, а для запросов — POST /v1/chat/completions. Запросы проходят через обычную маршрутизацию моделей opencodex, поэтому применяются учётные данные провайдера, OAuth-аккаунты и комбинации моделей, как и для любого другого клиента. Поддерживаемые поля запроса перечислены в справочнике форматов прокси.

Если приложение сообщает, что моделей нет, проверьте, что Base URL заканчивается на /v1, а не на /v1/chat/completions, и что /v1/models возвращает непустой массив data. Если opencodex слушает адрес вне loopback, укажите в поле API key ключ допуска данных (токен из раздела удалённого доступа или созданный в дашборде ключ ocx_…). Приложение отправляет его как Authorization: Bearer; /v1/chat/completions использует его только для допуска к прокси и не пересылает upstream. Подробнее см. матрицу аутентификации.

Factory Droid

Factory Droid использует ~/.factory/settings.json (%USERPROFILE%\.factory\settings.json в Windows). Явно включите интеграцию командой ocx integration client enable --client droid, затем выберите пользовательскую модель через /model. Управляемые записи не содержат ключа и работают только через loopback. Отключение удаляет управляемые записи, а Undo восстанавливает сохранённые байты. Если в прежнем config.json есть записи OpenCodex или settings.local.json переопределяет customModels, устраните конфликт до включения. См. документацию Factory BYOK.

Hermes / Command Code: model names

Hermes and Command Code support --model-names alias|routed (API: modelNames). The default is routed, independent of preferModelAliasIds. A connection stores its mode; later Apply without the option preserves it. Alias mode uses only provider-qualified aliases that the router proves equivalent; missing, unsafe or colliding aliases fall back to routed keys. Combos keep their keys. Removed/renamed aliases migrate on the next successful managed refresh, with foreign-edit refusal. Named Hermes profiles need explicit Apply.

ocx export --client hermes --model-names alias --json previews a current already loaded catalog without writing client files or managed state; a cold or stale catalog returns unavailable. Explicit --out writes an export artifact. See the English integration guide for the canonical workflow.