RateLimit-заголовки: дайте агентам тормозить вежливо
Что такое стандартные RateLimit-заголовки, зачем они AI-агентам, минимальный пример, правильно vs неправильно, ошибки и как проверить.
Обновлено:
Что это
Стандартные RateLimit-заголовки (IETF draft) сообщают клиенту его квоту прямо в
ответе: сколько запросов осталось и когда счётчик сбросится. Современная форма —
структурное поле RateLimit (с параметрами limit, remaining, reset); раньше
использовались три отдельных заголовка RateLimit-Limit/-Remaining/-Reset.
Зачем это AI-агентам
Агент-автомат не «чувствует» нагрузку, как человек. Без явной квоты он либо
долбит ваш сервер, либо натыкается на жёсткий блок (429) и падает. Машиночитаемый
лимит позволяет агенту тормозить заранее и вежливо: видит remaining: 2 —
сбавляет темп. Это и защита сервера, и предсказуемая автоматизация для клиента.
Минимальный рабочий пример
Современная (структурная) форма:
HTTP/1.1 200 OK
RateLimit: limit=100, remaining=87, reset=42
RateLimit-Policy: 100;w=60
При превышении:
HTTP/1.1 429 Too Many Requests
RateLimit: limit=100, remaining=0, reset=30
Retry-After: 30
Правильно vs неправильно
| Правильно | Неправильно |
|---|---|
RateLimit с limit/remaining/reset на ответах | Нет заголовков — агент узнаёт лимит только по 429 |
Retry-After на 429 | 429 без подсказки, когда повторить |
reset отражает реальное окно | Случайные/неверные значения |
| Консистентно на всех лимитируемых ручках | Только на части эндпоинтов |
Типичные ошибки
- Только
429без RateLimit-заголовков — агент бьётся вслепую. - Нет
Retry-Afterна429— клиент не знает паузу. - Неверный
reset(не то окно/единицы) — агент тормозит не вовремя. - Смешение старого и нового формата без согласованности.
Как проверить
Скан проверит наличие RateLimit-заголовков. Вручную:
curl -sI https://example.com/api/endpoint | grep -i 'ratelimit\|retry-after'
Ждём RateLimit: (или RateLimit-*) на обычном ответе и Retry-After на 429.