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

Повтор безопасен не для каждой ошибки. Сначала определите, был ли запрос принят, начался ли результат и является ли причина временной; только затем решайте, отправлять ли тот же запрос снова.

Повторяйте автоматически только непринятый запрос

Сетевой сбой может произойти после того, как запрос был принят и начал выполняться, поэтому отсутствие HTTP-ответа или видимого результата не доказывает, что работа не началась. Запускайте автоматический повтор только когда известно, что запрос не был принят. Во всех остальных случаях проверьте Использование, время запроса и точный идентификатор модели, затем примите явное решение о повторе без слепого воспроизведения. Ошибку 400, неверный ключ, недостаточный баланс, отсутствие права или несовместимый параметр нужно исправить, а не повторять.

Используйте ограниченную экспоненциальную задержку:

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

Значения этих границ выбирает клиент для своей задачи. Они не являются обещанием времени восстановления сервиса.

Автоматический повтор допустим только при подтверждённом непринятии запроса.

Отличайте лимит расходов от временного 429

При 429 сначала прочитайте публичный код. API_KEY_SPEND_LIMIT_EXCEEDED означает, что сумма списаний, активных резервов и оценки нового запроса превысила лимит ключа. Дождитесь resetAt из ответа или измените лимит в API-ключах; экспоненциальная задержка не создаёт новый бюджет.

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

Проверяйте контекст и предел ответа

Размер контекста и максимальный ответ зависят от точного идентификатора модели. Получайте context_length, опубликованный предел ответа и supported_parameters из текущего каталога или GET /v1/models.

Контекст включает сообщения и другие входные данные текущего запроса; API не добавляет историю прошлых запросов автоматически. Передавайте только одно поддерживаемое поле ограничения ответа: max_tokens или max_completion_tokens. Ошибки context_length_exceeded, max_output_tokens_exceeded и OUTPUT_TOKEN_LIMIT_EXCEEDED требуют изменить вход, предел или настройку модели, а не повторить прежнее тело.

Учитывайте разные стадии тайм-аута

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

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

Обрабатывайте прерванный поток отдельно

Chat Completions считается завершённым после [DONE], а Messages — после message_stop. Закрытие соединения раньше означает неполный результат. Запишите последнее событие, модель, время и идентификатор запроса при наличии, но не запускайте автоматический повтор после полученной части результата.

После завершения обработки без подтверждённого результата или данных об использовании резерв освобождается без списания за использование. Если часть потока уже доставлена или использование подтверждено, эта часть может быть оплачена. Точный срок изменения резерва не обещается; проверяйте Баланс и Использование.