> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.api.odyssey.ml/llms.txt
> Use this file to discover all available pages before exploring further.

# Broadcast

Broadcast enables multiple people to view the same stream simultaneously via the Stream API endpoint. It also allows multiple users (or API calls) to inject prompts into that shared stream. These capabilities support both **interactive, multi-player experiences** and **Twitch-style passive viewing**, where audiences can watch a live stream without directly participating.

| Feature          | Standard Stream | Broadcast                |
| :--------------- | :-------------- | :----------------------- |
| Number of worlds | One per client  | One shared world         |
| Viewers          | Single client   | Multiple clients         |
| Input            | Single source   | Multiple participants    |
| Streaming output | Isolated        | Shared                   |
| Use cases        | Solo experience | Collaborative experience |

### **How It Works**

* A broadcast session starts a single Odyssey stream.
* Multiple clients join the same broadcast session.
* All participants receive the same live stream of the world.
* The stream runs once and persists for the duration of the broadcast session.
* All users see the same evolving world state.

### **Collaborative Experiences**

Some applications may choose to allow multiple users to send prompts or events to a shared world. This behavior is not enforced by the Broadcast API, but can be implemented by the client application using a custom orchestration layer.

In these setups:

* Multiple users submit input to the application
* The application decides how and when prompts are forwarded to the model
* The shared world evolves based on coordinated input

This pattern is demonstrated in the Broadcast demo application.

### **Important Considerations**

* Broadcast sessions involve a shared visual state.
* Input coordination, moderation, and conflict resolution are handled by the client application.
* Odyssey does not enforce role-based control or input arbitration by default.
* Applications should define clear rules for how shared input is accepted and applied.

### **Example Use Cases**

* Shared live demos
* Interactive presentations
* Collaborative tools built on top of shared worlds
* Educational experiences with synchronized visuals
* Multiplayer-style applications with custom orchestration

<Tip>
  ### **Best Practices**

  * Explicitly manage broadcast session lifecycle and cleanup.
  * Clearly separate streaming (Broadcast) from input orchestration (application logic).
  * Define moderation or ownership rules for shared input.
  * Close connections when users leave a broadcast.
</Tip>

## For implementation details, see our SDKs

<CardGroup cols={2}>
  <Card title="JavaScript" icon="js" href="sdk/javascript/introduction">
    Integrate our JavaScript SDK.
  </Card>

  <Card title="Python" icon="python" href="sdk/python/introduction">
    Integrate our Python SDK.
  </Card>
</CardGroup>