OpenRouter не работает: разбираем все причины и что с этим делать

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

Ещё один частый вариант 402 — списание сорвалось не из-за нехватки денег, а из-за просроченной привязанной карты при автопополнении: сервис пытается списать сумму, карта отклоняет операцию, а на экране всё равно всплывает «недостаточно кредитов», хотя формально проблема на шаг раньше — в способе оплаты, а не в самом балансе.

Ошибка 401 — проблема с ключом API

401 — про авторизацию, а не про деньги: ключ отсутствует в запросе, введён с опечаткой или был отозван вручную в панели управления. В отличие от 402, тут не поможет пополнение баланса — нужно зайти в настройки, проверить, что ключ активен, и при необходимости выпустить новый.

Частый бытовой случай — ключ утёк в публичный репозиторий на GitHub, и его автоматически отозвали в целях безопасности. Если 401 появился внезапно на коде, который ещё вчера работал, первым делом стоит проверить именно это, а не искать баг в собственном приложении.

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

Ошибка 429 — упёрся в рейт-лимит

429 значит, что превышен лимит запросов — по количеству обращений в единицу времени или по объёму токенов. В ответе всегда приходит заголовок `Retry-After` с числом секунд, которое нужно подождать перед повтором — это не рекомендация, а прямое указание от сервера.

На практике проще не ждать первого 429, а закладывать паузу заранее: если пайплайн шлёт запросы пачкой, стоит добавить очередь с задержкой между обращениями и повтор с нарастающим интервалом при ошибке, а не долбить сервер повторными попытками сразу же — от этого лимит только сработает жёстче.

### Почему это особенно бьёт по бесплатным моделям

У бесплатных моделей лимит куда жёстче платных: 50 запросов в день, если на аккаунт никогда не заводили кредиты, и 1000 запросов в день, если хотя бы раз пополняли баланс на 10 долларов или больше. Разработчики, которые тестируют промпты в цикле на бесплатной модели, упираются в это за полчаса активной работы — и это ожидаемое поведение по документации, а не баг агрегатора.

Что означают 502 и 503 у провайдера?

Тут причина не в твоём аккаунте вообще. 502 значит, что провайдер модели — тот же OpenAI, Anthropic или Google — недоступен или вернул невалидный ответ; 503 — что ни один из провайдеров не подходит под условия маршрутизации или все временно перегружены. Если включена фолбэк-маршрутизация, OpenRouter может сам повторить запрос через другого провайдера этой же модели — но только если у модели вообще есть больше одного хостера.

Модели с единственным провайдером такой страховки лишены в принципе: упал единственный, кто её держит, — упала и модель, пока провайдер не восстановится. В этом случае единственный рабочий вариант — временно переключиться на модель с несколькими провайдерами или подождать.

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

Для критичных сценариев разумно закладывать явный список из двух-трёх допустимых моделей заранее, а не полагаться на единственную: тогда при падении основной провайдер меняется одной строкой конфига, а не экстренным патчем посреди инцидента.

Часто спрашивают, когда OpenRouter барахлит

Что означает `error_type` в ответе, если он не совпадает с HTTP-кодом? OpenRouter нормализует ошибки разных провайдеров в общий набор типов — `rate_limit_exceeded`, `context_length_exceeded`, `authentication`, `content_policy_violation`, `server` — чтобы код одинаково обрабатывал сбой что у OpenAI, что у Anthropic, даже если у них разный формат ответа. Смотреть стоит именно на `error_type`, а не только на HTTP-статус.

Почему запрос обрубает по таймауту (408)? Значит, обработка заняла больше отведённого времени — обычно из-за слишком длинного контекста или перегруженного провайдера в моменте. Помогает сократить промпт или переключиться на модель с меньшей нагрузкой.

Ошибка 403 — это точно про модерацию? Почти всегда да: сработал фильтр контента или защита от prompt injection. В `error.metadata` приходит причина и обрезанный фрагмент текста, который вызвал срабатывание, — по нему обычно понятно, что именно не понравилось модерации.

Можно ли получать уведомления, если сервис реально упадёт? Да, status.openrouter.ai поддерживает подписку на обновления статуса, и это надёжнее, чем гадать по симптомам в коде.

Ошибка про слишком длинный контекст — это тоже про OpenRouter? Нет, это ограничение конкретной модели, просто OpenRouter приводит её к общему виду `context_length_exceeded`. У разных моделей разный максимальный контекст, и если код одинаково стабильно работал с одной моделью, а на другой внезапно посыпался именно с этой ошибкой — дело не в сбое сервиса, а в том, что у новой модели окно контекста заметно короче, и её лимит нужно закладывать в логику отдельно, до первого падения в проде.

Не получается оплатить из России

Отдельная категория «не работает» — вообще не про API, а про оплату. OpenRouter принимает карты, крипту и AliPay, но карты российских банков в это «карты» не входят: международный эквайринг для них закрыт, и попытка привязать такую карту в панели просто заканчивается отказом на стороне платёжной системы, а не ошибкой самого OpenRouter.

Рабочих обходных путей два: платить криптовалютой, если есть возможность её купить и вывести, либо оплатить через посредника — тот же SUB.SUP: пишешь в Telegram или ВКонтакте, там оформят пополнение баланса, не трогая ни код, ни архитектуру запросов. Разбираться в этом самостоятельно с нуля, ища криптобиржи и обменники, обычно выходит дольше, чем просто написать в поддержку и получить пополненный баланс.

Отдельная путаница здесь — принять отказ карты за ошибку самого OpenRouter и начать чинить несуществующий баг: менять ключи, переустанавливать библиотеки, перечитывать документацию по API. Если проблема на этапе привязки способа оплаты, а не на этапе запроса к модели, все эти действия бесполезны по определению — дело не в коде.

Если не помогло

Когда статус-страница зелёная, код ключа верный, баланс не нулевой, а модель всё равно не отвечает — есть смысл заглянуть в раздел поддержки на сайте и описать конкретный `error_type` и время запроса, а не общую фразу «не работает». Специфика агрегатора в том, что за одной и той же ошибкой может стоять пять разных причин на стороне пяти разных провайдеров, и без деталей запроса поддержка будет гадать так же, как и ты.

Минимальный набор, который стоит проверить перед обращением в поддержку:

• статус-страница — зелёная или показывает инцидент;
• баланс — не ушёл в ноль и не завис на списании старых кредитов;
• ключ — активен, не отозван, скопирован без лишнего пробела;
• модель — доступна у более чем одного провайдера, если критична стабильность;
• `error_type` в ответе — записан дословно, а не пересказан по памяти.

Держи в голове на будущее: чем сложнее цепочка — свой прокси, фолбэк, несколько моделей в связке, — тем больше точек, где что-то может сломаться не по вине OpenRouter вовсе. Прежде чем винить агрегатор, стоит на секунду остановиться и проверить, не сломалось ли что-то в собственном коде между запросом и ответом.

Из всего разобранного здесь на стороне самого сервиса, по факту, случается редко: почти все жалобы «OpenRouter не работает» на деле оказываются проблемой на одном из пяти уровней — баланс, ключ, лимит, конкретный провайдер или способ оплаты. Ни один из них не требует ждать, пока «починят сервер», — почти всё решается за несколько минут, если знать, в какую сторону смотреть.