Skip to main content
This page lists FastH3-Omni’s messages, tracks, and commands. Wait for the session to be ready before sending commands.

Tracks

Session lifecycle

When you connect to FastH3-Omni, the session starts with empty generation and playout queues, autoplay off, and no clip playing. The initial state_update shows the session settings, queue capacities, and available commands. Check its valid_commands field to see which commands you can send in the current state. The initial queue_update shows the clips waiting to generate or play; both lists start empty. Send enqueue to add your first clip to the generation queue. When generation finishes, the model sends clip_generated and moves the clip to the playout queue. Call play to send it to main_video and main_audio, or turn on autoplay to play ready clips whenever the player is idle. You can generate another clip while one plays. Call reset to stop playback, clear both queues and any retained clips you could continue from, clear the output tracks, and restore the session defaults.

Commands

enqueue

Queue a clip from a prompt, with optional references or continuation. Every clip needs a nonempty prompt. Image references guide characters, scenes, and appearance. Separate first_frame_image and last_frame_image inputs pin the opening and closing frames; each needs a reference image in the same request. Audio references guide the soundtrack and require an image reference or a retained clip to continue. The model keeps each request’s references with its clip. It replies with clip_queued when it accepts the request, then sends clip_generated or clip_failed after generation.
Do not send reference_image with reference_images, or reference_audio with reference_audios in the same request.
A continued clip’s soundtrack uses one of the three audio labels. Give every uploaded audio clip a role in the prompt, such as a speaker’s voice, background sound, or music; without that sentence the model has no instruction for how to use it. Keyframes are separate from ordered reference images and have no <Picture N> label. The model checks file types, counts, prompt budget, and queue capacity before accepting a request. It sends command_error if a check fails. Each image must be JPEG, PNG, or WebP, no larger than 25 MiB and no more than 25 million pixels, with an aspect ratio between 1:4 and 4:1. Audio can be WAV, MP3, AAC/M4A, OGG/Opus, FLAC, or WebM. Each file can be up to 25 MiB and 2 to 15 seconds long, in mono or stereo. The model checks the prompt and image references against the deployment’s text and presentation budgets. Handle command_error if either limit is exceeded; the model refuses an over-budget request rather than truncating it. With the base JavaScript SDK 3.1.0 or later, pass FileRef values directly, including inside reference_images and reference_audios arrays. The SDK serializes them for you. The Sandbox converts browser-readable images, including HEIC, before upload and keeps only the first 15 seconds of longer audio. Direct API callers must use an accepted format and keep audio between 2 and 15 seconds.

Keyframes and continuation

reference_image and reference_images guide appearance. To pin a frame, upload a separate image as first_frame_image or last_frame_image. Every request with a keyframe must also include at least one ordinary reference image. Keyframe images are not numbered <Picture N> references. For an independent clip, you can set either or both keyframes. With continue_from_clip_id, the default latent mode carries motion, camera, and audio and accepts no keyframes. Set continue_mode: "frame" to use the earlier clip’s final frame as the new first frame. Do not pass first_frame_image with a continuation. A last_frame_image with continuation requires frame mode and a reference image. After the SDK reaches ready, upload the files and enqueue an independent clip with a pinned start and end:
Wait for that clip’s clip_generated message and save message.data.clip.clip_id as generatedClipId. To begin the next clip on its final frame, pass that ID with frame mode and an ordinary reference image:
clip_queued confirms acceptance, clip_generated reports readiness, and clip_failed reports a generation failure. Each message’s clip includes the keyframe and continuation fields listed below. Invalid combinations produce command_error with a reason.

play, pop, move, and stop

A clip cannot be replayed after it has played, been stopped, or been removed with pop.

State and defaults

The defaults are 14.375 seconds, seed 1000, aspect ratio 16:9, autoplay off, and flush on. Read state_update for the current session values.

Messages

Command replies, including clip_queued, are correlated to the caller. The model broadcasts state, queue, and playback changes to all session clients. New clients receive state_update and queue_update when they connect.

ClipInfo

Messages about a clip include this ClipInfo record:

state_update

This message gives you the current session settings, playback status, queue counts, and available commands. It arrives when you connect or session state changes, and in reply to get_state. Use queue_update to see the clips in each queue.

queue_update

This message lists the clips waiting to generate or play. It arrives when you connect or either queue changes, and in reply to get_queue. Each listed clip is a ClipInfo record. With autoplay off, a new clip appears in generation after enqueue. When clip_generated arrives, it moves to playout. Calling play removes it from playout; its ID then appears in state_update.playing_clip_id. Save a generated clip’s clip_id if you want to continue from it while the session retains it.

Complete example

This base SDK example queues a clip from a prompt and plays it when ready. See the tutorial for uploads and continuation.