Grok Imagine ignores aspect_ratio on image-to-video; Sume rejects it

On Grok Imagine image-to-video the input picture sets the output shape, and xAI's docs say aspect_ratio is ignored (read 2026-10-10). On Sume the grok-imagine-video-1.5 row is stricter: its request schema rejects aspect_ratio outright, so a script that sends it will fail validation instead of being silently ignored.

The fix is the same on both sides. Crop or pad the still to the shape you want before you upload it.

What xAI says

The xAI video page (read 2026-10-10) states that image-to-video output always matches the input image's aspect ratio and that aspect_ratio is ignored in that mode. For modes without an image, it lists nine ratios: 1:1, 16:9, 9:16, 4:3, 3:4, 3:2, 2:3, 21:9 and 5:2.

So at xAI, sending aspect_ratio with a start image is harmless but pointless. A pipeline that always sends the field works there by accident.

What Sume does

Sume's Grok row only has an image-to-video slot. The schema refinements require exactly one image, supplied as image_url, first_frame_url or a single reference image, and they reject end_image_url, last_frame_url, reference video or audio, bitrate_mode, generate_audio and aspect_ratio. The Video Router capability entry for the row lists no aspect ratios at all.

If your code builds a generic request and adds aspect_ratio for every model, add a branch that omits it for this id. The Video Generation docs say to read each row's supported_aspect_ratios from GET /v1/videos/models before you send the field.

Crop sizes that give the ratio you want

Because the picture decides, produce the still at the target ratio. The sizes below are simple pixel arithmetic for a 1080-pixel short side, not Sume requirements, and the model's output resolution is set separately with resolution.

Crop rather than stretch. Cropping a wide product shot to 9:16 removes the sides, so check that the subject sits in the middle third before you animate it.

If you need a ratio the still cannot give

If you must choose a ratio the picture does not have, the Grok row is the wrong tool on Sume. Seedance 2.5 accepts 21:9, 16:9, 4:3, 1:1, 3:4 and 9:16 in its capability entry, Wan 3.0 accepts 16:9, 4:3, 1:1, 3:4 and 9:16, and Gemini Omni Flash 1.1 accepts 16:9 and 9:16. None of the Sume rows lists 4:5, which another post in this series covers.

Cost is the trade. The Grok row bills a flat $0.0125 per second, while a 5-second Wan 3.0 clip at 720p bills $0.625. A cheap loop with a pre-cropped still is usually the better deal when the framing is under your control.

• Prepare the still at the final ratio.
• Omit aspect_ratio for grok-imagine-video-1.5.
• Use resolution for 480p, 720p or 1080p.

Where the error shows up in real pipelines

The failure usually appears when a team reuses one request builder for several models. A builder written against Seedance or Wan adds aspect_ratio for every call, because those rows accept it. When the same builder targets the Grok row, validation rejects the request before any money is reserved, so the cost of the mistake is a failed call, not a bill.

Put the rule in data rather than in an if-statement: keep a per-model list of allowed fields, seeded from GET /v1/videos/models, and drop anything not on it. That also protects you from size and seed, which Sume rejects for every video model.