Sume queue_admission_unavailable and usage_reservation_unavailable

queue_admission_unavailable and usage_reservation_unavailable mean Sume could not decide whether your paid submit fits, not that it did not fit. Neither is the 402 insufficient_credits balance error and neither is the 429 queue_full capacity error. Nothing was sent to a provider, the half-created job is failed and its hold given back, and the right move is to retry the same submit with the same Idempotency-Key.

What does each code mean?

A paid submit goes through two internal gates before work starts. First the usage reservation puts a hold on the estimated cost. Then queue admission checks the workspace against its accepted-job capacity, which is the concurrency limit plus the queue limit (for example Pro is 4 plus 20, so 24).

usage_reservation_unavailable means the hold could not be placed, for reasons other than an empty balance. The message is "The usage reservation could not be placed. Retry the request." queue_admission_unavailable means the admission check threw twice in a row. The code retries it once, then gives up with "Generation admission could not be evaluated. Retry the request." That error is marked retryable.

Why is it safe to retry?

The job row is created before these gates run, so the code cleans up after itself. On admission failure the row is updated to failed with the retryable error, and the usage hold is refunded. If the refund itself fails because the same database pool is unhealthy, a repair task is scheduled that fails and refunds the orphaned row once the pool recovers. The reservation path does the same kind of repair for a row still queued with no provider task.

The docs state the retry rule for submits in general: use the same Idempotency-Key again so the retry returns the original job and does not bill a second one. A different payload under the same key gives 409 idempotency_conflict, so keep the key tied to one exact request.

How do these errors compare with the ones you already know?

What should a client do?

Treat a submit that errored with no job id as unknown, not as failed. Retry with the identical key and body after a short backoff. If the response is an accepted job, store its id and poll status as usual. If a job shows up as failed with one of these codes, resubmitting is correct, since the error is retryable and the hold was returned. Do not retry in a tight loop: a database that cannot evaluate admission is not helped by more load.

If it keeps happening for minutes, contact support with the request id from the error body, and leave API keys and signed URLs out of the message.