MiniMax H3 2K and 4K upscale on Sume: H3 accepts them, H3 Max does not

Yes: minimax-h3 takes resolution: "2K" or "4K" on Sume, billed as upscales of the native 768p output, while minimax-h3-max does not offer either. The Video generation docs say native resolutions for H3 are 480p and 768p and that 2K and 4K upscales are priced if requested; the API reference adds that 2K and 4K are MiniMax H3 upscale SKUs, not H3 Max.

The catch is discovery. The capabilities list for minimax-h3 shows only 480p and 768p, so a client that validates against supported_resolutions will never offer 2K or 4K. The request path checks a wider set for this one id, so a direct request with the upscale value is admitted.

What each H3 id accepts

The table lists the values the catalog code admits per id. minimax-h3-max reaches 1080p through what the docs call latent refinement from native 768p, and it stops there.

Casing matters: the schema lists 2K and 4K with an uppercase K. The lowercase 4k is an alias only on gemini-omni-flash-1.1; everywhere else the API reference says it is rejected in v1.

What a 2K or 4K clip costs

The minimax-h3 catalog line dated 2026-08-25 lists $0.05 per second at 480p, $0.06 at 768p, $0.13 at 2K and $0.16 at 4K. Sume bills list × 1.25 and rounds up to the next cent per the catalog formula. Durations run 5 to 15 seconds.

Worked out: 5 s at 2K is 5 × $0.13 = $0.65 list, × 1.25 = $0.8125, so $0.82. 10 s at 2K is $1.30, × 1.25 = $1.625, so $1.63. 15 s at 2K is $1.95, × 1.25 = $2.4375, so $2.44. At 4K the lists are $0.80, $1.60 and $2.40, which become $1.00, $2.00 and $3.00 exactly.

Deciding whether the upscale is worth it

At ten seconds, the step from 768p to 2K is $0.75 to $1.63 and the step to 4K is $2.00, so a 4K final is roughly two and two-thirds the cost of the 768p draft. That is a fair price when the clip goes on a large screen and a poor one for a vertical social clip that platforms recompress anyway.

If you only need sharper delivery and not a different model, also compare minimax-h3-max at 1080p, which the docs describe as a latent refinement from native 768p. It is a separate id with its own rate card, and the catalog notes say to inspect opening frames of 1080p image-to-video clips before assembly, so budget a review step for either route.

A draft-then-upscale routine

The 768p row works out as 5 × $0.06 = $0.30 → $0.375 → $0.38; 10 s is $0.60 → $0.75; 15 s is $0.90 → $1.125 → $1.13. So a ten-second 4K final costs $2.00 against $0.75 for the 768p draft. Draft at 768p, and only request 2K or 4K for the clip you will actually publish.

One caution: the upscale is a separate request on the same prompt, not a free re-render of the draft you liked. Without a seed (no Video Router model accepts one, per the Video generation docs), the 4K request generates a new clip, so review the result rather than assuming it matches the draft.

Sending the request

``bash curl -X POST https://api.sume.com/v1/video-router/generate \ -H "Authorization: Bearer $SUME_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: h3-4k-001" \ -d '{ "model": "minimax-h3", "prompt": "Slow push-in on a ceramic mug, steam rising", "resolution": "4K", "duration": 10, "mode": "async" }' ``

Swap the model for minimax-h3-max and the same body fails with an unsupported resolution error, since its admitted set is 480p, 768p and 1080p.