> ## 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=` scaffolds a complete app with secure auth wired up. Typed TypeScript SDKs are published as @reactor-models/; 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. # Manage a model > List, change, inspect, or delete the models registered against your account. All commands are workspace-aware. Four commands operate on a model record after it has been [registered](/deploy/platform/register): `ls`, `update`, `instances`, and `delete`. The last three infer the model name from the nearest enclosing `reactor.yaml` when you run them inside a workspace, so the usual call needs no arguments. ## List the models you own `reactor ls` prints the models registered against your account (`reactor model ls` is identical), one canonical `/` per line, so the output pipes cleanly into shell composition: ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor ls # vendor/my-awesome-model # vendor/rolling-model ``` The default view shows only models you own. Pass `-a`/`--all` to include every visible model on the platform, including the public ones you can deploy but do not own: ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor ls -a ``` ### Long format with `-l` Pass `-l` to get a table with visibility, ownership, status, and per-region instance columns. Short bool flags compose, so `-la` is the same as `-l -a`: ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor ls -l ``` ``` Models (2): NAME VISIBILITY OWNED STATUS INSTANCES (by region) vendor/my-awesome-model private ✓ ACTIVE us-central=2 us-east=1 vendor/rolling-model private ✓ ACTIVE - ``` | Column | Meaning | | --------------------- | --------------------------------------------------------------------------------------------------------- | | NAME | Canonical `/` identifier, ready to paste into `publish`, `deploy`, `status`, or `update`. | | VISIBILITY | `public` if the model is discoverable platform-wide, `private` if only your account can see it. | | OWNED | `✓` when your account owns the model, `✗` for platform / other-account public models. | | STATUS | `ACTIVE`, `DEPRECATED`, or `DISABLED` (set via [`reactor model update --status`](#update-a-models-spec)). | | INSTANCES (by region) | Running instances per canonical Reactor Region. Shown for models you own only. | ### Structured output Pass `-o`/`--output` to emit the same data, including the per-region instance counts, in a structured format: `table` (default), `json`, `yaml`, or `md` (Markdown table): ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor ls -o json reactor ls -o md ``` ### Narrowing the listing Pass `--name ` to keep only canonical names containing the substring (case-insensitive, server-side filter): ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor ls --name vision # owned names containing "vision" reactor ls -la --name reactor # public reactor models, long format ``` When no rows match, the CLI prints a hint pointing at the next step: register a model, drop `--name`, or pass `-a` to widen the view. `list` is registered as an alias for `ls`, so `reactor model list` keeps working if that's the muscle memory you have from other CLIs. ## Update a model's spec `reactor model update` is the way to change a registered model without re-publishing a release. It has two modes. ### Spec-driven (default) With no flags, update treats your `reactor.yaml` as the **complete declaration** of the model's mutable fields. The CLI sends a full-replace `PUT` built from the spec: description, resource overrides (CPU / memory / GPU), and `extra-args`. Anything absent from the spec is cleared on the server. ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} cd my-model reactor model update ``` `public` is the exception. When you leave it out of the file, the model keeps the visibility it already has. When you write it, the value in the file overwrites the stored visibility. This mode never renames the model: `model.name` only selects the target. `model.version` is also ignored (update operates on the model, not a release). To update a model from outside its workspace, point at a spec explicitly: ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor model update --model-file ./reactor.yaml reactor model update my-model --model-file ./reactor.yaml ``` When both an explicit `` and a `model.name` in the file are present, they must match (short and canonical `org/name` forms compare equal). ### Targeted (status / visibility) To flip a status or visibility flag without touching the rest of the spec, pass one of `--status`, `--public`, or `--private`. Targeted mode ignores `reactor.yaml` values entirely and applies just the named change server-side. ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor model update --status DEPRECATED reactor model update --private reactor model update --status ACTIVE --public ``` `--status` accepts `ACTIVE`, `DEPRECATED`, or `DISABLED`. `--public` and `--private` are mutually exclusive. `--model-file` cannot be combined with the targeted flags. ## List running instances `reactor model instances` shows the instances currently serving a model, so you can check what is deployed and live without leaving the CLI. ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor model instances # model.name from reactor.yaml reactor model instances my-model reactor model instances my-model --json | jq .count ``` The default view is live-only, and it hides any region where the model is scaled to zero. Add `--all` to include both the recent historical instances and those all-zero regions. Bound the history window with `--since` (a Go duration, with a `d` day suffix): ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor model instances --all reactor model instances --all --since 7d ``` | Flag | Description | | --------- | ------------------------------------------------------------------------------------------------------ | | `--all` | Include recent historical instances and the regions scaled to zero. | | `--since` | History window when `--all` is set (`30m`, `24h`, `7d`; server default 24h, max 7d). | | `--json` | Emit the raw server response for scripting. The workspace-inference notice is suppressed in this mode. | The formatted output opens with a per-region count table, then lists one row per instance: ``` Model: my-model Instances: 2 REGION DESIRED RUNNING HEALTHY IDLE us-central 2 2 2 1 ---------- ------- ------- ------- ---- Total 2 2 2 1 REGION INSTANCE STATUS us-central helios-aa44-bz1k healthy us-central helios-aa44-fqwe healthy ``` Each instance reports its own `STATUS`: | Status | Meaning | | ------------ | --------------------------------------------------------------------------------------------- | | `healthy` | The instance holds a fresh heartbeat. | | `unhealthy` | The instance runs, but it does not send a heartbeat yet. | | `terminated` | The instance served past sessions and is gone from its cluster. It appears only with `--all`. | | `?` | The server reported no status for this instance. | A `?` in the region table means the same thing: the server did not report that number. Use `INSTANCE` (the instance identifier) with [`reactor logs `](/deploy/platform/logs) to tail that instance's logs, or with `GET /logs?machine_id=…` from the [log gateway](/deploy/platform/logs). ## Delete a model `reactor model delete` soft-deletes a model: the record and its releases are kept on the server as a tombstone, and the model's name stays reserved. The model leaves every read surface at once, but the same name cannot be re-registered while the tombstone exists. The partner image and weights bundles in object storage are retained for audit and garbage-collected separately. ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} cd my-model reactor model delete ``` The CLI prints the model name it resolved and then asks you to type it back verbatim before proceeding, the same convention `kubectl delete`, `gh repo delete`, and `terraform destroy` use. Any mismatch (including a different case or trailing whitespace) aborts immediately; there is no retry. ``` Warning: This permanently deletes model "my-model" and all its releases. The model cannot be recovered, and its name stays reserved: it cannot be re-registered afterward. Type the model name ("my-model") to confirm; anything else aborts: ``` For CI and scripted use where stdin is not a TTY, pass `--yes` to skip the confirmation: ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor model delete my-model --yes ``` You can also target a model by name from outside its workspace: ```sh theme={"theme":{"light":"github-light","dark":"github-dark-high-contrast"}} reactor model delete my-model reactor model delete partner/my-model ``` ## Next See where each release stands and which one is live. Tail the runtime logs of a session or instance.