FLUX API 429 vs Sume 429: rate_limited and queue_full

BFL's errors page gives 429 Too Many Requests one meaning: you exceeded the rate limits for your account. Sume returns two different 429 codes. rate_limited means too many requests in the current window, so back off; queue_full means the workspace has no room for another paid generation job until one finishes or is canceled.

BFL's line is from its errors page; Sume's from Errors and credits and Generation admission, read 2026-10-01.

What does BFL say about 429?

Only one sentence: "You've exceeded the rate limits for your account." The page lists no limit values and no retry header in that entry, so read the response itself and back off.

How do the two Sume 429 codes differ?

Will retrying fix a queue_full?

Not on its own schedule. The docs say Sume cannot accept another paid generation job for the workspace until an existing queued or processing job finishes or is canceled. Concurrency being full is not an error by itself: valid jobs are accepted as queued while queue capacity remains. Concurrency is plan-only and prepaid top-ups do not raise it, so adding funds will not clear it. The docs give queue capacity as max(3, concurrency_limit × 5) by default.

How do I retry safely?

Do not retry unsafe submit requests without an Idempotency-Key. The docs say to back off on 429 and use retry-after when present, and that read, status and list endpoints can also be rate limited, which is polling backpressure rather than generation concurrency. Slow your polling before you assume the queue is the cause. The wider picture is in 429 vs 503.