Tracks
The model generates at 832 × 480 and delivers at the resolution you pick:
1080p (1920×1080), 2k
(2560×1440), or 4k (3840×2160). Read the deployment’s offered list of sizes from the state
snapshot’s available_resolutions; never hard-code it. There are no inbound tracks; all
client-to-model communication is through commands.
Session lifecycle
Once the connection reaches ready, the session begins inWAITING. start transitions to
GENERATING (provided a prompt is set); pause moves to PAUSED; resume returns to
GENERATING; reset clears state and returns to WAITING from any state. See
Sessions for the connection-level lifecycle
(disconnected → connecting → waiting → ready) the session passes through first.
When a run reaches its max_chunks limit (up to 229 chunks, ~7 minutes) the server emits
generation_complete and returns the session to WAITING. It does not roll into another run
because a new run begins at chunk 0, which would be a hard visual cut. Call start again with the
same conditions, or reset to clear the prompt and image first.
Commands
Send commands withreactor.sendCommand() on the base SDK, or the typed methods on
ViskoOrbisStableModel / useViskoOrbisStable(). The setter
commands (set_*) take effect at the next chunk boundary.
How commands report back. On @reactor-team/js-sdk 3.x every command’s success acknowledgement
is the correlated reply the awaited sendCommand() (or typed method) resolves with — delivered
to the calling connection only. Read the acknowledgement off the await, not off a
reactor.on("message") listener. The per-command examples below all follow that pattern. Reserve
on("message") for what the model genuinely broadcasts to every connected client — state,
chunk_complete, generation_started / generation_paused / generation_resumed /
generation_complete / generation_reset, conditions_ready, and command_error.
Below are all available commands:
set_prompt
Set the scene prompt. Valid at any time — call before start to arm generation, or hot-swap during
generation to steer the next chunk. The picture morphs into the new prompt at the next chunk
boundary rather than cutting. This is the model’s hero feature and what the tutorial’s
live steering
section builds on. Replaces the previously active prompt; applied on the next chunk when generating,
otherwise when start fires. Returns prompt_accepted as the awaited reply; conditions_ready and
state are broadcast to every connected client.
Parameters:
set_audio_prompt
Set the sound description the audio is generated from. Valid at any time — call before start, or
during generation to change the sound from the next chunk on. Pass an empty string to clear it,
which switches the audio model to generating sound from the picture alone (the default, and measured
the best). Returns audio_prompt_accepted as the awaited reply on success; state is broadcast.
Rejected with command_error on a deployment that has no audio track.
Parameters:
set_image
Provide a starting frame the video grows out of (image-to-video). Optional — with no image the model
generates from the prompt alone. Call before start; the image anchors the first chunk and every
later chunk inherits it through the model’s own history, so a change during generation has no effect
until reset and a new start. Upload the file first with uploadFile(), then pass the returned
FileRef. Returns image_accepted as the awaited reply on success;
conditions_ready and state are broadcast, and the command is rejected with command_error if
the file is missing, not an image, or cannot be decoded.
I2V ordering: await uploadFile, then setImage, then setPrompt, then start, because a
start that races past an in-flight upload renders its first chunk unconditioned and visibly
flickers into the anchored composition a beat later. On @reactor-team/js-sdk 3.x setImage
resolves with the image_accepted reply once the image is decoded, so await is the whole
pattern. See the
tutorial I2V flow.
Parameters:
set_seed
RNG seed for the next run. Must be a non-negative integer; the model never draws its own seed, so
the same seed with the same prompts reproduces the same video. Read once when start fires; later
changes take effect only after reset followed by a new start.
Parameters:
set_resolution
Choose the delivery resolution for main_video from this deployment’s offered list
(available_resolutions in the state snapshot — e.g. 1080p, 2k, 4k). These are delivery
tiers, not generation sizes: the model generates at 832×480 and the server delivers the picked
raster at that size. Session-scoped: read when start fires, so the track’s geometry never jumps
mid-shot — call it before start, or any time to arm the next run. Resolution survives reset; the
prompt does not. Returns resolution_accepted as the awaited reply on success; state is
broadcast, and the command is rejected with command_error naming the offered list when the value
is not on it.
Parameters:
set_audio_enabled
Enable or disable sound for runs started from now on. When false the audio model is skipped
entirely — main_audio carries silence and each chunk is cheaper to produce. Session-scoped like
set_resolution: read when start fires, and it survives reset. Returns audio_enabled_accepted
as the awaited reply on success; state is broadcast. Rejected with command_error on a deployment
that has no audio track. A client that never wants audio can also simply omit main_audio from its
track mapping when connecting — that needs no command, but still spends the compute; this command
is how the compute is saved.
Parameters:
start
Begin generating video on main_video. Requires a prompt (via set_prompt); a starting image is
optional. Returns generation_started as the awaited reply on success; state is broadcast.
Rejected with command_error if no prompt is set. Has no effect while already generating.
pause
Pause generation after the current chunk finishes. Frames stop streaming on main_video until
resume is called; the model keeps its place, so resuming continues the same shot rather than
starting a new one. Returns generation_paused as the awaited reply on success; state is
broadcast. Rejected with command_error if not generating or already paused.
resume
Resume generation from a previous pause. Requires the session to be paused. Returns
generation_resumed as the awaited reply on success; state is broadcast. Rejected with
command_error if not paused.
reset
Abort the current run, clear the active prompt and starting image, and return to the waiting state.
Valid at any time. After reset, call set_prompt (and optionally set_image) again before
start. Resolution and audio settings survive reset; prompt and image do not. Returns
generation_reset as the awaited reply; state is broadcast.
The lifecycle commands take no arguments. Each await resolves with that command’s correlated
reply:
Messages
Visko Orbis Stable emits the following messages. Every message is delivered as JSON{ "type": "<name>", "data": { … } }. Each row’s Delivery column says whether a connected
client sees the message as the correlated reply of a single awaited command (read it off the
await) or as a broadcast every connected client receives (subscribe with on("message")).
Both means the message is the calling command’s correlated reply and a broadcast every
connected client receives — on the calling connection it surfaces twice: once as the value the
awaited command resolves with, and once on the
message event. Drive state off the await for
the call that earned it; keep any on("message") listener for the broadcast side only (for
example, a second connection that did not issue the command). command_error is the exception to
that pattern: sendCommand() never rejects, so a rejection always surfaces on the message event
— that’s why it reads Broadcast, not Both. A rejected awaited call also lands on getLastError().state payload
state is the single source of truth for driving UI. Subscribe once and treat it as the
authoritative session snapshot; you generally do not need to track individual commands and
chunk_complete events yourself.
Example handler (broadcasts only):