OpenClaude для работы с несколькими провайдерами

Переключение провайдеров через команды-обертки работает, пока их немного. Одна команда запускает облачную модель, другая локальную, третья выставляет нужные переменные окружения для шлюза. С парой провайдеров это терпимо. Дальше появляются квоты, сбои и требования к обработке данных.

OpenClaude устроен иначе. Это самостоятельный CLI для кодинг-агента с профилями провайдеров и пошаговой настройкой через /provider. В текущей документации перечислены OpenAI-совместимые API, Gemini, GitHub Models, Codex, Ollama и другие бэкенды. Список провайдеров и модели по умолчанию меняются, поэтому сверяйтесь с документацией репозитория.

Один терминальный процесс и отдельные профили

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

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

Профили уменьшают трение при настройке, но не отменяют решения о том, нужно ли передавать следующей модели текущий контекст.

Начните с пошаговой настройки

В проекте описаны такие установка и запуск:

npm install -g @gitlawb/openclaude@latest
openclaude

Затем выполните /provider в CLI. Команда сохраняет профиль провайдера и избавляет от отдельной команды-обертки для каждого сервиса. В текущем README сказано, что OpenClaude не загружает автоматически проектный .env. Экспортируйте переменные провайдера явно, используйте документированную настройку или передавайте отдельный файл окружения для провайдера, если это подходит вашему процессу.

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

Простая политика маршрутизации

Если моделей несколько, выбирайте их по типу задачи, а не по названию бренда. Например:

Работа	Какой профиль рассмотреть
Небольшая локальная или чувствительная задача	Локальную модель после проверки ее возможностей
Первичное исследование	Более дешевый профиль с понятным лимитом токенов
Решение по дизайну или сложное ревью	Модель, которую вы уже проверили на такой работе
Долгое изменение	Профиль с достаточной квотой и явными контрольными точками

Это политика, а не гарантия, что один класс моделей всегда лучше другого. Проверяйте маршрут на своем репозитории, с теми инструментами и разрешениями, которыми пользуетесь. Отслеживайте результаты тестов, замечания ревью, задержку, повторы и полную стоимость запросов. Быстрая модель, которой нужно несколько исправлений, не обязательно окажется дешевле.

Локальные модели и OpenAI-совместимые endpoint

OpenClaude поддерживает OpenAI-совместимые подключения и документирует настройку локального Ollama через переменные окружения:

export CLAUDE_CODE_USE_OPENAI=1
export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_MODEL=qwen2.5-coder:7b
openclaude

Считайте это начальной точкой. Проверьте актуальное имя модели, размер контекста, работу с инструментами и расход ресурсов на своей машине. Локальный endpoint не отправляет промпты во внешний API только тогда, когда локальны все компоненты процесса. У поиска, MCP-серверов, телеметрии и других инструментов могут быть собственные сетевые обращения.

Сравнение с обертками

Clother и OpenClaude решают разные задачи. Обертка сохраняет официальный бинарник Claude Code и меняет окружение вокруг него. OpenClaude является отдельным CLI со своей конфигурацией и настройкой провайдеров.

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

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