Чтобы подключить OpenRouter к OpenCode, хватает двух команд внутри программы: /connect для ввода ключа из личного кабинета OpenRouter и /models для выбора модели из списка. Облако открывает доступ к моделям разных разработчиков с одним ключом, но вместе с запросом наружу уходят фрагменты вашего кода. Схема уместна для репозиториев, содержимое которых разрешено отправлять внешнему сервису.
Облако для кода
OpenCode подключает OpenRouter как готового провайдера: ключ вводят командой /connect, модель выбирают в /models, а файл opencode.json нужен только для тонкой настройки.
Основная причина взять облачного провайдера — качество. Крупные модели лучше удерживают в голове несколько файлов, аккуратнее правят чужой код и реже путаются в вызовах инструментов. Вторая причина — выбор: через один ключ OpenRouter можно пробовать модели разных разработчиков и сравнивать их на своей задаче. Для команды без мощного железа это самый быстрый путь получить сильную модель в терминале.
Платой становятся данные и зависимость от внешнего сервиса. Каждый запрос содержит куски файлов, которые агент счёл нужными, и результаты выполненных команд. Если репозиторий содержит коммерческую тайну или персональные данные клиентов, сначала решите вопрос допуска, и только потом заводите ключ. Локальную альтернативу, где модель отвечает с вашего компьютера, описывает материал про локальный сервер LM Studio, а работу с самим сервисом через собственный код — статья про рабочую схему OpenRouter API.
На практике команды приходят к OpenRouter по-разному. Одним нужно быстро сравнить несколько моделей на реальном репозитории перед покупкой отдельных подписок. Другим мешает слабое железо, и локальная модель в терминале работает слишком медленно. Третьи хотят дать разработчикам единый способ доступа, при котором расход видно в одном кабинете. Во всех трёх случаях вопрос допуска данных решается раньше вопроса о качестве: сильная модель бесполезна, если безопасность запретила отправлять код наружу.
Отдельно обозначим границу с соседней темой: подключение инструментов MCP к OpenCode, выбор серверов и права на них разобраны в статье про OpenCode MCP. Здесь речь только о том, откуда агент берёт модель.
Ключ и подключение
Как указано в разделе провайдеров документации OpenCode, подключение OpenRouter устроено в три шага. Ключ создают в настройках аккаунта OpenRouter, затем вводят в самом OpenCode через интерактивную команду, а модель выбирают из списка. Править конфигурационный файл для старта необязательно: ключ OpenCode сохраняет в собственном локальном хранилище учётных данных, поэтому в репозиторий ему путь закрыт.
- Создайте отдельный ключ в кабинете OpenRouter для этого проекта и дайте ему понятное название. Так в случае утечки вы отзовёте один ключ, оставив остальные интеграции нетронутыми.
- Запустите
opencodeв папке тестового репозитория и введите/connect. В списке найдите OpenRouter и вставьте ключ. - Выполните
/modelsи выберите модель. По документации, многие модели уже предзагружены в список, поэтому дополнительная настройка нужна только для отсутствующих. - Задайте безобидный вопрос о структуре проекта и сверьте ответ с реальными файлами. Только после этого переходите к правкам.
Ключ — это платёжный инструмент: расход идёт на ваш баланс в OpenRouter. Задайте для ключа лимит расходов, если сервис это позволяет, и следите за журналом использования в кабинете. Показывать ключ в чатах, вставлять в файлы проекта и пересылать коллегам нельзя; каждому разработчику выдают свой.
Выбор модели
Список моделей в OpenRouter длинный и быстро меняется, поэтому названия и цены берите с актуальных страниц сервиса. Для кодового агента важнее общих рейтингов четыре свойства, которые вы проверяете на своих задачах. Заведите короткий тестовый набор из трёх задач разной сложности и прогоняйте на нём каждую кандидатуру.
| Свойство | Как проверить | Тревожный сигнал |
|---|---|---|
| Работа с инструментами | Попросить прочитать файл и назвать точку входа | Модель описывает действие словами вместо вызова |
| Окно контекста | Дать задачу из нескольких файлов | Агент забывает начало разговора |
| Качество правок | Сравнить diff с ожидаемым результатом | Задеты соседние функции |
| Расход токенов | Посмотреть журнал использования в кабинете | Длинные рассуждения при короткой правке |
Сравнивать модели полезно парами. Возьмите одну сильную и одну экономную, дайте им идентичные задачи и сопоставьте число правок, которые пришлось исправлять вручную, с расходом токенов за прогон. Часто выясняется, что простые задачи вроде переименования или дописывания теста экономная модель закрывает с тем же результатом, а сильную оставляют для рефакторинга и разбора чужого кода. Такое разделение записывают в памятку команды, чтобы разработчики выбирали модель под задачу осознанно.
Если нужной модели нет в предзагруженном списке, её добавляют в opencode.json в блоке provider.openrouter.models по идентификатору из каталога OpenRouter. Идентификатор берут целиком вместе с префиксом разработчика, иначе OpenRouter отклонит имя. В том же месте при необходимости задают параметры конкретной модели.
Маршрут и данные
Один и тот же идентификатор модели в OpenRouter может обслуживаться разными хостерами. В документации OpenCode приведён пример: для выбранной модели в разделе options.provider задаются порядок хостеров order и флаг allow_fallbacks, отключающий переход к другому хостеру при сбое. Для кода это решает практический вопрос: вы указываете, у кого именно обрабатывается запрос, вместо выбора по умолчанию.
Политику хранения и использования запросов задают условия самого OpenRouter и каждого хостера. Эти условия меняются, поэтому перед загрузкой реального кода прочтите актуальные страницы сервиса и закрепите решение в правилах компании. Если ответ юриста или службы безопасности ещё впереди, работайте только с открытым кодом и учебными репозиториями.
Какие части вашего кода разрешено отправлять внешнему сервису?
Часть защитных мер лежит на вашей стороне. Исключите из рабочей папки агента файлы окружения, выгрузки и каталоги с клиентскими данными. Пока команда осваивает инструмент, держите режим, при котором OpenCode спрашивает разрешение на запись в файлы и запуск команд. Вопросы допуска в компании удобно решать вместе с разбором консалтинга по ИИ: роли, владельцы ключей и перечень разрешённых репозиториев.
Первая задача
Для проверки возьмите тестовый репозиторий и задачу с готовым критерием: дописать тест к функции, исправить ошибку с воспроизводимым сценарием или переименовать сущность по всему коду. Сформулируйте её одним абзацем с указанием файлов и ожидаемого результата. Чем точнее вход, тем меньше агент домысливает.
Результат принимает человек. Прочитайте diff целиком, отдельной командой запустите тесты и линтер, посмотрите новые зависимости и вызовы. Облачные модели правят аккуратнее локальных, но придумывают метод библиотеки с той же уверенностью. Коммит ставит разработчик, который понимает каждую строку изменения.
После десятка задач сопоставьте журнал расхода из кабинета OpenRouter с числом принятых правок. Так видно, какие модели окупаются на вашем коде, а какие тратят токены на длинные рассуждения. Решение о переходе на другую модель или о возврате к локальной схеме принимайте на этих данных.
Типичные причины сбоя в первый день укладываются в короткий список. Ключ введён с лишним пробелом или относится к другому аккаунту. Идентификатор добавленной модели записан без префикса разработчика. Баланс в кабинете исчерпан, и сервис отвечает отказом. Выбранная модель слабо справляется с вызовом инструментов и подменяет действие рассуждением. Прежде чем менять конфигурацию, проверьте каждый пункт отдельно, меняя за один раз только одну вещь.
Заведите отдельный ключ с лимитом расходов, подключите OpenRouter в тестовом репозитории и прогоните три задачи разной сложности на двух моделях. Запишите, сколько правок пришлось исправлять руками. Если нужна помощь с регламентом допуска, напишите нам про внедрение ИИ в разработку.