Osmosis CLI Command Reference

Run osmosis -h to see all available commands. Every sub-command supports -h / --help. The global output flags --json and --plain are position-independent — they work before or after the command:

osmosis --json <command>
osmosis <command> --json

Use --json for automation and AI agents. Use --plain for low-noise shell output.

quickstart

Interactive setup: sign in, clone your workspace, and get your first agent prompt.

osmosis quickstart [--workspace NAME]

Option	Type	Default	Description
`-w`, `--workspace`	`str`	Current clone, otherwise prompt	Workspace name to set up

The wizard authenticates the CLI, resolves which workspace to use, waits for the workspace repository to be connected and clones it, reports whether billing is set up, then asks what you want to do. Training a model, evaluating a model on a dataset, and running a benchmark each print an agent prompt for that goal; exploring prints documentation links instead. When you run osmosis quickstart from inside a workspace clone, the wizard picks up that workspace from the git remote. From an empty or unrelated directory, it lists the workspaces you belong to and asks you to pick one. Pass --workspace <name> to skip the picker and target a specific workspace by name. This is useful when you belong to more than one workspace. It is safe to re-run: every step checks the current state before changing anything, so an already-configured workspace gets an all-clear report and goes straight to asking what you want to do next. Re-running from an empty directory reuses the last clone path recorded for that workspace when it still exists. The wizard needs an interactive terminal and runs in rich output mode only, so it is not available with --json or --plain — see Onboarding for the manual steps it automates.

auth

Manage CLI authentication.

Command	Description
`osmosis auth login`	Authenticate via browser OAuth or personal access token
`osmosis auth logout`	Revoke the current session and clear local credentials
`osmosis auth whoami`	Show the authenticated user, token expiration, and linked workspace

osmosis auth login
osmosis auth whoami

When you run osmosis auth whoami from inside a workspace repository, the CLI also resolves the linked Platform workspace. --json reports it as a workspace object (id, name, role); other modes show Workspace and Role rows. Outside a workspace repository, or when the repository is not linked to a Platform workspace, workspace is null and the rest of the output is unchanged. The command always verifies the stored credential or OSMOSIS_TOKEN against the Platform, so it needs network access and it fails with AUTH_REQUIRED when you are logged out or your session has expired.

doctor

Inspect and optionally repair the workspace directory scaffold.

osmosis doctor [path] [--fix]

Argument / Option	Type	Default	Description
`path`	`path`	`.`	Path inside the workspace directory
`--fix`	flag	—	Create missing scaffold directories without overwriting existing files

When you are logged in and the workspace directory has a Platform-connected origin remote, doctor also reports the linked workspace (Linked workspace: <name>, or the workspace resource field in --json). The lookup is best-effort — offline or logged out, the field is null and doctor still works.

template

Add starter rollouts from the Osmosis workspace template catalog.

template list

osmosis template list

Lists available starter templates.

template apply

osmosis template apply <name> [--force]

Argument / Option	Type	Description
`name`	`str` (required)	Template name from `osmosis template list`
`-f`, `--force`	flag	Replace the template-owned rollout directory and config files

rollout

Create local rollout scaffolds and list synced rollouts.

rollout init

osmosis rollout init <name> [--force]

Creates:

rollouts/<name>/main.py
rollouts/<name>/pyproject.toml
rollouts/<name>/README.md
configs/eval/<name>.toml
configs/training/<name>.toml

Argument / Option	Type	Description
`name`	`str` (required)	Lowercase rollout name that starts with a letter and then uses letters, digits, or hyphens. `default` is reserved.
`-f`, `--force`	flag	Replace existing scaffold paths for this rollout

rollout list

osmosis rollout list [--limit N] [--all] [--branch NAME]

Option	Type	Default	Description
`--limit`	`int`	`50`	Maximum number of rollouts to show
`--all`	flag	—	Show all rollouts
`--branch`	`str`	Repository default	Show rollouts synced from this branch

eval

Submit and manage evaluation runs, and run LLM-as-judge rubric scoring locally.

eval submit

Submit an evaluation run from a TOML config under configs/eval/. The platform clones the workspace repository identified by the origin remote and runs the rollout server-side, so push your commits before submitting.

osmosis eval submit <config_path> [--yes] [--secrets-file PATH]

Argument / Option	Type	Description
`config_path`	`path` (required)	Eval TOML under `configs/eval/`
`-y`, `--yes`	flag	Skip the confirmation prompt
`--secrets-file`	`path`	Dotenv file supplying values for `[secrets].required` names; `-` reads stdin

osmosis eval submit configs/eval/my-rollout.toml

# Supply per-run secret values without saving them to the store
osmosis eval submit configs/eval/my-rollout.toml --secrets-file .env.run
vault read -field=env secret/eval | osmosis eval submit configs/eval/my-rollout.toml --secrets-file - --yes

Each name in [secrets].required resolves in this order: --secrets-file, the CLI process environment, an existing personal or workspace secret, then a hidden prompt when stdin is a TTY. Existing stored values are resolved server-side. Values supplied locally by file, environment, or prompt are sent with this submission’s TLS request but are not added to the Osmosis secret store or persistent run config, so supply them again for later runs. Outside a TTY, names still unresolved after the stored-secret check are reported all at once so CI shows the full gap. See [env] and [secrets] for the config-side rules.

Config values come from the local TOML file. Rollout code comes from the synced workspace repository. Use [experiment].branch or [experiment].commit_sha to select the source; they are mutually exclusive.

eval list

List evaluation runs for the current workspace repository, including each run’s status, average reward, and progress.

osmosis eval list [--limit N] [--all]

Option	Type	Default	Description
`--limit`	`int`	`50`	Maximum number of evaluation runs to show
`--all`	flag	—	Show all evaluation runs

eval info

Show details, results, and metrics for an evaluation run.

osmosis eval info <run-name> [--output PATH]

Argument / Option	Type	Description
`name_or_id`	`str` (required)	Evaluation run name or ID
`-o`, `--output`	`path`	Run output root. Defaults to `.osmosis/evals/<name>/` in rich mode.

The detail fields show name, status, progress (rows completed and percent), duration, pass rate, tokens used, submission and completion times, and the dataset, model, and rollout the run used. Two sections follow:

Configuration — entrypoint, the resolved config values (limit, n, batch_size, pass_threshold, timeouts), branch, short commit SHA, resolved secret scopes, and [env] keys.
Results — graded, passed, failed, and skipped counts, pass threshold, reward stats (mean, std, min, median, max), and pass@k.

eval info reports aggregates only. Use eval logs for platform logs and eval download for row-level trajectories, artifacts, metrics, and logs. For completed runs, eval info also fetches metrics (duration, pass rate, tokens used, reward statistics, and pass@k) from the platform and exports them as JSON:

In rich mode, the CLI saves metrics to .osmosis/evals/<name>/metrics.json by default when metrics are available.
In JSON or plain mode, pass -o / --output to set the run output root; the CLI writes metrics.json inside that directory.
The CLI creates parent directories automatically.
If metrics are not yet available (for example, the run is still pending), the CLI prints a notice instead of writing a file.

osmosis eval info my-eval-run
osmosis --json eval info my-eval-run -o ./eval-outputs/

-o / --output now points at the run output root, not a metrics filename. Legacy files under .osmosis/metrics/ are left in place — delete them manually once you have re-run eval info under the new layout.

eval download

Download evaluation run outputs — metrics, trajectories, artifacts, and logs — from the platform to your local disk.

osmosis eval download <run-name> [--type TYPES] [--rows ROWS] [--output PATH] [--overwrite] [--yes]

Argument / Option	Type	Default	Description
`name_or_id`	`str` (required)	—	Evaluation run name or ID
`--type`	`str`	`metrics,trajectories`	Comma-separated selector: `metrics`, `trajectories`, `artifacts`, `logs`, or `all`. Replaces the default selection.
`--rows`	`str`	—	Rows to include for trajectories and artifacts, for example `3,7,10-20`. Each selected row includes all of its runs.
`-o`, `--output`	`path`	`.osmosis/evals/<name>/`	Run output root. Filenames and subdirectories below the root are fixed.
`--overwrite`	flag	—	Re-download files that already exist locally with a matching size.
`-y`, `--yes`	flag	—	Skip the confirmation prompt for downloads larger than 100 MiB.

Downloads land in a fixed run-scoped layout so re-running the command resumes cleanly:

.osmosis/evals/<run-name>/
├── metrics.json
├── summary.jsonl
├── trajectories/row_<row>_run_<n>.json
├── artifacts/row_<row>_run_<n>/...
└── logs.txt

Behavior:

The CLI skips files whose local size matches the platform manifest unless you pass --overwrite, so re-running the command only fetches missing or partial files.
Downloads over 100 MiB in total require confirmation; pass --yes to skip the prompt in scripts.
The CLI requests presigned URLs in bounded batches and downloads up to eight files concurrently. Each file writes to a *.partial sibling, then moves into place atomically once the CLI verifies its size.
The CLI retries failed files with backoff. If some files still fail, it reports each failed path and exits partial — re-run the command to retry only what is missing.
Pending runs fail early with a clear message; the platform performs authoritative path validation.

# Default: metrics + trajectories for the whole run
osmosis eval download my-eval-run

# Only artifacts for rows 3, 7, and 10–20
osmosis eval download my-eval-run --type artifacts --rows 3,7,10-20

# Everything, into a custom root, non-interactive
osmosis eval download my-eval-run --type all -o ./eval-outputs/ --yes

eval stop

Stop a pending or running evaluation run.

osmosis eval stop <run-name> [--yes]

Argument / Option	Type	Description
`name_or_id`	`str` (required)	Evaluation run name or ID
`-y`, `--yes`	flag	Skip the confirmation prompt

eval logs

Show the most recent lifecycle logs for an evaluation run, oldest first. Use this to diagnose failed runs.

osmosis eval logs <run-name> [--limit N] [--cursor CURSOR]

Argument / Option	Type	Default	Description
`name_or_id`	`str` (required)	—	Evaluation run name or ID
`--limit`	`int`	`50`	Entries per page (1–200)
`--cursor`	`str`	—	Cursor from a previous page’s `next_cursor`

When older entries exist, --json output includes a non-null next_cursor. Pass it back with --cursor to page further back in time.

eval rubric

Run LLM-as-judge evaluation locally over a JSONL conversation file. This sub-command does not require a workspace directory or platform authentication and does not run a rollout.

osmosis eval rubric -d <data.jsonl> -r <rubric> --model <model>

Option	Type	Default	Description
`-d`, `--data`	`str` (required)	—	Path to JSONL conversations
`-r`, `--rubric`	`str` (required)	—	Rubric text or `@file.txt`
`--model`	`str` (required)	—	Judge model in LiteLLM format
`-n`, `--number`	`int`	`1`	Number of evaluation runs per record
`-o`, `--output`	`str`	—	Path for JSON output
`--api-key`	`str`	—	API key for the judge model
`--timeout`	`float`	—	Request timeout in seconds
`--score-min`	`float`	`0.0`	Minimum score
`--score-max`	`float`	`1.0`	Maximum score

benchmark

Discover managed benchmarks and submit, inspect, and manage benchmark runs for the current workspace. benchmark list and benchmark info act on benchmarks themselves: the workspace list and one benchmark’s page. Commands for an individual run live under benchmark runs.

benchmark list

List the benchmarks added to the current workspace.

osmosis benchmark list [--limit N] [--all]

Option	Type	Default	Description
`--limit`	`int`	`50`	Maximum number of benchmarks to show
`--all`	flag	off	Fetch every benchmark

The table mirrors the Platform’s benchmarks page: Name, the shell-safe Key, Last Run, Tasks, and Added By. Last Run reads as the newest run’s state, its age, and its name (Finished · 2d ago · brave-otter). The key, the exact case-sensitive name, and the ID all work in [experiment].benchmark. JSON list items include run_count, running_count, last_run_at, last_run_status, last_run_name, and creator_name. A Harbor registry benchmark’s task list pages in from the registry after the benchmark is added. Until it finishes, Last Run reports the sync instead of a run (Syncing · 412 / 500 tasks), Tasks stays empty, and a run cannot be submitted against it. A benchmark whose sync failed reports the reason in Last Run, shows unavailable under Tasks, and returns a sync_error; retry its sync from the benchmark’s page in the Platform. The reported platform_url opens that page, with its leaderboard and runs.

benchmark info

Show a benchmark’s summary, leaderboard, and runs.

osmosis benchmark info <key_name_or_id> [--limit N] [--all]

Argument / Option	Type	Default	Description
`key_name_or_id`	`str` (required)	—	Benchmark key, exact name, or ID
`--limit`	`int`	`50`	Maximum number of runs to show in the runs table
`--all`	flag	off	Show every run in the runs table

The rich output opens with the benchmark summary (the source’s upstream page, runner, task and category counts, named task sets, harness and judge requirements, and pass threshold), followed by the benchmark’s leaderboard and a table of the workspace’s runs on it. --limit and --all apply to the runs table. When a benchmark’s published scores were measured on a specific harness, that harness is reported as the default. The LLM Judge row reads Required (default: <model>) when the run chooses the judge model, API key only (pinned grader) when the adapter pins its own grader and the run supplies only judge_api_key_secret, and – when the benchmark has no judge. JSON output also includes the complete task manifest and a leaderboard array:

osmosis --json benchmark info terminal-bench-2-1

Each leaderboard entry carries the rank and a tied flag (set when the paired test can’t separate that entrant from the top-ranked one, so it shares rank 1). It also reports the task set (full or parity), the harness and model, and the scoring run’s id, name, and platform_url. The five ranked metrics follow: pass_at_1 with its confidence interval, pass_at_k, the per-task cost_per_task, mean_duration_seconds, and tokens_per_task. Those are the same metrics the Platform’s leaderboard ranks by. Each task in the JSON manifest has a difficulty field with the value easy, medium, hard, or null. null means the source did not provide a difficulty, and clients must not infer one. For HLE, benchmark info also marks parity as the recommended named task set. Omit [tasks] from the config to select the full benchmark; use task_names, categories, or a listed task_set for a subset.

benchmark submit

Submit a benchmark run from an Osmosis TOML config under configs/benchmark/.

osmosis benchmark submit <config_path> [--yes] [--secrets-file PATH]

Argument / Option	Type	Description
`config_path`	`path` (required)	Benchmark TOML under `configs/benchmark/`
`-y`, `--yes`	flag	Skip the confirmation prompt
`--secrets-file`	`path`	Dotenv file supplying values for `[secrets].required` names; `-` reads stdin

osmosis benchmark submit configs/benchmark/terminal-bench-smoke.toml

# Supply a per-run token without saving it to the secret store
osmosis benchmark submit configs/benchmark/hle-parity.toml --secrets-file .env.run

The benchmark named in [experiment].benchmark must already be added to the current workspace. The command previews the selected tasks, agents, attempts, concurrency, and resolved secret scopes before submission. [secrets].required names use the same file → process environment → stored personal/workspace secret → hidden TTY prompt order as eval and training. Locally supplied values are labeled Run and sent with this submission’s TLS request, but are not added to the Osmosis secret store or persistent run config; stored values are resolved server-side. Every other secret reference (model api_key_secret, harness_api_key_secret, judge_api_key_secret, [verifier].required) must already exist in the workspace or personal scope. The result includes the generated run name, task count, status, and platform_url. See Benchmarks for the CLI workflow and Configuration Files for the full TOML schema.

benchmark runs list

List benchmark runs for the current workspace. The table matches the Platform’s runs table: Name, Status, Progress, Benchmark, Agents, Best Pass@1, Submitted, and Submitted By.

osmosis benchmark runs list [--limit N] [--all]

Option	Type	Default	Description
`--limit`	`int`	`50`	Maximum number of benchmark runs to show
`--all`	flag	—	Show all benchmark runs

benchmark runs info

Show a benchmark run’s configuration, agents, progress, result totals, and metrics.

osmosis benchmark runs info <run-name>

Argument	Type	Description
`name_or_id`	`str` (required)	Benchmark run name or ID

The summary reports status, progress, duration, best pass@1, and submission details. The Agents section scores each agent the way the run’s Agent Results table does: rank, pass@1 with its interval, the deepest pass@k, and per-task cost, time, and tokens. Results totals report outcome counts, input and output tokens, and LLM Cost, which is model spend on your own provider keys and is not billed by Osmosis. The result includes platform_url, which opens the run in the Platform.

benchmark runs logs

Show recent lifecycle logs for a benchmark run, oldest first. Use this to monitor progress and diagnose failures.

osmosis benchmark runs logs <run-name> [--limit N] [--cursor CURSOR]

Argument / Option	Type	Default	Description
`name_or_id`	`str` (required)	—	Benchmark run name or ID
`--limit`	`int`	`50`	Entries per page (1–200)
`--cursor`	`str`	—	Cursor from a previous page’s `next_cursor`

When older entries exist, --json output includes a non-null next_cursor. Pass it back with --cursor to page further back in time.

benchmark runs stop

Stop a pending, queued, or running benchmark run.

osmosis benchmark runs stop <run-name> [--yes]

Argument / Option	Type	Description
`name_or_id`	`str` (required)	Benchmark run name or ID
`-y`, `--yes`	flag	Skip the confirmation prompt

benchmark runs download

Download benchmark summary metrics, task-level results, result artifacts, or logs.

osmosis benchmark runs download <run-name> [--type TYPES] [--output PATH] [--overwrite] [--yes]

Argument / Option	Type	Default	Description
`name_or_id`	`str` (required)	—	Benchmark run name or ID
`--type`	`str`	`summary,results`	Comma-separated selector: `summary`, `results`, `artifacts`, `logs`, or `all`. Replaces the default selection.
`-o`, `--output`	`path`	`.osmosis/benchmarks/<name>/`	Run output root. Filenames and subdirectories below the root are fixed.
`--overwrite`	flag	—	Re-download files that already exist locally with a matching size.
`-y`, `--yes`	flag	—	Skip the confirmation prompt for large downloads.

Downloads use a fixed run-scoped layout:

.osmosis/benchmarks/<run-name>/
├── summary.csv
├── results.csv
├── logs.txt
└── artifacts/<result-id>/<path>

The CLI skips complete local files unless --overwrite is set, writes partial downloads atomically, and reports any files that still fail after retrying. Re-run the same command to fetch only missing or incomplete files. pending and queued runs do not have downloadable outputs. Downloads from a running run are snapshots; use --overwrite to refresh existing files.

secret

Manage Platform environment_secret records. Train and eval configs reference them through [secrets].required. Benchmark configs reference model (api_key_secret), harness (harness_api_key_secret), and judge (judge_api_key_secret) records, along with any dataset-verifier records listed in [verifier].required. Osmosis never returns secret values to the CLI — these commands show or accept names and metadata only. Values are read from a hidden interactive prompt or a named environment variable, never as a plaintext command-line argument. Each secret has a scope:

Workspace secrets are shared across the workspace. Creating, updating, or deleting them requires an admin or owner role.
Personal secrets are private to you. When a workspace and a personal secret share a name, your personal value wins at run time. Use personal secrets for overrides, such as swapping in your own provider API key without affecting teammates.

Secret names must match ^[A-Z][A-Z0-9_]*$ (SCREAMING_SNAKE_CASE).

secret list

List secrets visible to you in the current workspace (names and metadata only — never values).

osmosis secret list [--scope all|workspace|personal] [--limit N] [--all]

Option	Type	Default	Description
`--scope`	`str`	`all`	Filter by scope: `all`, `workspace`, or `personal`
`--limit`	`int`	`50`	Maximum number of secrets to show
`--all`	flag	—	Show all secrets

The output includes a Scope column labeled Workspace or Personal.

osmosis secret list
osmosis secret list --scope personal

secret set

Create or update (upsert) a secret. The CLI reads the value from the env var named by --env VARNAME; without that flag, you type the value at a hidden interactive prompt. In --json or --plain (non-interactive) modes, you must pass --env.

osmosis secret set <name> [--scope workspace|personal] [--env VARNAME]

Argument / Option	Type	Default	Description
`name`	`str` (required)	—	Secret name in `^[A-Z][A-Z0-9_]*$`
`--scope`	`str`	`personal`	`personal` (private to you) or `workspace` (shared with the workspace)
`--env`	`str`	—	Read the value from this environment variable

# Create or update your personal secret (default scope):
osmosis secret set OPENAI_API_KEY

# Read the value from an env var (recommended for scripts and CI):
OPENAI_API_KEY=sk-... osmosis secret set OPENAI_API_KEY --env OPENAI_API_KEY

# Workspace-shared secret (requires admin or owner role):
OPENAI_API_KEY=sk-... osmosis secret set OPENAI_API_KEY --scope workspace --env OPENAI_API_KEY

secret delete

Delete a secret within the given scope. The CLI prompts you to confirm unless you pass --yes.

osmosis secret delete <name> [--scope workspace|personal] [--yes]

Argument / Option	Type	Default	Description
`name`	`str` (required)	—	Secret name to delete
`--scope`	`str`	`personal`	Scope of the secret to delete
`-y`, `--yes`	flag	—	Skip the confirmation prompt

osmosis secret delete OPENAI_API_KEY --yes
osmosis secret delete OPENAI_API_KEY --scope workspace --yes

dataset

Manage platform datasets for the current workspace repository.

Command	Description
`osmosis dataset upload <file> [--overwrite] [--yes]`	Upload a CSV, JSONL, or Parquet dataset
`osmosis dataset download <name> [-o PATH] [--overwrite]`	Download a dataset file
`osmosis dataset list [--limit N] [--all]`	List datasets
`osmosis dataset info <name>`	Show dataset details and processing status
`osmosis dataset preview <name> [--rows N]`	Preview uploaded dataset rows
`osmosis dataset validate <file>`	Validate a dataset locally
`osmosis dataset logs <name> [--limit N] [--cursor CURSOR]`	Show lifecycle logs for a dataset (oldest first)

osmosis dataset upload data/train.jsonl
osmosis dataset info train
osmosis dataset preview train --rows 5

Dataset names are derived from the file name without its extension. If a dataset with that name already exists, the upload fails — pass --overwrite to replace it (the old record is soft-deleted). Use osmosis dataset logs <name> to diagnose failed uploads. --limit accepts 1–200 entries (default: 50). When older entries exist, the --json output includes a non-null next_cursor; pass it back with --cursor to page further back in time.

osmosis dataset upload requires --yes (-y) in non-interactive modes (--json, --plain, or when stdin is piped). Running without it raises INTERACTIVE_REQUIRED, even with --overwrite. Add --yes to CI jobs and scripted uploads to skip the confirmation prompt.

train

Submit and manage training runs for the current workspace repository.

train submit

osmosis train submit <config_path> [--yes] [--secrets-file PATH]

Argument / Option	Type	Description
`config_path`	`path` (required)	Training TOML under `configs/training/`
`-y`, `--yes`	flag	Skip confirmation prompt
`--secrets-file`	`path`	Dotenv file supplying values for `[secrets].required` names; `-` reads stdin

Config values come from the local TOML file. Training code comes from the synced workspace repository. [secrets].required names use the same file → process environment → stored personal/workspace secret → hidden TTY prompt resolution order documented under eval submit; locally supplied values are sent with the current TLS request but are not added to the Osmosis secret store or persistent run config.

train info

osmosis train info <run-name> [--output PATH]

Shows run details, checkpoints, and metrics. The summary panel includes progress (current_step / total_steps with percent complete) and the latest reward while the run is in flight. In rich mode, metrics are saved under .osmosis/metrics/ by default.

train logs

Show the most recent lifecycle logs for a training run, oldest first. Use this to diagnose failed or crashed runs.

osmosis train logs <run-name> [--limit N] [--cursor CURSOR]

Argument / Option	Type	Default	Description
`name`	`str` (required)	—	Training run name
`--limit`	`int`	`50`	Entries per page (1–200)
`--cursor`	`str`	—	Cursor from a previous page’s `next_cursor`

When older entries exist, --json output includes a non-null next_cursor. Pass it back with --cursor to page further back in time.

Other train commands

osmosis train list [--limit N] [--all]
osmosis train stop <run-name> [--yes]

train list shows status, current step / total steps, and the latest reward for each run.

model

Manage base (foundation) models and LoRA models produced by training runs. Deploying a LoRA model exposes it for inference.

model list

List base models and LoRA models for the current workspace as two independently paginated sections (base first, then LoRA). The base table shows Name, Created, and Created By. The LoRA table shows Name, Base Model, Training Run, Checkpoint Step, Training Reward, and Created. When deployment info is available, the LoRA table also shows Deployment Status and a deployment-quota summary below it (for example, 2 of 5 inference deployments used).

osmosis model list [--type all|base|lora] [--limit N] [--all]

Option	Type	Default	Description
`--type`	`str`	`all`	Filter to a single list: `all`, `base`, or `lora`
`--limit`	`int`	`50`	Maximum number of models to show per type
`--all`	flag	—	Show all models of each type

--limit and --all apply to each list independently, and each list carries its own pagination cursor (next_offset).

osmosis model list
osmosis model list --type lora
osmosis model list --type base --limit 50
osmosis --json model list

--json output keys each list separately, so the structure itself identifies which list is which:

{
  "base_models": { "items": [...], "next_offset": null },
  "lora_models": { "items": [...], "next_offset": null },
  "active_deployments": 2,
  "max_active_deployments": 5
}

When deployment info is available, the active_deployments / max_active_deployments quota keys appear for --type all and --type lora, but not for --type base.

model info

Show details for a single LoRA model: base model, training run, checkpoint step, training reward, Hugging Face export status, and deployment status when deployment info is available.

osmosis model info <lora-model>

model deploy

Deploy or reactivate a LoRA model by name.

osmosis model deploy <lora-model>

model undeploy

Transition a LoRA model’s deployment to inactive (idempotent). The LoRA model remains in the training run history.

osmosis model undeploy <lora-model>

The standalone osmosis deployment, osmosis deploy, and osmosis undeploy commands have been removed. Use osmosis model deploy <lora-model> and osmosis model undeploy <lora-model> instead.

upgrade

Self-upgrade the CLI to the latest version published on PyPI.

osmosis upgrade

The CLI auto-detects your install method (pip, pipx, or uv tool) and runs the appropriate upgrade command.

​quickstart

​auth

​doctor

​template

​template list

​template apply

​rollout

​rollout init

​rollout list

​eval

​eval submit

​eval list

​eval info

​eval download

​eval stop

​eval logs

​eval rubric

​benchmark

​benchmark list

​benchmark info

​benchmark submit

​benchmark runs list

​benchmark runs info

​benchmark runs logs

​benchmark runs stop

​benchmark runs download

​secret

​secret list

​secret set

​secret delete

​dataset

​train

​train submit

​train info

​train logs

​Other train commands

​model

​model list

​model info

​model deploy

​model undeploy

​upgrade

quickstart

auth

doctor

template

template list

template apply

rollout

rollout init

rollout list

eval

eval submit

eval list

eval info

eval download

eval stop

eval logs

eval rubric

benchmark

benchmark list

benchmark info

benchmark submit

benchmark runs list

benchmark runs info

benchmark runs logs

benchmark runs stop

benchmark runs download

secret

secret list

secret set

secret delete

dataset

train

train submit

train info

train logs

Other train commands

model

model list

model info

model deploy

model undeploy

upgrade