Ideogram API 402 inflight_limit: fast vs slow queue, and Sume

On Ideogram 4.5, a 402 (or 429) body can carry reject_reason: "inflight_limit", meaning you already have too many generations in progress; max_inflight_requests gives the cap and task_completion_speed says whether the fast or slow queue applied. Sume handles concurrency differently: extra jobs are accepted as queued, and only when queue capacity is full does it return 429 queue_full. In Sume's documented errors, 402 means insufficient_credits.

Ideogram facts are from its Ideogram 4.5 reference; Sume facts from generation admission and errors and credits, read 2026-10-01.

What does the Ideogram error body contain?

Both 402 and 429 use the same shape: error (a message) and reject_reason, one of insufficient_funds, subscription_required, daily_limit, priority_credit_required, inflight_limit or feature_limit. For inflight_limit two more fields appear: max_inflight_requests and task_completion_speed (fast or slow). So a 402 is not always about money: read reject_reason first.

How does Sume treat concurrency?

The docs call concurrency a dispatch limit, not a submit limit. If a workspace is at its generation concurrency, Sume can still accept more jobs as queued while queue capacity remains. Concurrency is plan-only; top-ups do not raise it. When the queue is full, new paid submissions fail with 429 queue_full.

How should my retry logic differ?

Do not blindly retry a 402 on Sume; the balance has to cover the request first. For queue_full and rate_limited, back off and retry, with an idempotency key so a retry cannot queue a second paid job. On Ideogram, inflight_limit clears when your running generations finish, so limit your own parallelism to max_inflight_requests. The Sume equivalents for other vendors are in BFL 402 and 429 retry rules.

Do I need to cap parallelism on Sume?

Not to avoid errors until the queue fills: queued jobs wait and are moved to processing under the per-workspace guard. Submit rate limits are separate, and the docs tell you to treat read and status limits as polling backpressure. Do not treat queued as failure.