
OpenRouter перестал обслуживать пользователей из России, и вопрос теперь стоит иначе: чем заменить. Для команд, у которых на нём жили прототипы и рабочие интеграции, это не отвлечённая новость. Запросы к прежнему адресу начинают отдавать ошибку, а пополнить баланс российской картой не выходит. Переезд на прямые китайские модели при этом не требует переписывать продукт. Разберём, что делать по шагам.
Что произошло
OpenRouter устроен как агрегатор: одна точка входа ко множеству моделей, единый ключ, привычный формат запросов. Именно поэтому им было удобно пользоваться из России — не нужно заводить отдельный аккаунт у каждого вендора. Ограничение доступа из страны ломает сразу два звена: соединение и оплату. По данным разбора ProxyAPI, доступ для России был закрыт в конце июня 2026 года. У разных сервисов сроки и формулировки свои, но вывод один: как основной канал для российского продукта агрегатор больше не годится.
Отдельно про деньги. Агрегатор принимал оплату через внешнего платёжного провайдера, и российские карты у него не проходили. Пока сервис работал, вопрос закрывали посредниками и чужой картой. После ограничения доступа смысла в этом нет: даже если баланс пополнить, запросы из России не уходят.
Что именно сломалось у вас
Технически OpenRouter был OpenAI-совместимым: тот же SDK, свой адрес эндпоинта, ключ агрегатора, имя модели через слэш. Поэтому поломка видна быстро — запросы к прежнему адресу перестают проходить. Сам код вызова при этом цел: он умеет ходить на любой совместимый адрес. Чинить придётся не логику продукта, а точку подключения.
Проверьте, не зашиты ли адрес и ключ прямо в код. Если да, это первое, что стоит вынести в переменные окружения. Тогда следующая смена провайдера займёт минуты, а не вечер.
Четыре модели, на которые переходят
Заменять агрегатор логично прямыми китайскими моделями. Их сейчас четыре основных семейства, и у каждого свой профиль.
- DeepSeek — рассуждения, математика, код. Крепкий выбор, если продукту нужен инженерный ассистент: расчёты, скрипты, внутренние боты.
- Qwen — самое широкое семейство от Alibaba: от компактных моделей до флагманов, отдельные версии под код и изображения, уверенная многоязычность и длинный контекст.
- GLM — агентные сценарии: модель планирует шаги и работает с инструментами. Подходит для ассистентов, которые сами собирают данные из ваших систем.
- Kimi — очень длинный контекст: договоры, переписка за год, техническая документация. Там, где другие модели просят резать текст на куски, Kimi читает документ целиком.
Универсального победителя нет. На практике команды почти всегда приходят к связке: одна модель держит чат, вторая разбирает документы, третья пишет код. Поэтому важнее не выбрать «лучшую», а сделать так, чтобы модель была параметром, а не отдельной интеграцией.
Что меняется при переезде
Переезд сводится к трём значениям окружения: адрес эндпоинта, ключ доступа и имя модели. Бизнес-логика, обработка ответов и стриминг остаются прежними, если код уже работал с совместимым форматом.
Было: адрес агрегатора, ключ OpenRouter, имя модели через слэш.
Стало: адрес российского шлюза, один ключ, имя модели из каталога.
Вызов запроса и разбор ответа — те же.
Если в проекте несколько сервисов, переводите их по одному. Ошибка в конфигурации одного бота не заденет остальные. Про сам механизм переключения мы писали в разборе «OpenAI SDK и китайские модели».
Что проверить после переключения
Совместимый протокол не означает одинаковое поведение. Разница всплывает в мелочах, и почти все они проверяются заранее.
- Промпты. Формулировки, заточенные под одну модель, на другой дают другой результат. Прогоните свои на новой модели, а не ждите совпадения.
- Вызов функций и строгий JSON. Поддержка форматов различается между семействами. Проверьте на своих схемах, а не на демо из документации.
- Длинный контекст. Сверьте лимиты с самыми большими запросами приложения. Разница вылезает уже в проде.
- Обработка ошибок. Обвязка с повторами не должна зависеть от формулировок прежнего провайдера.
- Логи и лимиты. Пишите в журнал модель и адрес запроса, ставьте лимит расходов до продакшена.
Почти всё из списка лечится настройкой, но проверять лучше до переключения. После, на живом трафике, за вечер уже не отделаться.
Прямой вендор или российский шлюз
Можно пойти к вендору напрямую. Тогда придётся решать оплату зарубежной картой, держать отдельный аккаунт под каждый сервис и думать, что предъявить бухгалтерии. Для личных экспериментов это рабочий путь. Для продукта компании — лишние звенья, которые ломаются в самый неподходящий момент.
Альтернатива — российский шлюз: одна точка входа к нескольким моделям, оплата в рублях, документы для юрлица. По смыслу это то же, к чему вы привыкли в агрегаторе, только доступ и деньги идут через российскую сторону.
Как это устроено в Китай-API
Мы делаем Китай-API — российский шлюз к моделям DeepSeek, Qwen, GLM и Kimi. Доступ идёт через один OpenAI-совместимый ключ, оплата в рублях, для юрлиц — счёт и закрывающие документы, без VPN. Для кода это тот же приём, что и при переезде с агрегатора: сменить адрес эндпоинта и ключ, остальное оставить.
Сравнение агрегатора и шлюза мы разбирали в статье «Китай-API и OpenRouter», а про доступ за рубли — в материале «API китайских моделей в России».
Что сделать сегодня
- Вынесите адрес, ключ и имя модели в переменные окружения, если они ещё в коде.
- Соберите набор из своих реальных запросов, включая неудобные формулировки.
- Прогоните этот набор через две-три модели и сравните ответы с текущими.
- Переведите сначала один сервис, потом остальные.
- Подключите журнал расходов и лимит до того, как на новую модель пойдёт продакшен.
Переезд с ушедшего агрегатора — это ещё и повод навести порядок в подключении. Когда провайдер вынесен в конфиг, смена модели перестаёт быть проектом.
Платформа Китай-API готовится к запуску. Заявку на ранний доступ можно оставить в Telegram-боте: сообщим, когда откроем доступ первым. Как устроен шлюз, описано на главной странице. Про переезд по шагам читайте в разборе «Миграция с OpenAI на DeepSeek».