CONCURRENCY_LIMIT_EXCEEDED: Concurrency limit reached, N job(s) already running

{
  "error": {
    "type": "concurrency_limited",
    "code": "CONCURRENCY_LIMIT_EXCEEDED",
    "message": "Concurrency limit reached: 1 job(s) already running, limit is 1"
  }
}

Too many jobs in flight at once. Unlike the rate limit, waiting a fixed period does not necessarily help — what has to happen is that one of your running jobs reaches a terminal state.

The limits

Tier	Concurrent jobs
Free	1
Pro	5

A job counts as in-flight while it is queued or running. It stops counting the moment it reaches succeeded, failed or canceled.

Why it rejects instead of queueing

A silent queue would be friendlier in the moment and considerably worse in aggregate. An agent that loops on a generation tool looks completely healthy against a queue — every call is accepted — right up until the bill arrives.

Against a hard ceiling, the same loop fails on the very first extra call and the problem is visible immediately. This is the same reasoning behind prepaid credits: the useful property is that runaway consumption is loud.

Handling it

The right response depends on whether you control the other jobs:

• You submitted them and you are waiting on them — this is backpressure working. Collect a result first, then submit. Anything else just spins.
• Something else is holding the slots — cancel what you no longer need. POST /v1/jobs/{id}/cancel refunds the credits in full, so abandoning a render you changed your mind about costs nothing.
• You genuinely need parallelism — Pro raises the ceiling to 5. Below that, batching helps for images: n up to 4 produces four images inside one job, using one slot.

Not the same as RATE_LIMIT_EXCEEDED

Both are 429 and it is easy to conflate them:

	RATE_LIMIT_EXCEEDED	CONCURRENCY_LIMIT_EXCEEDED
Counts	requests per minute	jobs in flight
Clears when	the window passes	a job finishes
Free tier	5/min	1

Check error.code, not the status. See RATE_LIMIT_EXCEEDED.