Долгие операции

Всё, что не укладывается в ~10 секунд — большинство генераций и рендеров — выполняется асинхронно. В ответ сразу приходит задача, а не ожидание:

HTTP/1.1 202 Accepted
Location: /v1/qr/jobs/job_01J9Z4A7R3V5W2XN4V6B0RTC5H
Retry-After: 2

{ "id": "job_01J…", "object": "qr_generation", "status": "running",
  "progress": 0.4, "credits_reserved": 43, "credits_charged": null,
  "result": null, "error": null }

Опрашивайте URL задачи, либо дождитесь вебхука <object>.succeeded / <object>.failed (см. Вебхуки), когда они появятся. status проходит queued → running → succeeded|failed|canceled; credits_charged заполняется по факту завершения — это число, реально списанное с баланса, которое может быть меньше credits_reserved для операций с переменной ценой. Задачи хранятся не менее 7 дней.

Повтор при обрыве — безопасен. Если запрос на старт задачи оборвался уже после того, как она была принята, повтор с тем же Idempotency-Key вернёт ту же задачу вместо запуска второй — вы никогда не получите две задачи (и два списания) из-за одного таймаута.

В MCP вызов инструмента сам ждёт до 25 секунд завершения задачи, прежде чем вернуть объект Job и подсказку вызвать соответствующий <product>_get_job — поэтому быстрая задача ощущается синхронной для агента, а медленная корректно деградирует вместо зависания.

Далее: Идемпотентность · Кредиты