Повторяйте без второй генерации

Используйте ключ идемпотентности для логического запроса и учитывайте публичные заголовки повтора.

Задайте BASE_URL как корневой HTTPS-адрес API без завершающего / и без /v1, а API_KEY передайте из хранилища секретов. OpenAI-совместимые SDK используют ${BASE_URL}/v1, Anthropic-совместимые — BASE_URL.

Передавайте Idempotency-Key, если приложение может повторить запрос генерации после таймаута или потери соединения. Для каждого нового логического запроса создавайте новое непредсказуемое значение и храните его вместе с точными параметрами. При каждом повторе используйте то же значение и те же параметры. В течение 24 часов завершённый дубликат возвращает итог без новой генерации и списания. Новому запросу пользователя нужен новый ключ, даже если текст совпал.

Отправьте и сохраните логический запрос

Передайте процессу API_KEY. В оболочке с OpenSSL один раз создайте случайный ключ; в приложении используйте свой криптографически стойкий генератор UUID или эквивалент. Храните значение идемпотентности и тело запроса в состоянии приложения до терминального исхода. Не помещайте API-ключ или prompt в значение идемпотентности.

bash
export UNLIMGPT_REQUEST_KEY="$(openssl rand -hex 16)"

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

bash
test -n "${UNLIMGPT_REQUEST_KEY:-}" \
  && printf 'Authorization: Bearer %s\n' "$API_KEY" \
  | curl -q -H @- -i "$BASE_URL/v1/responses" \
    -H "Content-Type: application/json" \
    -H "Idempotency-Key: $UNLIMGPT_REQUEST_KEY" \
    -d '{
  "model": "gpt-5.6-sol",
  "input": "Поздоровайся.",
  "max_output_tokens": 64,
  "stream": false
}'

При успехе ожидайте терминальный JSON-ответ. Сохраните HTTP-заголовок request-id для диагностики; он отличается от ID запуска в активности API. Для повтора запускайте только второй блок с тем же значением переменной и неизменным телом. Повторное выполнение команды OpenSSL создаст новый ключ и может начать вторую платную генерацию.

Решите, можно ли повторять

  • Дубликат во время первого исполнения получает временный HTTP 409 с retry-after: 1 и x-should-retry: true. Подождите не меньше указанного времени и отправьте неизменный запрос с тем же ключом.
  • Тот же ключ с другими параметрами даёт постоянный 409 и x-should-retry: false. Это ошибка приложения; новый ключ создавайте только для действительно нового логического запроса.
  • При HTTP 429 читайте retry-after и x-should-retry. Временный лимит частоты допускает повтор после паузы; лимит пакета требует обновления окна или тарифа. Не запускайте цикл повторов при x-should-retry: false.
  • После обрыва потока проверьте активность и последнее нативное событие. Поток может сообщить ошибку после HTTP 200; для безопасного повтора используйте тот же ключ, если клиент поддерживает такое поведение.

Ограничивайте число повторов и общее время ожидания на своей стороне. Не повторяйте автоматически неповторяемую публичную ошибку и не меняйте тело, сохраняя старый ключ. См. потоки, ошибки и лимиты и контекст протокола в Responses.