CometAPI’s comparison article “MiniMax H3 Max vs MiniMax H3: The Ultimate 2026 Comparison”, published September 22, 2026, draws a line that matters more for a self-hosting decision than any of its speed or leaderboard numbers. It gives H3 a native short-edge 768p default, puts 2K (the 2560x1440 class) behind “a dedicated regeneration stage (H3-Regenerate-2K)” in the hosted pipeline, and states that “Self-hosted open weights remain at 768p.”
That comparison is a secondary write-up rather than MiniMax or fal documentation, and every figure below is taken from it, so the claims this post leans on are worth confirming against MiniMax’s own release materials. Read at face value, it answers the first question to ask before planning hardware around a 33B dense model: what is in the open release, and what stays on the hosted side?
What shipped
According to the comparison, MiniMax released H3 in late July 2026, and the open weights followed on August 3, 2026 under a community license “with certain territorial considerations.” H3’s foundation is a 33B dense H3-Omni-Transformer, the open release includes the FL2VA (first/last-frame focused) and Ref2VA (reference-heavy) transformer variants, and the comparison table sums up H3’s open-weight positioning as “H3-Base checkpoints released.”
The capability list it gives for H3 is broad: native short-edge 768p, 4-15 seconds at 24 fps, 32 kHz stereo audio generated jointly with the picture, aspect ratios from 21:9 to 9:16, and conditioning that runs from text-to-video through first-frame, last-frame, or first-and-last-frame image-to-video to omni-reference with up to 9 images, up to 3 video clips of 2-15 s each (totaling no more than 15 s), and up to 3 audio clips that must accompany visual references.
H3 Max came later from the same base. CometAPI’s comparison describes it as a post-trained derivative of the open-weight H3 base, developed by fal Research with MiniMax and released around August 27, 2026, with 480p and 768p native output. Its table lists H3 Max’s open-weight positioning as “Hosted post-trained H3 variant” and gives hosted APIs as its only availability; nothing in the article describes H3 Max weights as released.
The ceiling comes with the weights
The resolution section gives the reason self-hosted H3 stops at 768p: “The 2K pipeline on hosted H3 is a second-stage regeneration that uses the original context; it is not part of the open weights.” The next sentence is the one to read closely: “Consequently every post-train derived from those weights—including H3 Max—caps at 768p.”
Taken literally, “every post-train” covers more than fal’s derivative; it would also cover a post-train you run on FL2VA or Ref2VA yourself. That is my reading of the sentence, not a result the article reports for any custom run. One qualification sits next to it: the table lists “1080p latent refinement” as H3 Max’s higher-resolution workflow, and the H3 Max section says some platforms mention limited 1080p refinement options, while holding that “the structural ceiling remains below full 2K because the regeneration stage is not part of the open weights.” Whatever that 1080p option is, the comparison does not present it as a route to 2K.
If your deliverables need 2K
The only route to the 2560x1440 class the article documents is H3-Regenerate-2K, and it places that stage in the hosted pipeline, outside the open release. My inference from those two statements is that the open weights cannot produce a 2K master by themselves, so 2K output keeps hosted H3 in the pipeline. The comparison does not say whether any other host offers an equivalent stage, which is the limit of that reasoning. Its routing advice points the same way: standard H3 is “the stronger fit when the workflow depends on 2K final output.”
On cost, CometAPI’s comparison quotes official MiniMax rates as of mid-September 2026 and says pricing depends on the platform. Its per-second rate for 2K output from hosted H3 is about $0.13/s. It does not break out a separate price for the regeneration stage, so that is a rate for 2K output, not a documented cost for the stage itself.
The article also sketches a two-stage workflow: “H3 Max can be used for fast concept iteration and candidate generation, while selected ideas can move into a standard H3 workflow when 2K regeneration, editing, or deeper multimodal conditioning becomes necessary.” As written, the iteration stage is H3 Max, which the table lists as a hosted variant, and 2K regeneration is documented only in the hosted pipeline. It does not place FL2VA or Ref2VA in the iteration role, and while it says the regeneration “uses the original context,” it does not say whether that context can come from a generation run on your own hardware. A local-generation, hosted-finish split is not something this material establishes.
If 768p is enough
Here the resolution ceiling stops being the deciding factor. The comparison says “The open weights enable local deployment, research, and custom post-training,” and FL2VA and Ref2VA are the variants it names in the open release. My reading is that for a team whose delivery specs stop at 768p, the documented cap alone does not rule out self-hosting. That rests on the article’s statement of the cap; it reports no measurement of self-hosted output.
Two gaps remain before committing compute. The write-up lists H3’s conditioning modes but does not say which of them FL2VA and Ref2VA support in full, so a post-training plan should establish that first. And it describes the community license only as having “certain territorial considerations,” without detail, so the terms need a read before commercial use.
What the comparison leaves out
It gives no GPU, VRAM, or quantization figures for the 33B dense model, which is the missing input for any self-host sizing exercise; that is an open question to resolve, not one to estimate from this material. Without a memory footprint or throughput data for the open weights, it also offers no basis for comparing your own cost per clip against hosted H3’s rate of about $0.08/s at 768p.
The performance numbers it does report are not self-hosting measurements. Relaying fal’s launch comparison, it says a five-second 768p H3 Max generation takes “about three seconds or less,” roughly 35x the throughput of the official H3 endpoint. fal attributes the gains to post-training plus inference-stack work (multi-node serving, kernel caching, FlashPack-style techniques, autoscaling), and the article adds that part of the speed gain comes from co-design between the post-trained model and fal’s inference engine, with latency also depending on queueing, resolution, duration, batching, precision strategy, caching, and endpoint implementation. The Artificial Analysis with-audio leaderboard captures it cites from late August 2026 (image-to-video: H3 Max #1 at Elo 1,204, H3 #3 at 1,184; text-to-video: H3 Max #3 at 1,235, H3 #4 at 1,226) carry no runtime, hardware, or checkpoint details. Neither set of numbers says what the open weights will do on your hardware.
So does it still make sense?
The answer splits by deliverable. For 2K masters, my conclusion from the comparison’s evidence is that self-hosting cannot stand in for hosted H3, because it documents no 2K route outside the hosted pipeline. For 768p output, research, or custom post-training, the ceiling is not the obstacle; sizing, per-variant conditioning coverage, and the license terms are the open items.
For anyone who has sized this class of model on their own hardware: what did the 33B dense footprint and serving stack cost per second of 768p output, and how did that compare with hosted H3’s 768p rate? And if your slate mixes 768p deliverables with 2K masters, do you split them between self-hosted and hosted generation, or keep everything hosted and skip the operational load?