First-time setup — cyberine setup
Cyberine starts empty; cyberine setup is the guided onboarding (re-runnable, idempotent):
cyberine setup # interactive: auth providers -> pick + pin a chat model -> show capabilities
cyberine setup --status # read-only: print current state (no prompts, no writes)It (1) shows which providers are authed + which CLIs are logged in, (2) shows a checkbox list of the
unauthed API-key providers — toggle the ones you want (Up/Down move, Space toggle, a all, Enter
confirm, Ctrl-C cancel), then paste + validate a key for each selected one — (3) lets you pick + pin a
chat planner default (provider, then model from the local catalog), and (4) lists the task workers available now.
Task dispatch stays auto-routed — setup does not pin a build fleet. Set things up gradually:
re-run anytime to add a provider or change the default. Non-interactive (piped) runs print state +
capabilities without prompting.
cyberine setup --status additionally prints the detection table (kvywt, 2026-09-18) — one row
per detected worker and per declared seat, five columns:
WORKER CREDENTIAL BILLING STR REPORTED MODEL
loop-commandcode-build env var subscription (profile) 3 deepseek/deepseek-v4-flash
loop-commandcode-free-build env var free (auth) 2 (live-catalog-free)
codex file OAuth (ChatGPT login) subscription (auth) 4 (default)
claude-kt seat token file subscription (auth) 4 claude-sonnet-5
where each credential was found:
loop-commandcode-build env CMD_API_KEY
codex ~/.codex/auth.json
claude-kt ~/.cyberine/seats/kt.txt mode 600
loop-deepseek-build env DEEPSEEK_API_KEY [global: disabled in the global fleet.json]CREDENTIAL is the mechanism (env var, keychain OAuth, file OAuth (ChatGPT login),
seat token file, account login (oauth, stored in keychain), …), BILLING the class plus the
source that decided it (auth / profile / endpoint / fleet.json), STR the 1-5 model
strength rank (docs/providers/model-strength.md), and REPORTED MODEL the model a real run last
reported, falling back to the profile default when no run has reported one. The block underneath
names the LOCATION each credential was found at. No credential value is ever read into a string or
printed — the table is built from src/core/workerDetection.ts, which returns a mechanism and a
location and nothing else.
Since k5jzv (2026-09-18) a location line also carries a trailing [global: <reason>] when that
worker's entry in the GLOBAL $CYBERINE_HOME/fleet.json disables it — either disabled in the global fleet.json (a plain enabled: false) or auto-disabled (<kind>): <evidence> (a k2g29
autoDisabled block from an out-of-credits or auth-failure refusal) — so the operator sees, right
next to the detection evidence that made a worker look usable, exactly why the detected preset
still leaves it off. The check is against the global file regardless of which fleet.json (project
or global) is currently in effect, and is silent when no global entry exists for that worker.
When ~/.commandcode/auth.json already holds a Command Code CLI key but CMD_API_KEY (the
Command Code Provider API worker + judge backend) is unset, cyberine setup asks once on a TTY
whether to reuse that key for the Provider API; a yes writes CMD_API_KEY into the global
~/.cyberine/.env (mode 600) through the same writer cyberine auth login uses, and the key
itself is never printed. A non-TTY run prints a one-line hint instead of asking. Declining just
skips the write for that run — re-run cyberine setup (or cyberine auth login commandcode) to
be asked again, or set CMD_API_KEY by hand. Known limitation: the write lands in the env file
only — like every other credential cyberine setup writes this run, it does not update the
current process's own config snapshot, so the reused key takes effect starting with the next
cyberine command, not immediately.
Plugin CLI cheatsheet — plugin/references/cli-cheatsheet.md
A Claude Code plugin skill cannot always shell out to cyberine guide before it needs the answer (a skill's own description budget is paid whether or not it ever runs a command), so the same...
Project-level setup — cyberine init
cyberine init is the per-repo counterpart to cyberine setup. It detects which providers/CLIs are usable on the current machine, suggests a default fleet and mode, and writes...