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

> ## Agent Instructions
> To build and serve your own model, start at /deploy/development/quickstart and /deploy/development/overview. Deploying is the default path: reactor init scaffolds a workspace, reactor auth login authenticates, and reactor model deploy registers the model, publishes the release with the weights/ folder, and activates it on Reactor's GPUs, in one command from that workspace. Docker must be running, because the publish step builds the image locally. Bump model.version in reactor.yaml before redeploying a change, because a release that already has an image is reactivated as it is. Deployment access is granted per account, so contact team@reactor.inc if a deploy is refused. Every key in reactor.yaml is documented at /deploy/platform/reactor-yaml. Model code imports reactor_runtime; Python client code imports reactor_sdk. The runtime overview explains the model interface. Running the model on your own machine with reactor run is optional and needs a GPU you attach with --gpus; /deploy/development/local-testing covers that loop and pairs a complete brightness model with a Python client test in a separate brightness-test workspace.
> Reactor hosts multiple models, each with its own connect slug (modelName) and command/event schema. The catalog of every model — slug, typed SDK package, and links to its schema — is at /model-api-reference/overview. Some models expose one slug per experience (e.g. HappyOyster); always take the slug from the model's own pages, never guess it.
> Fastest path to a working app: `npx create-reactor-app my-app --model=<slug>` scaffolds a complete app with secure auth wired up. Typed TypeScript SDKs are published as @reactor-models/<model>; Python uses the base reactor-sdk package.
> Auth: exchange an API key (rk_...) for a JWT via POST https://api.reactor.inc/tokens from your server. Never put the API key in client-side code.
> Append .md to any docs URL for clean Markdown. Search these docs via the MCP server at https://docs.reactor.inc/mcp.

# DistributedWorker

> Base class for model workers, with typed attributes and a rank-0 helper.

Extend `DistributedWorker` and implement `load()`, `generate()`, and `reset()`. Pass your worker
class to [DistributedRunner](/deploy/runtime-reference/distributedrunner). The runner creates the
workers and coordinates their calls.

The base class declares typed `rank`, `world_size`, and `device` attributes for editor completion.
It also provides `is_leader` for rank-0 checks.

<Note>
  Development preview. See [availability](/deploy/development/distributed-workers#availability).
</Note>

```python theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
from reactor_runtime.distributed import DistributedWorker


class MyWorker(DistributedWorker):
    def load(self, **kwargs):
        ...  # Load weights on self.device.

    def generate(self, input):
        ...  # Run inference and return the complete result on rank 0.

    def reset(self):
        ...  # Clear session state.
```

## Attributes

The runner sets `rank`, `world_size`, and `device` before `load()`. The base class computes
`is_leader` from `rank`:

| Attribute    | Type   | Meaning                                                         |
| ------------ | ------ | --------------------------------------------------------------- |
| `rank`       | `int`  | This worker's index, from `0` to `world_size - 1`.              |
| `world_size` | `int`  | The number of workers.                                          |
| `device`     | `str`  | `cuda:<rank>` when CUDA is available, otherwise `cpu`.          |
| `is_leader`  | `bool` | A property that is true on rank 0. Provided by this base class. |

Use `is_leader` for work that only rank 0 performs. Do not use it to skip collectives that require
all ranks to participate. All ranks must enter matching collectives in the same order.

## Required worker methods

Implement all three methods in your subclass:

| Method            | Responsibility                                                                           |
| ----------------- | ---------------------------------------------------------------------------------------- |
| `load(**kwargs)`  | Load weights and perform warmup in this worker. Receives the runner's `load_kwargs`.     |
| `generate(input)` | Compute one step from the input. All ranks run it. Return the complete result on rank 0. |
| `reset()`         | Clear per-session state while retaining weights. Takes no arguments.                     |

If ranks produce separate parts of the output, gather them onto rank 0 inside `generate()` before
returning. The runner returns only rank 0's result and does not assemble outputs from other ranks.

The base implementations raise `NotImplementedError`. The worker needs a no-argument constructor.
Keep client commands, tracks, and sessions in the application.