MiniMax H3 Max bills per second of output. It does not bill per second of render. Those are two different clocks, they produce two different numbers, and conflating them is the most expensive habit you can carry over from GPU-rental thinking.
A 5-second clip at 768P costs the same whether the queue hands it back in four seconds or forty. The render clock does not appear on the invoice at all.
Anyone who has rented a GPU by the hour has the opposite instinct wired in: slow work is expensive work, so you optimise for throughput first. On a per-output-second endpoint that instinct is simply wrong, and acting on it costs you money in a roundabout way — you pick a faster configuration when the slower one was free, or you avoid iterating because you unconsciously price the wait.
Here is the actual cost structure, list price, launch promotion excluded:
| What you change | Effect on the bill |
|---|---|
| Clip length, 5 s → 15 s | 3× |
| Resolution, 480P → 768P | 1.6× on the Turbo post-train |
| Takes, 1 → 8 | 8×, every take billed |
| Render time, 4 s → 40 s | none |
Three multipliers and one non-multiplier. The three that count are all decided before you press the button; the one that feels expensive while you sit there is the one that costs nothing.
It is a UX number, and it decides something the invoice never sees: whether you try the idea again.
That is not a soft claim. The gap between a four-second turnaround and a forty-second one is the gap between changing one line and re-running, and going to make coffee. The first behaviour produces five variants in the time the second produces one, and at a fixed price per output second, five variants of a 5-second clip cost exactly five times one — no queue surcharge, no priority fee, no per-generation charge to amortise.
So the render clock belongs in the design conversation and not in the budget spreadsheet. Both are real. They are not the same document.
Exactly one place: timeouts. If your client gives up at 5 seconds and the work completes at 8, you have paid for output you then threw away. That is the render clock reaching across and touching the bill, and it is entirely self-inflicted.
Size the timeout off the tail, not the middle — a median is a poor basis for a deadline, which is the subject of the next note.
Cost is rate × seconds × takes. Nothing else enters. At the Turbo rung, 768P:
5 s × 1 take × $0.04 = $0.20
15 s × 1 take × $0.04 = $0.60
15 s × 4 takes × $0.04 = $2.40
15 s × 8 takes × $0.04 = $4.80
There is no per-generation fee to add, and a run that fails validation never reaches the meter at all. Every gap between the numbers above comes from a parameter you chose. None of it comes from how busy the hardware was.
Per-second rates, the takes multiplier and the zero per-generation fee are published as dated limits on the MiniMax H3 Max specifications page. The plan-level view of the same arithmetic — what a generation costs and what a finished clip costs once you allow for retakes — is laid out where you can see what a MiniMax H3 Max clip actually costs.