Nano Banana 2 on Sume: 512 and 1K are $0.10, 2K $0.15, 4K $0.20

Answer

Nano Banana 2 on Sume costs $0.10 per image at 512 and at 1K, $0.15 at 2K and $0.20 at 4K, so 200 images cost $20 at 1K and $40 at 4K. The 512 tier is not cheaper than 1K, which means there is no reason to pick 512 for savings.

These figures come from Sume's estimator in the pricing package: the provider list price times Sume's 1.25 margin, rounded up in USD micros. The catalog row shows the 1K default of $0.10 and the cost scales for 2K and 4K.

Picking a tier

• Draft at 1K, then rerun only the winners at 2K or 4K. The 4K price is exactly double the 1K price on Nano Banana 2.
• On Nano Banana Pro the 2K tier costs the same as 1K, so skip 1K there if you want more pixels for free.
• Nano Banana 2 lists 14 aspect ratios including 21:9, 4:1, 1:4, 8:1 and 1:8, and takes up to 10 reference images. Pro lists 10 ratios and 10 references.

Request

Set the tier with resolution. A model accepts only the tiers its descriptor lists, so a value outside 512, 1K, 2K and 4K returns 400.

curl -X POST https://api.sume.com/v1/images \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"google/nano-banana-2","prompt":"a matte black water bottle on a stone ledge","resolution":"2K","aspect_ratio":"4:5"}'

Slow settings can exceed the 30-second sync wait and come back as 202. Check the status code before you read the body. Reference: Sume Image API docs.

Budget examples

A 40-image storyboard at 2K costs 40 x $0.15 = $6.00. The same storyboard drafted at 1K and finished at 4K for 8 shots costs 40 x $0.10 + 8 x $0.20 = $5.60, which is cheaper and gives you four times the pixels where it counts.

Failed or cancelled generations are not billed, so a retry loop does not stack charges. A completed image is billed in full, and a response that arrives later through a 202 job is billed once, on completion.

Before a large run

Prices and descriptors change when the catalog changes, so confirm them before you spend. Call GET /v1/images/models/{id}/endpoints for the row you plan to use and read its pricing line and supported_parameters; both come back in one response.

Then run a pilot of three to five images and read usage.cost on each response. Multiply by your planned count for a forecast you can trust. Completed generations are billed in full and failed or cancelled ones are not, so a pilot that errors costs nothing.

For big batches, use mode: "async" or mode: "webhook" with a public HTTPS webhook_url, so no request waits on the 30-second sync limit. Poll GET /v1/jobs/{id}/status and fetch GET /v1/jobs/{id}/result when the job completes.