How Sume bills an image batch: list price times 1.25, worked out

A Sume image batch costs the provider list price times 1.25, times the number of images. The usage.cost field in the response is that billed amount, and the endpoints route publishes the per-image line that already includes the margin. The margin ratio is 1.25 in the repository pricing code, and the catalog formula reads list × 1.25 → ceil usd cents.

That makes batch cost easy to predict, as long as you read the right field. This post works four batches by hand and shows how to confirm them against the live endpoint.

Four worked batches

List prices below come from the repository pricing tables on 2026-10-08. Ideogram 4.5 list prices ($0.03, $0.06, $0.22 by quality) match the Fal page. Treat per-image numbers as before any cent rounding on the total.

Check it before you spend

Call GET /v1/images/models/{id}/endpoints. Each endpoint carries pricing: [{billable, unit, cost_usd}], and cost_usd is what Sume charges. Docs state that you pay cost_usd × n. Compare that against the one-image usage.cost from a first request, then multiply.

Rules that change the total

• Failed or cancelled generations are not billed. A 502 from the sync wait means no charge.
• n is capped per model; read the n range from the catalog. Grok Image is capped at 1.
• Some rows price by setting: Nano Banana 2.1 by resolution, Ideogram 4.5 by quality, GPT Image 2.5 by size and quality.
• If you omit quality on Ideogram 4.5 the request runs at medium, which is the middle price.

A worked budget

Say you need 300 social images and expect to keep one in three. On Qwen Image that is 300 times $0.025, or $7.50 for the full set, and the keepers cost $0.075 each. On Nano Banana 2.1 at 1K the same plan costs $30.00, so each keeper costs $0.30. The point of the arithmetic is not that the cheaper row wins, but that you can price the plan before the first request.

Run a ten-image pilot first. Multiply the observed usage.cost by the planned count and add a margin of your own for retries on slow jobs, because a request that falls back to 202 and finishes later is billed the same as one that finished inside the sync wait.

Common billing mistakes

Teams most often misread three things. They copy a vendor page price and forget the 1.25 factor. They forget that n multiplies the line. And they compare a 1K price against a 4K price when they switch rows. Keep a small sheet with row, setting, billed per image and image count, and fill it from the endpoints route, not from memory.

For a recurring job, store usage.cost next to each output file. A month later you can answer what a given campaign cost without recomputing from list prices that may have moved.

What Sume does not do

Sume does not offer a volume discount tier in the image docs, and token counts in usage are always 0 because images are metered per image. The Nano Banana 2.1 Gemini API also has a half-price batch mode at Google; Sume does not pass that through, so do not apply Google's batch rate to a Sume bill.