Smallest square GPT Image 2.5 accepts on Sume: 816x816

The smallest square that GPT Image 2.5 accepts on Sume as a custom image_size is 816x816, which is 665,856 pixels. 800x800 is 640,000 pixels, below the 655,360 floor. 810x810 clears the floor at 656,100 pixels, but 810 is not a multiple of 16. If you want a small square, ask for 816x816 and shrink it yourself.

Why 816

Two documented rules meet here. The total must be 655,360 to 8,294,400 pixels, and both edges must be multiples of 16. The square root of 655,360 is about 809.5, so the first multiple of 16 above it is 816 (51 x 16).

Sume's docs and the OpenAPI schema spell the rules out (as of 2026-10-08): Both edges must be multiples of 16, the longest edge is at most 3840, the aspect ratio is at most 3:1, and the total is 655,360 to 8,294,400 pixels.

A tiny asset is not a cheap one

Going small does not lower the pixel floor, and GPT Image 2.5 rows are billed from image tokens rather than a flat price. If the goal is a 256 px or 512 px icon, a flat-priced row is simpler to budget. Nano Banana 2.1 lists a 512 resolution tier (the catalog normalizes 0.5K to 512), and its listed price is a per-image line.

For a fixed-price check, read the endpoint record. It prints the billable line that your wallet is charged, with the Sume margin included.

curl https://api.sume.com/v1/images/models/google/nano-banana-2.1/endpoints \
  -H "Authorization: Bearer $SUME_API_KEY"

Validate in code

Run the same check before you submit so a bad size never leaves your app.

def legal(w, h):
    px = w * h
    return (w % 16 == 0 and h % 16 == 0 and max(w, h) <= 3840
            and max(w, h) / min(w, h) <= 3 and 655_360 <= px <= 8_294_400)

for w, h in [(800, 800), (810, 810), (816, 816)]:
    print(w, h, w * h, legal(w, h))

The smallest size at other ratios

The floor is a pixel count, so the smallest legal size changes with the ratio. 1024x640 is exactly 655,360 pixels, the floor itself. 1280x720 is the smallest legal 16:9. The table is computed by stepping each ratio up until all rules pass.

What to do with a rejected size

Sume does not round a custom size for you. The OpenAPI text says custom sizes are validated against the pixel box, so treat a failed validation as a client bug and fix the size before the call. Round up to the next multiple of 16 on each edge, then recheck the total. If you only need a small final image, request the legal size and downscale the result, because the downscale is free and the rejection is not recoverable inside the request.

Named presets are a separate path. The schema says named presets are not validated against the custom box, so square and square_hd skip this check, and you can use them when you do not need exact pixels.