192 frames is the only whole second MiniMax H3 can give you

Ask MiniMax H3 for an eight-second clip and you get 8.000 seconds. Ask for seven and you get 7.292. Ask for twelve and you get 12.250. The model is not rounding badly — it is not working in seconds at all.

H3 renders in frame blocks, not in seconds

Every H3 render is a whole number of latent blocks, and the frame count always lands on:

frames = 17n + 5

At 24 fps that fixes the runtime. The duration control in an interface is a request; the grid is what actually gets rendered, and your value is snapped to the nearest legal block. ComfyUI does this snapping visibly — set a duration and watch the frame field jump.

Across the 4–15 second range the API accepts, the whole grid is small enough to print:

One row is bold, and it is the only one that needs to be.

Why exactly one value lands on a whole second

A frame count divides evenly into whole seconds when it is a multiple of 24. So we want:

17n + 5 ≡ 0  (mod 24)
17n     ≡ 19 (mod 24)

Seventeen happens to be its own inverse modulo 24 — 17 × 17 = 289 = 12 × 24 + 1. Multiply both sides by 17:

n ≡ 17 × 19 ≡ 323 ≡ 11 (mod 24)

So the solutions are n = 11, 35, 59, …. The next one after 11 is 35, which is 600 frames, or 25 seconds — well past the 15-second ceiling.

Inside the range H3 will actually render, n = 11 is the only answer. 192 frames. 8.000 seconds. Everything else you can ask for is a fraction of a second long.

When this matters and when it does not

For a single clip going straight to a feed, it does not matter at all. Nobody watching a loop can tell 8.708 seconds from nine.

It starts to matter the moment the clip stops being alone:

• Cutting to music. A bar at 120 bpm is 2.000 seconds. A 10-second request gives you 7.292 or 8.708 — both of them drift against the grid, and the drift compounds across a sequence.
• Stitching clips. Six shots at 5.167 seconds are 31.002 seconds, not 31. Small, but it accumulates into a timeline that never quite lines up with the markers you set.
• Anything with a hard slot. A six-second pre-roll is not a duration H3 can produce. 6.583 is the closest, and it overruns.

If a project has any timing constraint at all, build it out of 8.000-second blocks and trim in the edit. It is the only length the model hands back clean.

The practical version

Three things worth keeping:

1. Ask for 8 seconds when you can. It is free precision — the same cost per output second as any other value, and it is the one that arrives whole.
2. Read the frame count, not the seconds field. Frames are what the model committed to. Seconds are a division you are doing afterwards.
3. Do not fight the grid in the prompt. Writing "exactly six seconds" into a prompt does not change the block size. Timing inside the shot — a beat at 00:04.500, say — is honoured; the total runtime is not negotiable.

The arithmetic above is worth doing yourself. It takes a minute, it needs no source beyond the 17n + 5 rule and 24 fps, and it settles a question that otherwise looks like the model behaving unpredictably.