I’d start with H3 Max for fast candidate generation and move to H3 when a shot needs 2K output, richer references, or editing. The “Max” suffix is a poor guide to capability: it describes a variant optimized for speed, prompt adherence, and aesthetics, while the original H3 retains the broader production surface.
The distinction also depends on where you run the model. Hosted H3 includes a resolution stage missing from its open weights, and H3 Max’s headline performance depends partly on fal’s serving infrastructure.
The comparison below uses the reported late-August 2026 leaderboard snapshots and mid-September 2026 pricing. I’d treat those as dated measurements, then check the endpoint I actually intend to ship against.
Start with the output contract
Before comparing preference scores, I’d decide what the application must deliver. A 768p preview loop and a 2K final-render pipeline impose different requirements.
| Requirement | H3 Max | H3 |
|---|---|---|
| Model origin | fal Research post-training of H3 open weights | Original MiniMax foundation |
| Main emphasis | Throughput, adherence, aesthetics | Multimodal generation and production control |
| Duration | 5–15 seconds, whole-number seconds | 4–15 seconds |
| Native resolution | 480p or 768p | 768p |
| Higher-resolution path | Limited 1080p latent refinement on some platforms | Hosted H3-Regenerate-2K |
| Frame rate | 24 fps | 24 fps |
| Generated audio | Native 32 kHz stereo | Native 32 kHz stereo |
| Text-to-video and image-to-video | Yes | Yes |
| First/last-frame control | Yes | Yes |
| Reference-to-video | Available; host-dependent surface | Broader documented support |
| Video editing | Not the primary documented endpoint | Supported |
| Open-weight deployment | Positioned as a hosted post-trained variant | Released H3-Base checkpoints |
Both support the same family of aspect ratios: 21:9, 16:9, 4:3, 1:1, 3:4, and 9:16. Some interfaces also expose adaptive options.
The one-second difference in minimum duration matters if you need four-second transitions. Both models snap frame counts to a VAE-friendly grid, so duration and frame handling deserve attention at the endpoint level.
Separate native generation from resolution refinement
Hosted H3 reaches the 2K, 2560×1440 class through H3-Regenerate-2K, a dedicated second stage that uses the original context. Its native generation resolution is short-edge 768p.
That regeneration stage is absent from the open-weight release. Self-hosted H3 therefore remains limited to 768p, and H3 Max does not inherit the hosted H3 2K path.
Some H3 Max interfaces advertise 1080p latent refinement. I’d record that as a separate endpoint capability: its native generation modes remain 480p and 768p. Treating every advertised output size as a native model resolution makes this comparison unnecessarily confusing.
What the shared foundation gives you
MiniMax released H3 in late July 2026, followed by open weights on August 3, 2026. The weights use a community license with territorial considerations; local deployment still requires reading those terms.
H3 is a general-purpose omni-modal video system built around a 33B dense H3-Omni-Transformer. Its architecture includes Contextual Omni Representation, the high-compression H3-VAE, and In-Context Regeneration. The open release contains two transformer variants:
- FL2VA, focused on first/last-frame conditioning.
- Ref2VA, focused on reference-heavy generation.
H3 jointly generates picture and stereo audio. Dialogue, foley, ambience, and music can arrive synchronized without a separate audio model or a post-processing stage for basic synchronization.
That shared audiovisual foundation is useful across advertising, e-commerce, branding, product design, UI/UX motion, gaming, and short cinematic work. H3 also emphasizes instruction following, text and brand rendering, and video-to-video motion transfer.
H3 Max came later, around August 27, 2026, from fal Research working with MiniMax. It post-trains the released H3 foundation for faster generation, stronger prompt adherence, and aesthetics while retaining joint audio-video generation.
I’d distinguish the model’s lineage from its deployment options. H3’s released checkpoints support local deployment, research, and custom post-training. H3 Max is documented primarily through hosted APIs.
Neither model has a useful “coding” or token-window comparison
These are video-generation models. Neither has a published token-based context-window specification for the endpoints discussed here.
H3 documents bounded multimodal reference inputs and uses H3-Context-IR for multimodal instruction understanding. H3 Max exposes prompt expansion. Neither is documented as a general reasoning API, and coding benchmarks do not help choose between them.
Reference conditioning is where I’d inspect the API closely
H3’s reference budget is more specific than a generic “supports multimodal input” label:
- Up to 9 images.
- Up to 3 video clips, each 2–15 seconds, with no more than 15 seconds total.
- Up to 3 audio clips, which must accompany visual references.
It also supports first-frame, last-frame, and combined first-and-last-frame image conditioning.
Those constraints directly affect request construction. Three individually valid reference videos can still exceed the aggregate duration limit, and audio references cannot be treated as an independent input mode.
H3 Max launched around text-to-video and image-to-video with first/last-frame control. Several platforms subsequently added image, video, and audio reference modes, but their exposed feature sets remain more constrained than full H3 in some implementations.
For character consistency across multiple images, motion transfer from clips, or audio-guided shots, I’d inspect the chosen provider’s schema before committing to either model. A reference-to-video checkbox does not tell me the accepted combinations, limits, or editing operations.
Read the speed claim as a serving result
fal reports generating a five-second 768p H3 Max clip in under three seconds on its optimized inference stack. Its launch comparison describes roughly 35× the throughput of the official H3 endpoint.
That is a substantial improvement for prompt iteration, candidate selection, and high-volume social or advertising content. Generating faster than playback duration can change how an interactive application feels.
But throughput and per-request latency measure different things. I would not convert “35× throughput” into a promise that every request finishes 35 times faster.
fal attributes the result to both post-training and inference engineering, including multi-node serving, kernel caching, FlashPack-style techniques, and autoscaling. The reported advantage belongs to that model-and-serving combination.
Production behavior also depends on:
- Queueing and batching.
- Requested resolution and duration.
- Precision strategy.
- Caching.
- Provider implementation.
For an application, I care about how long a user waits and how many completed clips the service can sustain. The launch figures are a useful starting point; they do not establish identical performance across providers or hardware.
Preference rankings favor Max, with a narrower conclusion than “better”
The late-August 2026 Artificial Analysis with-audio snapshots put H3 Max ahead in both directly comparable categories:
| Category | H3 Max | H3 |
|---|---|---|
| Image-to-video | #1, Elo 1,204 | #3, Elo 1,184 |
| Text-to-video | #3, Elo 1,235 | #4, Elo 1,226 |
The gaps are modest, particularly on the tightly clustered text-to-video board. They support a preference advantage in those evaluations, rather than a universal capability ranking.
fal’s own human-preference evaluation, using Bayesian Elo with confidence intervals, ranked H3 Max first for overall quality, prompt understanding, and aesthetics against its comparison field, including H3. Design Arena also highlighted the combination of H3-level quality and much faster generation.
I’d keep the provenance attached to each result. Artificial Analysis provides an independent comparison; fal’s evaluation is internal, even when it uses blind preference testing. Those are different sources of evidence.
Reports of stronger complex-prompt adherence and more appealing 768p results are consistent with H3 Max’s positioning. H3’s advantages emerge elsewhere: higher-resolution delivery, richer conditioning, and editing.
Both are described as strong relative to earlier 2025–early-2026 systems on temporal consistency, motion, dialogue lip-sync, and text or brand rendering. Joint audio-video generation also removes the need to assemble separately generated sound and picture for basic synchronization.
Price the actual resolution and duration
The reported official MiniMax rates as of mid-September 2026 are:
| Model and resolution | Price per generated second |
|---|---|
| H3 Max, 480p | $0.05 |
| H3 Max, 768p | $0.08 |
| H3, 768p | Approximately $0.08 |
| H3, 2K | $0.13 |
At the listed 768p rate, Max does not have an automatic per-second price advantage. Its practical value comes from faster iteration and the option to generate at 480p.
That changes how I’d budget exploration. If low-resolution candidates are sufficient for choosing composition and motion, Max’s 480p tier is relevant. If every candidate must be 768p, I’d compare provider pricing and measured latency rather than assume the speed-oriented model is cheaper.
Pricing remains platform-dependent. Aggregator discounts can affect the calculation, but a general discount claim should not substitute for the current rate of the specific endpoint.
A unified gateway helps orchestration, but inspect the video schema
For an application already combining language, image, and video models, CometAPI offers a unified OpenAI-compatible gateway covering 500+ models, including these identifiers:
Base URL: https://api.cometapi.com/v1
H3 model ID: minimax-h3
H3 Max model ID: minimax-h3-max
The practical benefit is one API key and base URL across that workflow. Its documentation includes text-to-video, image-to-video, reference modes, and size and duration controls.
The platform advertises pay-as-you-go billing without mandatory monthly fees, discounts often in the 20–40% range across many models, and a 99.9% availability target. New-user test credits are also described as typically available. I’d verify those commercial terms separately from model capabilities.
OpenAI compatibility can simplify SDK configuration, but the base URL and model ID alone are insufficient to construct a complete video request. I’d use the documented video schema, particularly when switching reference modes or requesting resolution refinement. Where both models expose the same request shape, switching the model field is convenient; feature parity still needs checking.
Direct access is also available: H3 through MiniMax’s API and released H3-Base weights, and H3 Max through fal’s hosted APIs.
How I’d route production work
Use Max for the candidate loop
I’d choose H3 Max for interactive text-to-video or image-to-video generation, prompt refinement, motion A/B testing, and high-volume short clips.
It is especially attractive when 480p or 768p satisfies delivery requirements, or when the selected host’s limited 1080p refinement is sufficient. The preference results make it a credible final-output choice at those resolutions as well as an iteration tool.
Use H3 when the job requires its additional capabilities
I’d choose H3 for hosted 2K delivery, broader reference conditioning, video editing, and motion-transfer workflows. It is also the relevant option for experimenting with released H3-Base checkpoints or doing custom post-training.
Self-hosting changes that decision’s resolution implications: open weights provide deployment control, but they do not include the hosted 2K regeneration stage.
Keep the handoff explicit
A two-stage workflow makes sense when exploration and delivery have different requirements: generate candidates with H3 Max, select a direction, then use H3 for the shots that require deeper conditioning, editing, or 2K regeneration.
I’d make that routing decision from the shot requirements. A finished 768p asset can stay on Max; a reference-heavy shot may belong on H3 from the first request.
Originally published at cometapi.com
Top comments (0)