Six steps, and open weights stop at 768p

GitHub records the Pika-Labs/Pika-H3-Flex repository as created at 2026-10-29T17:08:59Z, which is 01:08 on October 30 in Beijing. That clock comes from the repository record, not from a sentence in the readme. It falls after the backfill line and before this edition's window.

The readme says Pika H3 Flex is a post-trained H3 model built on MiniMax-H3. It generates video with synchronized stereo audio in six sampling steps. Native resolution for local open-weight inference is 480p and 768p, across the 11 aspect ratios the page lists. 1080p, 2K, and 4K are described on Pika's hosted API, which generates the higher resolution from a draft video. They are not the native output of the local weights.

The family has two task adapters. FL2VA handles text and endpoint frames. Ref2VA handles multimodal references. Ref2VA accepts up to 9 images, 3 videos, and 3 standalone audio clips, with 12 reference files in total, and at least one image or video is required. Each video or standalone audio clip must be 2 to 15 seconds, and the combined video duration and the combined standalone-audio duration must each be at most 15 seconds. The page says these are accepted input limits, not a guarantee that every maximum combination fits in GPU memory.

Requested durations are integers from 5–15 seconds. Actual length follows the model's frame grid. A 5-second request produces 124 frames, about 5.17 seconds, and a 15-second request produces 362 frames, about 15.08 seconds. The frame rate is 24 fps. Audio is 32 kHz stereo, mixed into the generated video. The output is an MP4 with H.264 video and AAC audio, plus JSON metadata. A prompt is text or a UTF-8 file, from 1 to 8,000 characters.

The readme sets the six showcases outside the release results. They are there to show camera work, sequences, graphics, and reference-guided animation. They are not release-validation renders and not throughput benchmarks. Exact reproduction with the released package is not guaranteed. This column does not treat how those clips look as a measurement.

The local weights and the hosted API have to be read separately. Six sampling steps, 480p and 768p, 24 fps, and 124 frames are in the open-weight description. A 5-second request becomes 124 frames, about 5.17 seconds, and a 15-second request becomes 362 frames, about 15.08 seconds, because duration follows the frame grid. Audio in that file is 32 kHz stereo. 4K and separate audio stems sit on the hosted API and do not change the local specification. Reference caps are acceptance limits, not a quality score: up to nine images, three videos, and three audio clips, twelve files in total, with at least one image or video, and combined video or audio not past 15 seconds. A maximum combination may still fail to fit in memory. The showcases do not replace these specifications. They are not release-validation renders and not throughput benchmarks, and exact reproduction is not guaranteed. The page does not give a score against another video model, and it does not give a quality change for six steps against a longer sampling schedule. What a reader can check is narrower than a launch claim. The repository record gives the creation time. The readme gives six generator evaluations, native 480p and 768p, a 24 fps file, mixed stereo audio, and a frame grid that turns a requested integer duration into a slightly different length. Higher resolutions and separate stems are listed on the hosted API, including generation from a draft. The six showcases are labeled as clips to watch, not as a test that the released package will reproduce. Those distinctions are the whole of the public specification in the repository. There is no table that places this model against another video model, and there is no statement comparing six steps with a longer sampling schedule.