# Ошибка 429 в OpenRouter: лимиты, очередь и повтор запроса

Что делать при OpenRouter 429: определить источник ограничения, проверить заголовки и очередь, сократить параллелизм и настроить ограниченный повтор с Retry-After.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/openrouter-429-error/
Language: ru

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

В этой статье рассматривается диагностика по официальной документации на 1 ноября 2026 года. Конкретные лимиты зависят от выбранного продукта, модели и состояния доступа.

## Сохраните признаки одного отказа

[OpenRouter Errors and Debugging](https://openrouter.ai/docs/api_reference/errors-and-debugging) описывает 429 и возможный заголовок `Retry-After`. Запишите время, статус, безопасные поля `error`, выбранную модель и идентификатор операции, если он получен. Полный ключ и пользовательский документ для такого отчёта не требуются.

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

## Проверьте режим использования

[Документация лимитов](https://openrouter.ai/docs/api_reference/limits) различает ограничения сервиса. Для бесплатных моделей особенно важно сверить действующие правила, а не переносить цифры из старой инструкции. Новый API-ключ сам по себе не увеличивает общую доступную частоту аккаунта.

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

## Следуйте времени повтора

Если ответ содержит `Retry-After`, учитывайте его в логике ожидания. Если заголовка нет, используйте ограниченную стратегию с увеличивающейся паузой и случайным разбросом, подходящую вашему приложению. Назначьте максимальное число попыток и общий срок задачи.

| Ситуация | Следующий шаг |
| --- | --- |
| Кратковременный всплеск | Уменьшить одновременные вызовы и сохранить очередь |
| Повторяющийся предел выбранного режима | Пересмотреть расписание и допустимый маршрут |
| Истёк общий срок пользовательской задачи | Завершить её понятным отказом |
| Непонятный источник 429 | Сопоставить журналы соседних компонентов |

Очередь тоже должна иметь предел. Иначе ограничение внешнего API превращается в бесконечно растущий список задач внутри вашего приложения.

## Проверьте восстановление

Условный пилот начинает с одного последовательного запроса, затем осторожно повышает параллелизм. Цель — увидеть момент отказа и возврат нормального поведения, а не создать нагрузку на чужую платформу. Используйте согласованные ограничения и небольшой тестовый набор.

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

## Свяжите результат с мощностью GPU

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

Далее полезны [планирование мощности](/ru/journal/inference-capacity-planning/) и [лимиты бесплатных моделей](/ru/journal/openrouter-free-model-limits/). Расширение пула обсуждается на основании измеренного профиля нагрузки, а не одного статуса ошибки.