Two latency figures are published for the instant lane on MiniMax H3 Max, and reading them as one number is how you end up with a timeout that fires on a request that was going to succeed.
| Figure | Value | What it covers |
|---|---|---|
| Median (p50) | 4.6 s | the instant lane, across configurations |
| p95 | 7.9 s | the same lane, the slowest one run in twenty |
| p50, scoped | 6.9 s | a 5-second clip at 768P specifically, over 22 runs |
The third row is the one that catches people out. It is not a contradiction of the first — it is a different denominator. A lane-wide median mixes 480P with 768P and short clips with long ones. Fix the configuration and the median moves. Both numbers are honest; neither is usable without its scope attached.
7.9 ÷ 4.6 ≈ 1.7×. One request in twenty takes roughly seventy percent longer than the typical one.
That ratio is the number to design against, and it is well behaved as these things go — a 1.7× p95/p50 spread is a queue that is mostly doing one thing, not one that is quietly falling over. What it is not is a ceiling. p95 says nothing about the other 5%, and the tail beyond p95 is where the interesting failures live.
1. Size timeouts off the tail, never off the median. A median of 4.6 s means half of all requests are still running at 4.6 s, so a client that gives up at 5 seconds is abandoning a large fraction of work that was about to succeed — and on a per-output-second endpoint, paying for whatever completed after it stopped listening. Take p95, double it, and you have a defensible client timeout with room for the tail you cannot see.
2. Show a progress state after the median, not after the timeout. The user's patience clock starts at zero, not at 4.6 seconds. If nothing on screen changes for eight seconds, the request has failed as far as they are concerned, whatever your logs say.
3. Quote your own p95 to your own users, not the vendor's p50. Your number includes your upload, your queue and your network. It is always worse, and it is the only one your users experience.
"22 runs" is small, and publishing it is the point. Twenty-two samples give you a serviceable median and a p95 that is really just "the second-slowest run I saw" — with n = 22, the 95th percentile is being estimated from one or two observations.
So treat a scoped p50 from a couple of dozen runs as a good planning number and a bad SLA. Any latency figure quoted without its sample size and its configuration should be read as marketing rather than measurement, including when the number is flattering.
The bill. Render time does not enter the price of a generation on this model — you are billed per second of output, not per second of waiting. Latency is a product constraint and a UX budget; it is not a cost line. That separation is what makes it safe to iterate quickly here, and it is the subject of the previous note.
Both figures are published on the front page of minimaxh3max.video, measured on that site rather than taken from an upstream inference timer, with the scoped figure carrying its run count. The lane itself is the throughput-tuned post-train — what "Turbo" actually refers to on this model is worth reading once if you are choosing between the engines, because the naming is the confusing part, not the pricing.