Grok API

Лимиты запросов нейросети Грок - Rate limits Grok API

Обновлено:

Обработка ошибки 429 от Grok API, защитные лимиты шлюза и рекомендации при высокой нагрузке.

Как устроены лимиты Grok API Dev

Где действует ограничениеКак оно проявляется
Отдельный API-ключОграничение может применяться к конкретному ключу, не затрагивая остальные.
Одновременные запросыСерия параллельных ресурсоёмких запросов может вызвать 429 для этого ключа.
Общая нагрузка на шлюзПри пиковом трафике gateway может временно замедлять или отклонять новые запросы.
Большие файлы и multimodalЗапросы с тяжёлыми вложениями могут ограничиваться строже, чем обычные текстовые запросы.

Мы не публикуем строгую таблицу ограничений RPM/TPM. Фактическое срабатывание ограничения зависит от API-ключа, параллелизма, размера запросов и текущей нагрузки на шлюз.

Если вам нужен высокий постоянный throughput, напишите в поддержку и опишите паттерн нагрузки.

Обсудить нагрузку с поддержкой ↗

Что делать при ошибке 429

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

Пример возможного ответа

HTTP
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 8

{
  "error": {
    "message": "Rate limit exceeded. Please retry later.",
    "type": "rate_limit_error",
    "code": "rate_limit_exceeded"
  }
}

Текст и поля error могут отличаться. Логика клиента должна опираться прежде всего на HTTP 429 и Retry-After, а не на формулировку message.

  1. 1Ограничьте параллелизм очередью или семафором.
  2. 2Учитывайте Retry-After, если сервер его вернул.
  3. 3Без Retry-After увеличивайте задержку после каждой попытки и добавляйте случайный jitter.
  4. 4Ограничьте число попыток; постоянные 429 должны попадать в мониторинг, а не в бесконечный цикл.