> ## 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
> 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.

# Quick iteration

> The develop, test, ship loop for every release after the first.

Once a model is registered, shipping a change is a short loop: edit, test locally, bump the version,
publish, deploy. You register a model only once; from then on you publish and deploy releases.

## The loop

<Steps>
  <Step title="Edit">
    Change your model code or swap the weights in your weights directory.
  </Step>

  <Step title="Test locally">
    [Build](/deploy/platform/build) and run the workspace, then connect from the [Reactor Sandbox](https://reactor-sandbox.vercel.app/). This is the fastest feedback loop, before anything ships.

    ```bash theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
    reactor build && reactor run
    ```
  </Step>

  <Step title="Bump the version">
    Increment `model.version` in `reactor.yaml` (for example `v1.0.0` to `v1.0.1`). This is the release tag publish and deploy use.

    ```yaml reactor.yaml theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
    model:
      version: v1.0.1
    ```
  </Step>

  <Step title="Publish and deploy">
    Both commands read the tag from `reactor.yaml`. Publish ships the image. Pass `--weights <path>`
    only when the checkpoint changed; otherwise the deploy reuses the previous release's bundle
    automatically.

    ```bash theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
    reactor model publish
    reactor model deploy
    ```
  </Step>
</Steps>

## Rolling back

To return to an earlier release, deploy it by name. This is the one case where you pass the tag
explicitly, since you're targeting a release other than the one in `reactor.yaml`:

```bash theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
reactor model deploy my-model:v1.0.0
```

In-flight sessions finish on the version they connected to. To disconnect them instead, add
`--immediate`. See [Cut over immediately](/deploy/platform/deploy#cut-over-immediately).

## Reuse the previous bundle for code-only changes

If the weights are unchanged between releases (a code-only tweak, a rebuilt image, a config update)
the bundle does not need to be on the machine that runs publish. Publish without `--weights` and the
deploy reuses the most recently deployed release's bundle server-side, with no local read or upload:

```bash theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
reactor model publish
reactor model deploy    # ℹ️  reuses the bundle from the previously deployed release
```

This is the standard form for CI machines that don't have the checkpoints checked out. To carry over
from a release other than the most recently deployed one, name it explicitly with
`reactor weights upload <model>:<release> --from <source-release>`. See
[Carry over weights from a previous release](/deploy/platform/publish#carry-over-weights-from-a-previous-release)
for details.

## Changing the spec without re-publishing

Some changes need no new release: a description tweak, a CPU/memory bump, or a visibility flip.
Edit `reactor.yaml` and reapply it with `reactor model update`:

```bash theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
# Edit model.description / model.resources / model.public in reactor.yaml, then:
reactor model update
```

Update is **spec-driven** by default: the entire mutable surface (`description`, `resources`,
`extra-args`) is rebuilt from `reactor.yaml`. Anything you remove from the file is cleared on the
server. `public` is the exception: leave it out and the model keeps the visibility it already has.
For status- or visibility-only changes that should ignore the spec entirely, use the targeted flags:

```bash theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
reactor model update --status DEPRECATED
reactor model update --private
```

See [Manage a model](/deploy/platform/manage#update-a-models-spec) for the full mode list.

## Keep versions moving forward

Bump `model.version` to a fresh, increasing value before each publish so `status` and rollbacks stay
unambiguous. The version must be full semver (`v1.0.0`, `v1.2.3-rc1`); the CLI rejects partial
values like `v1` before anything ships.

## Next

<CardGroup cols={2}>
  <Card title="Publish a release" icon="upload" href="/deploy/platform/publish">
    What publish builds, pushes, and uploads.
  </Card>

  <Card title="Check status" icon="circle-check" href="/deploy/platform/status">
    Confirm where each release stands.
  </Card>
</CardGroup>