10 static ad variants in one Sume image request: n and its cap

The Sume Image API accepts n from 1 to 10 images per request, but each model has its own cap in the catalog, so ten variants in one call is only possible if the model you choose allows it. Read n.max for the model on GET /v1/images/models before you rely on a number. The docs show a descriptor where n ranges from 1 to 4, which is a reminder that the request cap and the model cap are different things. If your model caps at 4, three requests give you ten.

The rules for n

The Image API field table gives n as an integer with a 1 to 10 request cap plus a per-model cap from the catalog. The catalog descriptor expresses it as a range with min and max under max_images, so a client can read the limit instead of finding out through a 400.

Variants by n or by separate requests

One request with n greater than 1 gives variations of one prompt, which is good for exploring a look but not for testing different headlines, since all images share a prompt. For distinct hooks, send one request per prompt and keep n small. Use the same model, aspect ratio and quality in each so the only difference is the copy.

The stored comparison of the Image API n parameter and a bulk Format run covers the trade-off when you need many images with different instructions.

Feed sizes on the image side

For an Instagram or Facebook feed still, 4:5 is 1080 by 1350. Nano Banana Pro and Nano Banana 2.1 include 4:5 in aspect_ratio, and gpt-image-2 accepts 4:5 too, while Imagen and Grok do not. If you use custom pixels on GPT, the docs require both edges to be multiples of 16, and 1080 and 1350 are not, so a literal 1080 by 1350 will not pass. The nearest exact 4:5 on that grid is 1088 by 1360, since 1088 is 68 times 16 and 1360 is 85 times 16, and 1088 divided by 1360 is 0.8. At 1,479,680 pixels it sits inside the 655,360 to 8,294,400 pixel range.

On Nano Banana, the docs say that 1080x1350 becomes aspect_ratio 4:5 plus a target_pixels value, and the exact 1080 by 1350 is a documented post-step.

curl -sS -X POST https://api.sume.com/v1/images \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"openai/gpt-image-2","prompt":"Product ad: ceramic mug on a desk, clean studio light","n":2,"image_size":{"width":1088,"height":1360}}'

Pricing a set

Ideogram 4.5 has the simplest list price in the docs: $0.03, $0.06 or $0.22 per image for low, medium or high, the same for all sizes. Ten images at medium is $0.60 at list, before Sume pricing, and ten at high is $2.20 at list. Read the live price per model from GET /v1/images/models, since the number you are charged is the Sume rate, not the list rate quoted in the docs.

Before you scale

Run a batch of two with n equal to 2 and look at both images at full size. If text in the image is part of the ad, check every word. Then raise n up to the catalog cap, one request per prompt.

A simple variant plan

Keep the plan boring. Pick one product shot, write five headlines, and send five requests with n equal to 2. That gives ten images, two per headline, and each pair shows how stable the model is on that prompt. If one headline gives unreadable text in both images, the prompt is the problem. If the two images differ widely, the model is, and you should consider a different quality tier.

Name every request with a stable label on your side, and write the label next to the returned image URLs. Image jobs are job-backed like the others, so keep the job id too.

The Image API does not run your A/B test, and it does not check your copy against platform policy. We also did not verify each model's n cap here, since the number lives in the live catalog and can change.