Skip to main content
This page documents the complete Visko Orbis Stable wire surface: the media tracks it produces, the session lifecycle, every command you can send, and the messages the model emits back. For what Visko Orbis Stable is and a quick start, see the overview.

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 in WAITING. 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.
Session lifecycle: waiting → generating → paused, with generation_complete and reset returning to waiting

Commands

Send commands with reactor.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.
Non-16:9 starting images squash. The reference is resized to 832×480 with no crop. Use a 16:9 frame.
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):

Complete example

Stage a prompt (and optionally an image), wait for the image to decode if you sent one, start, then steer mid-stream.