On this page

Configuration and provider reference

Purpose: locate the setting that owns a behaviour, without treating a file edit or saved field as proof of active state. Use the human Settings interface where available. This is a curated operational reference, not a claim that every JSON field or plugin-specific setting is documented here.

Provider selection

Owner / key Meaning in the inspected source
llm.provider Selects a provider-registry entry. Blank uses default selection; the UI describes a default-flagged entry.
llm.model Explicit model selection; when blank, resolution uses that entry's default_model. No model after resolution is an error.
Provider name, url, api_type Entry identity, endpoint and protocol. Endpoint is url in the registry, not a new endpoint field inside llm.
Provider api_key, api_key_env Stored credential or environment-variable reference. Both are sensitive configuration, even if the UI masks the value.
Provider context_length, max_output_tokens Context window and output allocation used by host budgeting. Zero may trigger metadata/default resolution, not unlimited capacity.
Provider reasoning_effort, thinking_budget, thinking_mode Provider/model-dependent reasoning controls; they are not universal capability switches.
llm.timeout_seconds, probe_timeout_seconds Request and substrate-check timeout configuration. Do not infer effective values from a zero in the shipped template.

Credential resolution checks an explicitly supplied value, entry's stored key, then its named key environment variable. If an entry names an environment variable that is empty, the inspected resolver returns that empty value rather than silently borrowing another provider's credential. Additional block/vendor environment fallbacks exist only after those entry-specific cases and include ownership checks. See the pinned resolver for the exact order; do not diagnose authentication by exposing secrets.

Settings → Substrate selects the entry/model and reports resolved and active state. Settings → Providers edits the provider facts. A substrate change involves a real inference check before application; plan its endpoint, disclosure and cost first. Models and providers develops the distinction.

Configuration areas and their companion guides

Area Inspect here Companion / caution
Identity paths/format identity configuration and host database state Storage; do not hand-edit records as a repair
Dashboard dashboard host, port, authentication, TLS/origin and related settings A loopback URL is not a local-only processing guarantee; remote serving needs a verified security procedure
Speech speech.stt, speech.tts, speaker/mode settings Voice; selected engines can have external data flow
Built-in tools tools.cwd, disabled, extra_roots, local_hosts, timeouts Permissions; broader reach is consequential
Plugins plugins autoload, trust/catalogue settings, grants, auth profiles, resources/settings Plugin boundary; installed does not mean all effects are granted
Prompt and agency prompt, agency context/work limits Memory/work; a limit is not a completed-work receipt
Projects projects.root Ongoing work; verify active project and evidence
Updates, maintenance, logs updates, maintenance, logs Operations; retained counts do not prove a restore was verified
Platform/contact services genesis, witness_server, contacts and other service settings Privacy; inspect actual destinations before disclosure

The shipped JSON includes updates.automatic: true and maintenance enabled with backup_keep: 8. These are template facts, not a readback of your effective configuration or a guarantee of eight usable backups. Runtime policy and retention can differ.

For a human-readable inventory beyond this provider-focused table, see configuration areas. For recognized program commands and flags, see command-line reference.

Schema and change discipline

The pinned configuration types and provider entry schema are the complete implementation references for fields outside this curated table. The shipped template is an example/default input, not a complete effective-config dump. Defaults and migrations are also code-defined; do not treat omitted or zero values uniformly.

Before a consequential change: confirm the identity/build, preserve a supported verified backup, change the smallest relevant setting, and inspect success/error plus active readback. A host rejection is evidence that the requested transition did not complete as requested; investigate its phase instead of editing unrelated state. This is change discipline, not a tested configuration-recovery recipe.

Never paste configuration files wholesale into Chat or a public issue. Masking the API-key field does not sanitize URLs, tokens, contacts, paths or plugin profiles elsewhere in a file.

Implementation evidence

Back to section overview · Documentation home