Лимиты запросов

Лимит

Область действия	Лимит
На один API-ключ	60 запросов в минуту

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

Этот лимит существует прежде всего как защита от вышедших из-под контроля циклов — цикла повторов без задержки, бага, который отправляет запрос на каждое нажатие клавиши, — а не как значимый потолок для легитимного использования. Обычный трафик приложения, даже довольно активное использование чата, остаётся заметно ниже него.

Превышение лимита

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

HTTP/1.1 429 Too Many Requests

{"error": {"message": "Rate limit exceeded. Please slow down and retry.", "type": "rate_limit_error"}}

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

Правильное снижение частоты запросов

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

# Python: минимальный повтор с экспоненциальной задержкой
import time

for attempt in range(4):
    try:
        response = client.chat.completions.create(model="tai-4.1", messages=messages)
        break
    except Exception as e:
        if attempt == 3:
            raise
        time.sleep(0.5 * (2 ** attempt))

Официальные SDK OpenAI уже реализуют поведение повтора с нарастающей задержкой именно для такого рода временных ошибок по умолчанию; если вы используете один из них, это, скорее всего, уже обрабатывается за вас без дополнительного кода, и вы увидите брошенное исключение только после исчерпания его собственного бюджета повторов.

Если 60 в минуту — это действительно мало

Для большинства приложений объём запросов естественным образом ограничен тем, насколько быстро человек или агентный цикл вообще может генерировать запросы, и 60 в минуту редко становится реальным ограничением. Если легитимный сценарий использования стабильно упирается в лимит, первое, что стоит проверить, — можно ли пакетировать или объединять запросы, отправляя меньше более крупных запросов вместо множества мелких для одной и той же задачи, прежде чем предполагать, что нужно менять сам лимит.