Skip to main content
A connection represents an active session between your application and Odyssey. Opening a connection reserves a GPU-backed streamer resource, minimizing the time required to start streaming.A stream is the real-time video output generated by the world model.Key relationship:
  • A connection can exist without an active stream.
  • A stream cannot exist without a connection.
  • A single connection can run multiple streams sequentially.
For a full explanation, see Connections vs Streams.
Yes.Connections reserve resources until they are explicitly closed or until they time out due to inactivity.Always call disconnect() when your application is finished streaming.Using cleanup patterns such as try/finally (or React useEffect cleanup) helps prevent dangling sessions.
This is usually caused by dangling sessions.Common causes include:
  • Browser tab closures without disconnect
  • Network interruptions
  • Application crashes
  • Hot module reload during development
  • Multiple tabs running the same application
Odyssey will automatically clean up stale sessions after a timeout window, but explicit cleanup is recommended.See Session Management for best practices.

​
Broadcast

Broadcast allows multiple clients to watch the same running stream. Instead of creating separate streams per viewer, Broadcast delivers the same live output to all spectators.
No.Broadcast is responsible only for shared streaming output.If you want multiple users to send prompts or interactions, your application must implement an orchestration layer that decides how and when prompts are forwarded to the model.
No.Broadcast streams produce recordings the same way as standard streams.Recordings are tied to the stream ID, not to individual spectators.

​
Simulations

Streaming generates real-time interactive video output.Simulations run asynchronous jobs and produce output once the job completes.Simulations are commonly used for:
  • batch generation
  • scripted world sequences
  • offline processing
Broadcast is only available for interactive streaming sessions.
Odyssey allows up to 10 simulation jobs to be queued at the same time.Pending jobs include simulations that are:
  • waiting to be processed
  • currently being processed
If you attempt to submit another job when the queue is full, the API will return a 429 quota exceeded error.To maximize throughput, submit up to 10 jobs, and then submit a new job whenever one completes so the queue stays near its limit.
The API will return a 429 quota exceeded error.You must wait until one of the queued simulations completes before submitting another.
Possibly, but execution order and timing are not guaranteed.There are no guarantees about:
  • exact execution order
  • when a specific job will start
  • how many jobs run concurrently
Simulation scheduling is managed internally by Odyssey.
No.Only the stream owner counts toward concurrent stream limits.Spectators connected through Broadcast do not create additional streams, so they do not consume additional stream slots.

​
Streaming Usage

Yes — this is recommended.A single connection can start and stop multiple streams sequentially. Reusing the same connection avoids repeated connection setup and allows new streams to start faster.Typical lifecycle:
connect()

startStream()
endStream()

startStream()
endStream()

disconnect()
Keeping the connection open while starting new streams is the recommended pattern for interactive applications.
A single interactive stream can run for up to 150 seconds.If you need longer sessions, you can start a new stream after the previous one ends while keeping the same connection open.Odyssey supports contiguous streaming sessions of up to 1 hour within the same connection.
If a connection is not closed, it remains active until it times out.During that time, it will still count against:
  • concurrent stream limits
  • active session usage
Explicit cleanup is strongly recommended.