Skip to main content

​
Runtime configuration

Kheish exposes live runtime controls through the daemon CLI and HTTP API.

​
What can change live

Without restarting the daemon, you can change:
  • the daemon default route
  • the learning automation policy
  • the permission mode
  • the recovered run-memory policy
  • tool runtime limits
  • the system prompt settings
  • the daemon-wide hook configuration
  • the debug capture level

​
Common commands

./target/debug/kheish-daemon runtime get
./target/debug/kheish-daemon runtime set-model openai/gpt-5.4
./target/debug/kheish-daemon runtime learning-policy get
./target/debug/kheish-daemon runtime tool-limits get
./target/debug/kheish-daemon runtime tool-limits set --file tool-limits.json
./target/debug/kheish-daemon runtime set-permission-mode accept-edits
./target/debug/kheish-daemon runtime set-debug-level redacted
./target/debug/kheish-daemon runtime set-system-prompt --mode append "Prefer direct execution when safe."
./target/debug/kheish-daemon runtime hooks get
./target/debug/kheish-daemon runtime revisions
./target/debug/kheish-daemon runtime rollback --target-revision 3
runtime set-model accepts either a bare model name or a route-aware selector in the form <route_id>/<model>. The CLI normalizes that selector before calling the HTTP API. runtime get includes config.revision, config.updated_at_ms, config.persisted, config.history_len, config.history_limit, and the state-root path of runtime-config.json.

​
Durable revisions and rollback

Runtime mutations for the daemon default route/model, permission mode, learning automation policy, recovered run-memory policy, tool runtime limits, system prompt, hooks, and debug level are serialized through one durable runtime-config transaction. Successful mutations append a new revision to runtime-config.json; daemon restart restores the last revision before accepting work. Mutation requests can include expected_revision. When supplied, the daemon rejects stale writers with 409 and runtime/runtime_revision_conflict. Runtime mutations also gate route pinning and runtime reads while the commit phase applies and persists the new revision. A run either pins the previous durable route or the next durable route; it should not observe a partially applied runtime mutation. Rollback creates a new revision from an older snapshot: 
./target/debug/kheish-daemon runtime revisions
./target/debug/kheish-daemon runtime rollback --target-revision 7 --expected-revision 12
The rollback does not delete history. It appends a new rollback revision that records the restored target revision. The daemon retains at most config.history_limit historical revisions plus the current revision. Older historical revisions are pruned, so only revisions still returned by runtime revisions can be rollback targets. Runtime summary surfaces redact hook executor bodies, including historical hook snapshots in runtime revisions. Use runtime hooks get for the current raw hook settings when you need to audit or edit hook commands.

​
Tool runtime limits

Tool limits bound the wrapper around every tool call:
  • JSON input bytes per call
  • JSON output bytes per call
  • full result-envelope bytes per call, including context_updates and hook contexts
  • timeout per call
  • parallel calls per batch
  • calls per tool-use turn
  • cumulative output and full-envelope bytes per tool-use turn
  • maximum sandbox profile allowed by the runtime
The limits are replaced as one object: 
./target/debug/kheish-daemon runtime tool-limits get
./target/debug/kheish-daemon runtime tool-limits set --file tool-limits.json --expected-revision 12
./target/debug/kheish-daemon runtime tool-limits set --reset
The daemon validates every numeric limit as greater than zero. Changes affect future tool batches; an already executing batch keeps the limits it started with.

​
Learning automation policy

The daemon-owned learning worker is configured through runtime policy:
  • ./target/debug/kheish-daemon runtime learning-policy get
  • ./target/debug/kheish-daemon runtime learning-policy set --file learning-policy.json
That policy controls:
  • whether the daemon captures run_summary candidates automatically
  • whether the daemon captures semantic fact / preference / decision candidates from completed runs
  • whether candidates stay manual, run in shadow, or can publish automatically
  • which candidates match manual_review, reject, publish_provisional, or publish_active
  • whether API-origin candidates may auto-publish with the active tier
  • which named rules are temporarily quarantined
  • whether the model-backed judge is enabled, and which optional route override it uses
Important operator rules:
  • the daemon replaces the full learning policy on set
  • send mode explicitly when mutating policy
  • use --expected-revision when automating policy changes
  • publish_active is still gated by daemon-owned verification
  • automatically published learnings are only prompt-visible after verification
  • the judge is bounded by the deterministic policy envelope; it does not write directly to the learning store
Read Runtime API and Learnings API for the exact wire shape and rule semantics.

​
Operational semantics

These settings are daemon-wide. They affect future execution on that daemon, but they do not retroactively change the pinned route, model, debug capture level, or tool-limit snapshot of an already active tool batch. On a mixed-provider daemon, runtime set-model should be read as changing the daemon fallback route rather than forcing every session onto one provider immediately. After any runtime mutation, verify the current state with runtime get. Treat live reconfiguration as an operational change with production impact, especially when permissions, hooks, or debug capture are involved.