Ideogram 4.5 four images in one request: what Sume reserves

A request for four Ideogram 4.5 images reserves $0.15 of balance at low quality, $0.30 at medium and $1.10 at high on Sume. The reserve is the per-image price times the image count, taken when the submit is accepted. If your spendable balance is below it, the submit fails with 402 insufficient_credits and no provider work starts.

Why does a four-image request need a hold at all?

Sume bills paid generation in two steps. At submit it reserves the estimated amount; on successful completion it captures the usage; if the job fails or is canceled before capture, the reservation is released or refunded. The generation admission doc lays out the sequence and the 402 that guards it.

The image docs add the billing rule for image endpoints: a completed generation is billed in full, a failed or canceled one is not billed, and the endpoint's pricing line is already the wallet amount, so cost_usd x n is what you pay.

What does the hold look like at each quality?

The Sume prices per Ideogram 4.5 image are $0.0375 at low, $0.075 at medium and $0.275 at high. Multiply by the image count in one request.

The table shows the hold for one to four images. These are computed with the image-router estimator in the clone's provider-pricing package.

What happens when the balance is a little short?

Say your balance is $1.00. Three high images reserve $0.825 and fit. A fourth high image would bring the hold to $1.10, above the balance, so a four-image high request returns 402 insufficient_credits, while the same request at medium ($0.30) goes through.

The usual fixes follow the admission doc: wait for funds or top up in the dashboard, or submit a cheaper request. Two requests in a row also count: while the first is processing, its hold is still open, so a second request is checked against what is left.

Is one request for four images different from four requests?

The price is the same: four images cost four times the per-image price either way. The difference is the hold and the failure mode. One request for four high images needs $1.10 free at once, and the endpoint bills only completed generations in full. Four single-image requests each need $0.275 free when they are submitted, so a short balance fails the later ones instead of the whole set.

If you send several requests, give each its own Idempotency-Key and reuse a key only for an exact retry. The admission doc says a reused key with a different payload returns 409 idempotency_conflict, and that a failed admission releases its reservation. That makes retrying after a 402 safe once the balance is topped up: nothing was held, and nothing ran.

There is also a plan limit to keep in mind. A request that is valid but finds the workspace at its processing limit is accepted as queued rather than rejected, and its estimate is still reserved. Queued work therefore counts against balance before it starts.

How do I see the hold and the final charge?

GET /v1/usage lists reserved, captured and refunded ledger rows, and GET /v1/balance shows the balance. Filter the ledger with job_id to fold one generation into a summary with debited, held and refunded amounts. Held amounts are not spend yet; only debited is.

Confirm the live per-image prices on the API pricing page before sizing a budget, since the numbers here are a read from 2026-10-03.