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

# Register a model

> Provision a model record on Reactor. One-time per model.

Registering creates the model record on Reactor. You do it **once** per model; releases (image and
weights pairs) are published against it afterwards.

When the model is not registered yet, `reactor model publish` creates the record from your
`reactor.yaml` and continues with the release. Pass `--no-register` to make publish stop with an
error instead.

## Register from your workspace

Run it from inside your workspace:

```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
cd my-model
reactor model register
```

The CLI walks up from the current directory until it finds your `reactor.yaml` (stopping at the
repository root) and reads your model details from it, so no flags are needed. Those details are the
source of truth for everything Reactor knows about your model:

```yaml reactor.yaml theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
model:
  # Model name: `<org>/<name>`, lowercase. A short slug without the
  # org prefix also works; Reactor fills in your org.
  name: my-awesome-model

  # Release tag used by publish and deploy. Full semver, e.g. v1.0.0.
  version: v0.0.1

  description: |
    A vision transformer for partner integration.

  # Default false (private). Set true to make the model discoverable
  # by every Reactor account.
  public: false

  # Optional accelerator and CPU/memory overrides.
  # See "Resources and accelerators" below.
  resources:
    gpu:
      type: NVIDIA_H100
      count: 1

runtime:
  import: model:MyModel
  config: config.yaml
```

The success output prints the canonical model name and points at the next command:

```
Registering model 'my-awesome-model'...
✓ Model registered successfully
  ID:     a1b2c3d4-...
  Name:   vendor/my-awesome-model
  Status: ACTIVE
  Public: false

Next step - publish a release:
  reactor model publish vendor/my-awesome-model:<release>
```

The `Name` in the output, `vendor/my-awesome-model`, is your model's full identifier on Reactor.
It is the value commands take in a `<model>:<release>` argument. Inside a workspace you rarely type
it: the commands read it from `reactor.yaml` for you.

## Register without a workspace

For one-off invocations, pass the model name on the command line:

```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
reactor model register --name vendor/my-awesome-model
```

A short slug without the org prefix (`--name my-awesome-model`) also works; Reactor fills in your
org.

## Resources and accelerators

The accelerator your model runs on, and any CPU or memory overrides, all live under
`model.resources` in `reactor.yaml`:

```yaml reactor.yaml theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}}
model:
  resources:
    # Accelerator. Omit for CPU-only models.
    gpu:
      type: NVIDIA_H100
      count: 1

    # Optional CPU/memory overrides. Omit to use Reactor defaults.
    cpu:
      request: 750m
      limit: "2"
    memory:
      request: 8Gi
      limit: 32Gi
```

CPU and memory quantities follow Kubernetes conventions:

| Field            | Example | Meaning                   |
| ---------------- | ------- | ------------------------- |
| `cpu.request`    | `500m`  | Half a CPU requested      |
| `cpu.limit`      | `2`     | Up to two CPUs            |
| `memory.request` | `4Gi`   | 4 GiB requested           |
| `memory.limit`   | `32Gi`  | Up to 32 GiB memory limit |

The accelerator types Reactor accepts as `gpu.type`:

| Family         | Types                                                                                                                             |
| -------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| NVIDIA GPU     | `NVIDIA_A100`, `NVIDIA_H100`, `NVIDIA_H200`, `NVIDIA_B200`, `NVIDIA_GB200`, `NVIDIA_B300`, `NVIDIA_RTX6000`, `NVIDIA_RTX6000_PRO` |
| AMD GPU        | `AMD_MI300X`, `AMD_MI350X`, `AMD_MI400`                                                                                           |
| AWS Trainium   | `AWS_TRAINIUM_2`, `AWS_TRAINIUM_3`                                                                                                |
| AWS Inferentia | `AWS_INF_2`                                                                                                                       |

The platform is authoritative for this list. Print the currently accepted values with
`reactor gpu ls` (pass `--refresh` to bypass the local cache after a platform release adds a new
accelerator).

To change these settings on an existing model, edit `reactor.yaml` and run
[`reactor model update`](/deploy/platform/manage#update-a-models-spec).

## Next

<CardGroup cols={2}>
  <Card title="Publish a release" icon="upload" href="/deploy/platform/publish">
    Build the image, push it, and upload weights.
  </Card>

  <Card title="Manage the model" icon="sliders" href="/deploy/platform/manage">
    Update the spec, list running instances, or delete the model.
  </Card>
</CardGroup>