Production deployment

All three processes (llama-server, daemon, web UI) ship as systemd units in packaging/systemd/. Point EnvironmentFile= at a /etc/toki-recur/toki.env (chmod 600) with TOKI_AUTH_TOKEN set, that single token then gates both the daemon API and the web UI.

Systemd

sudo install -m 600 packaging/systemd/toki.env.example /etc/toki-recur/toki.env
# edit: TOKI_AUTH_TOKEN=<token>
sudo install -m 644 packaging/systemd/toki-recur.service packaging/systemd/toki-recur-web.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable --now toki-recur toki-recur-web

macOS uses a launchd LaunchDaemon instead; Windows wraps toki serve in NSSM or a scheduled task.

Web UI access + TLS

toki web --tls-cert /etc/toki-recur/tls/toki-recur.pem \
         --tls-key  /etc/toki-recur/tls/toki-recur.key

Cross-session cache persistence (disabled)

Prefix reuse is in-memory only: the engine routes similar prompts to the same llama-server slot and lets the slot's KV cache serve the shared prefix (cache_prompt=true). This is lossless, outputs are byte-identical to a no-cache run.

Disk persistence via ?action=save / ?action=restore was removed: restoring disk KV corrupted precision (benchmarks showed 88% substantive divergence from baseline outputs). The --slot-save-path flag and the .trkv sidecar layer (cache/blob.py) remain in the codebase but are dormant, the engine never calls cache_save / cache_load, and starting llama-server with or without --slot-save-path changes nothing about behavior.

Installers

install.sh/install.ps1 bootstrap the full stack themselves (own venv at /opt/toki-recur, package + llama-server + service unit), so they work standalone, they don't need the pipx install. CI executes both installers end-to-end on fresh runners and starts the installed daemon under systemd.

# Linux  -> systemd + logrotate   (macOS -> launchd LaunchDaemon)
sudo ./install.sh

Next: Development, repo layout, tests, license.