A thin command layer. No logic lives here. The CLI and the Python API (sbt2.core.backtest) are two front-ends on equal footing over api: every feature exists in both (see Library). Built with typer; the entry point is sbt2 = "sbt2.cli:app".

Command	What it does
sbt2 download	Fetch raw data from a source (e.g. --source bybit) into the root's raw/.
sbt2 ingest	Convert raw files from raw/ into the catalog, for --source, --symbol (repeatable) and an inclusive --start / --end range of UTC days. --type picks data types (default: all the source serves); --reingest accepts a changed instrument spec and rebuilds its days (see Data). Days without a raw file are logged as missing; a failure exits with status 1.
sbt2 data status	Show which symbols, data types and days are in the catalog, and flag gaps.
sbt2 run <spec.toml>	Expand a spec file and execute the runs, in parallel, fetching missing data first; without part, runs train and validation. --memory-budget SIZE and --memory-per-run SIZE override the run settings for this invocation (see Run settings in Run). `--launcher uncapped
sbt2 report tearsheet <run_id>	Write a stored run's tearsheet (see Results), to tearsheet.html in the run's folder unless --output PATH names another file, and log where. The benchmark is the strategy's default; --benchmark NAME[:ARG] overrides it with a build_benchmark name, its argument after the first : (buy-and-hold, buy-and-hold:ETHUSDT-PERP.BYBIT, equal-weight, external:prices.csv, none). The run is priced from the root's catalog.
sbt2 report parts <run_id>	Print compare_parts for the run as a table, one row per part with its run_id, dates and headline metrics, then degradation: one row per headline metric, one column per part and per change.
sbt2 report batch <batch_id>	Print batch_table: one row per run of the batch, the parameters that vary across it, then the headline metrics.
sbt2 report study <name>	Print study_table: one table per part, in split order, with a row per run of the study: run_id, the parameters that vary across the study, then the headline metrics.
sbt2 studies list	Show one row per study, by name: its strategy and how many runs it holds.
sbt2 runs list | show | delete	Query and manage the results store. list shows one row per finished run, oldest first: run_id, strategy, part, dates, net return, Sharpe, max drawdown and trade count; --strategy and --part filter it. show <run_id> prints the run's summary, then its resolved spec as JSON; a failed run has no summary, and show says so. delete <run_id> asks first unless --yes, removes the run's folder, partial ones of failed runs included, and refuses test runs.

sbt2-server (in sbt2-server, entry point sbt2-server = "sbt2.server.cli:app") starts the GUI's server (see Server on Architecture) and serves until interrupted.

Option	What it does
--data PATH	The data root whose runs the server serves, reading PATH/results and pricing tearsheets from PATH/catalog, and whose PATH/known_gaps.toml it edits. Default $SBT2_DATA; required, with no fallback to the working directory: without either, sbt2-server exits with status 2.
--config PATH	The config folder whose PATH/venues.toml the server edits. Default $SBT2_CONFIG; required, like --data.
--host HOST	The address to bind. Default $SBT2_SERVER_HOST, else 127.0.0.1.
--port PORT	The port to listen on, for WebSocket and GET /health. Default $SBT2_SERVER_PORT, else 8765.

The API token comes only from SBT2_SERVER_TOKEN, never from an option, so it stays out of the process list. It is required: without it, sbt2-server exits with status 2, naming the variable. The server logs to stderr at INFO. The container image sets SBT2_SERVER_HOST=0.0.0.0, SBT2_DATA and SBT2_CONFIG for it (see Deployment on Architecture).

Option	Scope	What it does
--log-level DEBUG|INFO|WARNING|ERROR	global, before the command	Level of the sbt2 logger and of nautilus's stdout log. Default INFO.
--log-file PATH	global	Also write the sbt2 log to a file.
--data PATH	every command that reads or writes data, after the command	The data root: raw/, catalog/, results/, known_gaps.toml and settings.toml live under it. Default $SBT2_DATA; required, so with neither the command exits with status 2, naming both, and creates nothing.
--config PATH	run, after the command	The config folder, whose venues.toml holds the venue profiles. Default $SBT2_CONFIG; required, so with neither run exits with status 2, naming both, and creates nothing. A folder without venues.toml fails the run with MissingConfigError, naming the file: logged, exit status 1.

Venue profiles come from the config folder's venues.toml (see Spec), read afresh on every run, the known gaps from the data root's known_gaps.toml (see Data sources); nothing is read from the working directory. run is the only command that reads the config folder: the others work from stored runs, whose venue arguments are in their spec.json.

An unknown run, batch, study or benchmark, or a failed run given to report tearsheet, fails like any other command: logged, exit status 1; an unknown study names the known ones.

sbt2 run loads the spec file's runs and hands them to batch (see Run) with the default Results store and the launcher --launcher names. An unknown launcher fails before any run starts. On failure it logs the traceback, naming the failed run and its folder, and exits with status 1.

• Standard Python logging (levels, optional log file) plus progress bars for batches, downloads and ingests.
• No print in library code.
• The CLI configures only the sbt2 logger (stderr, plus the optional file), never the root logger.