Grok Imagine on Sume lists 9:19.5 and 9:20 but not 4:5

Sume's Grok Imagine row lists tall phone ratios 9:19.5 and 9:20 and wide 20:9 and 19.5:9, but not 4:5, 5:4 or 21:9, and caps n at 1. Here is what to do.

5 min readSume
All posts

Sume's Grok Imagine image row (x-ai/grok-image) lists 13 aspect ratios, including phone-tall 9:19.5 and 9:20 and their wide mirrors 19.5:9 and 20:9, but it does not list 4:5, 5:4 or 21:9. So it suits full-screen phone art and does not suit a 4:5 feed post without a crop. It also accepts only one image per call, and bills $0.025 per image.

These facts come from the catalog code and the Image API docs read on 2026-10-10. xAI's own image generation guide, read the same day, covers its own model ids and prices; this post does not claim which of them sits behind the Sume row.

The ratio list

Most image rows list the same core: 1:1, 16:9, 9:16, 4:3 and 3:4. The Grok row adds the tall phone shapes that modern handsets use, which the other rows mostly lack. A 9:19.5 image is 0.4615 wide for each unit of height, so it fills a recent phone screen without bars.

The missing 4:5 matters because it is the common portrait feed shape. If you ask for it, Sume returns 400 invalid_request saying the model does not accept aspect_ratio, with a supported array. Do not map 4:5 to 3:4 silently, since that changes the crop.

Grok Imagine row on Sume, catalog read 2026-10-10
SettingValue
Row idx-ai/grok-image
Billed per image$0.025
n range1 to 1
Referencesup to 10
Phone-tall ratios9:19.5, 9:20
Wide ratios19.5:9, 20:9
Not listed4:5, 5:4, 21:9

Using it for phone wallpapers and story art

For a vertical story or a phone wallpaper, ask for 9:20 or 9:19.5 directly. For a set of four variations, send four calls rather than n: 4, which fails because the row caps n at 1. Four calls cost 4 x $0.025 = $0.10, the same as one four-image call on a row with no cap.

If you run the calls concurrently, keep the concurrency modest and handle a 202 job envelope as well as a 200 body: sync requests wait up to 30 seconds and then return a job, and the docs say to check the status code rather than the body shape.

If you need 4:5 as well

Pick a different row for the feed crop. Thirteen rows list 4:5 in the catalog, and the cheapest that takes three references is Qwen Image at $0.025, the same price as the Grok row. For a single pipeline, generate the tall art on Grok and the 4:5 on another row, or generate on Grok at 3:4 and crop, accepting that composition will shift.

  • Send one call per image on the Grok row.
  • Request 9:20 or 9:19.5 for phone-tall art.
  • Request 4:5 only from a row that lists it.
  • Read the supported array in a 400 to pick a valid ratio.

Reading the error when you ask for 4:5

The 400 body is invalid_request with a message that the model does not accept the requested aspect_ratio and a supported array. Treat that array as the row's own answer. Your code can pick the nearest value from it, or fall back to another row, and the choice should be explicit in your logs.

A good pattern is a short table in your config: for each placement (story, feed square, feed portrait, banner) list the rows that can serve it. The Grok row appears under story and wide banners and not under feed portrait.

Cost and concurrency

At $0.025 per image the row is the same price as Qwen Image and cheaper than FLUX.2 Pro at $0.0375. A hundred story images cost $2.50. Because each call returns one image, a hundred images means a hundred requests, so use a small pool of workers rather than an unbounded burst, and expect some calls to come back as 202 job envelopes that you poll through the jobs API.

A quick routing table

Keep the routing decision in data. Story and wallpaper art goes to the Grok row at 9:20. Feed portrait goes to any of the thirteen rows that list 4:5. Wide banner at 20:9 goes to the Grok row. Ultrawide at 21:9 goes to a row that lists it, since Grok does not.

Write that table once, test it against the catalog in CI, and your team stops guessing which row can serve a placement.

Sources

Related posts

More in Models

All Models posts

Written by Sume