Grok Imagine on Sume: 4:5 returns 400, 1080x1350 does not
Grok Imagine has no 4:5 on Sume. aspect_ratio 4:5 returns 400, but 1080x1350 snaps to the nearest native ratio, 2:3. What to send for Instagram portrait.

Grok Imagine does not list 4:5 on Sume, so aspect_ratio: "4:5" on x-ai/grok-image returns a 400. The same shape written as pixels, "1080x1350", is not rejected: Sume snaps it to the nearest ratio on Grok's list, and by the repo's snapping rule that is 2:3, not 4:5. If you need true Instagram portrait, pick a model that lists 4:5.
This is an easy way to ship the wrong crop without an error, so it is worth knowing which spelling does what.
What does Grok list on Sume?
The Grok row publishes thirteen ratios in the Sume catalog, and a code comment beside the list states that it follows Grok's official list and has no 4:5. Sume serves one image per call on this model, with a catalog n range of 1 to 1. The xAI image generation guide says the model edits from up to 5 source images and that image generation is billed flat per image, but the pages I read do not publish a ratio list, so I am not claiming one from xAI.
| Group | Values |
|---|---|
| Landscape | 2:1, 20:9, 19.5:9, 16:9, 4:3, 3:2 |
| Square | 1:1 |
| Portrait | 2:3, 3:4, 9:16, 9:19.5, 9:20, 1:2 |
| Not listed | 4:5, 5:4, auto |
Why does one spelling fail and the other snap?
The request path treats a ratio string and a pixel string differently. A ratio such as 4:5 is checked against the model's list and rejected when it is absent, with the accepted values in the error. A pixel string such as 1080x1350 is parsed as a size first, reduced to a ratio, and then matched to the closest entry on the list.
For Grok the matching rule first drops the 4:3 family when the request is in the 4:5 family, so that 4:5 is never silently turned into 4:3. Nothing on the list is in the 4:5 family, so it picks the closest remaining ratio on a log scale. 4:5 is 0.8; 2:3 is about 0.667 and 1:1 is 1.0, which makes 2:3 the nearer one. The portrait you get is therefore taller and narrower than the one you asked for.
The documented response does not echo the ratio that was used, so check the pixel size of the returned image instead of trusting the request.
What should I send for Instagram portrait instead?
Move the 4:5 job to a model that lists it. On Sume that is the GPT Image family, both Nano Banana rows, the Seedream rows, FLUX.2, Qwen Image and Ideogram V3. The docs also note that 4:5 is Instagram portrait at 1080x1350, not 4:3, and that Nano Banana Pro sends 4:5 natively at about 928x1152 on the 1K tier, with exact 1080x1350 as a post-step.
If you want Grok's look anyway, ask for 3:4, which Grok lists, and crop the top and bottom afterwards to 4:5. Cropping a 3:4 frame to 4:5 removes about 6 percent of the height, so keep faces and text away from the edges in the prompt.
curl -sS https://api.sume.com/v1/images \
-H "Authorization: Bearer $SUME_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"x-ai/grok-image",
"prompt":"A matte ceramic mug on a linen cloth, soft window light",
"aspect_ratio":"4:5"}'
# 400 invalid_request: x-ai/grok-image does not accept aspect_ratio "4:5".
# The error body carries the supported list.How do I catch this before it ships?
Run a check in your pipeline that compares the width and height of every returned image with the shape you asked for, and fail the job when they differ by more than a pixel or two. A pixel-string request that quietly became 2:3 shows up immediately in that check.
Also prefer sending ratios, not pixel strings, to models with a fixed ratio list. A ratio either works or fails loudly, while a pixel string is converted for you. For the models that do take custom pixels, the GPT Image 2.5 1080x1350 rule shows what legal sizes look like.
What does this mean for a multi-model template?
If one template feeds several models, build the request per model instead of sharing a single aspect_ratio string. Keep a small table of the ratios each model lists, read from GET /v1/images/models, and resolve your target shape to the nearest entry yourself. Then you know the ratio that was sent, and you can log it next to the job.
That also makes the Grok behavior visible. A 2:3 frame is fine for a poster and wrong for a feed post, so decide on purpose which one you want, and when the answer is 4:5, route that job to a row that lists it.
Sources
Related posts
More in Models
- Grok Imagine video in Sume: why it needs a start-frame image
Sume's Grok Imagine entry is image-to-video only: it blocks a submit without a start frame, tops out at 10 seconds, and sends no audio or aspect ratio.
- H3 Max 3D to Video: previs to photoreal on fal, not on Sume
fal's H3 Max 3D-to-Video turns a blockout render into photoreal video for $0.50 a request plus per second. Sume lists no such endpoint; what it offers instead.
- H3 Max Insert-Video: add a scene mid-clip on fal, and on Sume
fal's H3 Max Insert-Video adds 5 to 13 s to a source up to 60 s, billed on the new seconds only. Sume lists no such row; here is a trim, generate, join route.
- H3 Max Recast prompt: optional, and what Sume does with one
On Sume, H3 Max Recast runs without a prompt: the 1-4 photos say who to swap in. A prompt is allowed up to 2000 characters. Request body and limits below.
Written by Sume