Configuration

Overview#

Ster has no application configuration file. Runtime behavior is fully selected by CLI arguments or the equivalent ster request body fields, plus compile-time Cargo features and two Candle CPU thread environment variables. There is no precedence stack: omitted choices take the defaults below, and every training, sampling and judging number is required — Ster assumes none, and a command or body without one is refused naming it.

CLI keys#

These are all runtime CLI keys. --help and --version are clap controls, not Ster configuration.

Exact command behavior: CLI reference. Layer grammar: layer selection.

Ster passes temperature/top-p values to Candle without an additional range check. Invalid sampling parameters may therefore surface as a Candle error; use temperature > 0 and 0 < top_p <= 1. Strength is not clipped.

Request body keys#

Request JSON uses camelCase. Unknown JSON fields are ignored by serde. Choices with a default are filled before required-field validation; a required number that is missing is refused at deserialization, naming it (missing field \learningRate\`). All path values are paths on the filesystem of the ster request` process, and relative paths use its working directory.

The protocol, events, exit statuses and serialization behavior are in the desktop request reference.

Build-time features#

The default feature set is empty. Devices never auto-detect and there is no runtime fallback: a CPU-only binary refuses metal/cuda. Every backend defaults to F32. --precision f16 and --precision bf16 map the frozen base weights at half width instead, and what a run trains stays F32 regardless; bf16 has no CPU matmul kernel in Candle and is refused on cpu at load (precision).

Environment and local files#

Ster source reads exactly two environment variables, and both belong to the optional Brama pair generator: BRAMA_URL, read by base_url, and BRAMA_BEARER, read by bearer — the only two env::var calls in the whole source, both in src/brama.rs.

Both are read on one code path only — the Brama generator behind `ster pairs synthesize` and its ster request pairs/synthesize equivalent. Every other command ignores them, so neither variable changes how a model is resolved, trained, or steered.

Ster's Candle dependency honors two CPU thread knobs of its own:

RAYON_NUM_THREADS sizes Candle's Rayon pool and CPU matmul parallelism; CANDLE_NUM_THREADS sizes its barrier pool. Missing, non-integer, zero, or negative values silently use the hardware fallback.

Hub resolution calls hf-hub Api::new, not its environment-aware builder. Consequently HF_HOME and HF_ENDPOINT do not change Ster 0.13. The default client uses:

• cache: ~/.cache/huggingface/hub;
• optional bearer token file: ~/.cache/huggingface/token.

Apart from those two Brama variables there is no Ster environment key for model, device, revision, cache, offline mode, output directory, or log level: each of those is a CLI flag or a ster request body field. The only endpoint and token Ster takes from the environment are the pair generator's, never the model's.

Model config keys#

Ster does not own a separate model-config schema. It requires top-level model_type: "llama", then deserializes the whole config.json through Candle 0.11's LlamaConfig. Dimensions, heads, rope settings, EOS ids, context length, norm epsilon, and tied embeddings therefore come from the checkpoint, not Ster flags. Required files and resolution rules are documented in model resolution.

Repository release metadata, and the Stado install path#

.wisent-release.json configures repository delivery, not the installed binary. Its complete present key tree is: schema_version, product, releases; version_source.{kind,path,pattern}; platforms.<name>.{runner_platform,quality,build.argv,stage}; and promotion.{channels,reconcile}, inputs, deliveries. It declares darwin-arm64 and linux-amd64, both built by sh scripts/build-release.sh, promoted on stable, with no quality commands, inputs, or deliveries. Changing it cannot configure a running Ster process.

The reader of that manifest is Stado, which is how a built Ster actually reaches a machine. stado product status ster --surface cli reports the recipe it installs from — kind stado-release, repository wisent-ai/ster, manifest .wisent-release.json — together with the source_revision it was built from and the paths it wrote:

$ stado product status ster --surface cli
product = ster
surface = cli
status = stale
recipe = {'surface': 'cli', 'kind': 'stado-release', 'repository': 'wisent-ai/ster', 'manifest': '.wisent-release.json'}
installed_paths = ['/Users/<you>/.stado/bin/ster', '/Users/<you>/.local/bin/ster']
source_revision = 155908c5c5260ce96d83a864f9600218d8547d97

The lifecycle verbs are Stado's, not Ster's:

Each update copies the binary it replaces under ~/.stado/products/ster/backups/<timestamp>/ster, which is what stado product rollback restores; on this machine that directory held 17 retained generations when this page was written. scripts/build-release.sh exists to serve this path: it leaves the bare binary beside the tarball because, in its own words, "a stado-release install copies individual bin/ members out of .wisent-output and never unpacks a tarball". A status of stale means the installed revision is behind origin/main, which stado product update (or stado product sync) resolves.

None of this configures a running Ster process, and Ster never calls Stado: the dependency runs one way, from the installer to the installed binary. cargo install remains the path that needs no Stado at all.

Local pair-set workspace#

Ster has no behavior configuration file, but imported user data has durable state. It lives under $XDG_DATA_HOME/ster when XDG_DATA_HOME is set, otherwise ~/.local/share/ster. workspace.json indexes canonical copies under pairs/ and names one active set. The manifest and accepted pair files are written atomically; credentials and prompt contents are never printed by workspace show.