MiniMax H3 at 768p vs Wan 3.0 at 720p: 10 seconds, $0.75 vs $1.25

MiniMax H3 is cheaper for a 10-second clip: $0.75 at its native 768p, against $1.25 for Wan 3.0 at 720p on Sume. The two resolutions are not the same size, though. The catalog says 768p is native and first-class for H3 and that it must not be treated as 720p, so the price gap is partly a pixel gap. Wan wins when you need more than 15 seconds.

Prices at the same lengths

Both models bill per second by resolution. The catalog list is $0.06 per second for H3 at 768p and $0.10 for Wan at 720p. Sume bills list x 1.25, rounded up to the cent.

Arithmetic for the 10 s row

• H3 at 768p: $0.06 x 10 x 1.25 = $0.75.
• H3 Max at 768p: $0.08 x 10 x 1.25 = $1.00.
• Wan 3.0 at 720p: $0.10 x 10 x 1.25 = $1.25.
• Wan 3.0 at 480p: $0.05 x 10 x 1.25 = $0.625, rounded up to $0.63. H3 at 480p is also $0.63.

Where Wan wins anyway

Wan 3.0 accepts 2 to 30 seconds. H3 accepts 5 to 15. If your clip is 3 or 4 seconds, or 20 to 30 seconds, H3 is not an option. The aspect ratio lists differ too: H3 lists adaptive, 21:9, 16:9, 4:3, 1:1, 3:4 and 9:16, while Wan lists auto, adaptive, 16:9, 4:3, 1:1, 3:4 and 9:16, so only H3 takes 21:9. Reference limits also differ: Wan takes up to 10 images, 5 videos and 5 audios; H3 takes 9 images, 3 videos and 3 audios, and charges $0.08 list per image after the first five in reference-to-video.

How to decide

If the clip is 5 to 15 s, any aspect ratio in the shared list works, and 768p is enough, start with H3. If you need 720p or 1080p rows or a longer clip, use Wan 3.0. For H3 Max, the 1080p row is a latent refinement of native 768p rather than a native 1080p render, which the catalog flags. Test one clip of each at your real aspect ratio, because the catalog gives prices and limits, not a quality ranking. The request fields are on Video generation.

Check it before you run it

Every figure above is a catalog list price times 1.25, rounded up to the cent, as of 2026-10-08. Catalogs change, so before a large batch, read the current model entry in the docs and recompute the one line that matters for your case. Write the arithmetic next to the job in your own notes: list rate, seconds or characters, multiplier, rounding. If the result differs from the wallet charge by more than a cent, the catalog entry has changed, and the docs page is the place to find out why.

Run one small job first. Submit a single request with the pinned model id and the settings in the tables, poll the returned polling_url until it finishes, and compare the charge with your estimate. Then scale up. Using a pinned id for the test matters, because sume/auto never names the family, so you cannot tie its charge to the row you priced.