concurrency_limit_exceeded — заняты слоты одновременных задач

Четвёртый из пяти источников 429. Тело — только message и reason, заголовка Retry-After нет.

Ограничено не число запросов и не объём генерации, а количество ваших заказов В РАБОТЕ ОДНОВРЕМЕННО. Пачка из сотен заказов, отправленная залпом, упирается именно сюда — даже при полностью свободных квотах и без всякого rate-limit.

Ждать завершения СВОИХ активных заказов — это минуты, а не конец расчётного периода: повтор сразу после того, как любой из них ушёл в терминальный статус, пройдёт. Паузы между запросами не лечат: слот освобождает завершённая задача, а не тишина в канале. Правильная форма клиента — очередь с ограничением на число одновременных заказов, а не экспоненциальный backoff.

GET /usage — запись с limit_type: "concurrent" показывает потолок и текущее число активных (у неё period_start/period_end/resets_in равны null: периода у такого лимита нет). Что именно занимает слоты — GET /orders?status=in_progress. Освобождение слота удобнее ловить событием по WebSocket, чем поллингом.

• Гайд: лимиты и код 429
• Гайд: асинхронная модель
• GET /usage
• GET /orders
• Лимиты аккаунта