concurrency_limit_exceeded — concurrent task slots are full

The fourth of the five 429 sources. The body has only message and reason; there is no Retry-After header.

What is limited is neither the number of requests nor the generation volume, but the number of your orders IN PROGRESS AT THE SAME TIME. A batch of hundreds of orders sent in one burst hits exactly this limit — even with completely free quotas and no rate limit at all.

Wait for YOUR OWN active orders to finish — that takes minutes, not until the end of the billing period: a retry right after any of them reaches a terminal status will go through. Pauses between requests do not help: a slot is freed by a finished task, not by silence on the wire. The right client design is a queue with a cap on the number of concurrent orders, not exponential backoff.

GET /usage — the entry with limit_type: "concurrent" shows the ceiling and the current active count (its period_start/period_end/resets_in are null: this kind of limit has no period). What exactly is occupying the slots — GET /orders?status=in_progress. It is more convenient to catch a slot being freed via a WebSocket event than by polling.

• Guide: limits and the 429 code
• Guide: the async model
• GET /usage
• GET /orders
• Account limits