documentation
05 settings

Settings overview

Settings is where the operator tunes the instance. A grid of grouped panels covers AI models, providers, model routing, budget, agent behavior, council reviews, security, named secrets, data & storage, networking, and notifications. This page is the index — the shortest path to the knob you need.

What this page is for

The settings hub used to be a single 1300-line tabbed page called Config. It’s now a set of focused sub-pages under /settings, each scoped to one operator concern, each with its own form and its own save button. Changes on any sub-page take effect immediately — no restart required, because Exolvra reads configuration through live-reloading options.

Opening /settings shows a grid of grouped panels — Models & providers, Agents, Budget & routing, Council, Security, Notifications, Data, Network, and Automation — and each row inside a panel carries a live summary of its current state (“$10/day”, “3 configured · Anthropic, OpenAI”, “Enabled · Resend”, etc.) so you can see the shape of your configuration at a glance before drilling in.

The documented sub-pages

These are the sub-pages with their own reference page in this guide. The dashboard exposes a few more rows (model routing, image generation, sandbox runtimes, council policy, storage backend, HTTP fetching, scripting) that are documented inline on the hub.

Sub-pageWhat it controlsRead this before you touch it
AI ModelsDefault model, temperature, governance allowlist, anonymous fallbackConcepts → Tools, skills & MCP
ProvidersAPI keys for LLM, search, and embedding providersInstallation
BudgetDaily/monthly limits, smart routing, alerts, soft/hard thresholdsBudget dashboard
AgentsBehavior limits, auto-dispatch strategy, compaction, learning systemConcepts → Agents
SecuritySandboxing, skill signing, bot API restrictions, Composio governanceSecurity & cloud mode
Named secretsEncrypted credentials agents reference as {{secret:NAME}}Security & cloud mode
Data & storageFile quotas, versioning, session retention, blocked extensions
NotificationsEmail delivery, daily digest, provider credentialsAdmin overview

Settings vs. admin

The split is deliberate. Admin is identity and governance — who can use the instance, what they can do, what’s waiting for review. Settings is behavior and cost — how the instance runs, how much it spends, which models it uses. Both are admin-only (Members can’t open either section), but they’re separated because the concerns are different and the read-frequency is different: admins open admin pages weekly to handle approvals and audits; they open settings pages rarely, when something needs tuning.

The live summary lines

Each row on /settings shows a short summary of its current state:

  • AI Models shows the default model (e.g., claude-sonnet-4-6)
  • Providers shows how many are configured and their names
  • Model routing shows smart vs. default
  • Budget shows $X/day and whether smart routing is on
  • Council shows the review policy (disabled, unrestricted, or allowlist)
  • Agents shows the dispatch strategy
  • Security shows active flags (DM sandbox, skill signing)
  • Named secrets is reachable under the Security panel
  • Data & storage shows the storage cap and retention window
  • Notifications shows email enabled/disabled and the provider

If the summary reads “No providers configured” or “Disabled” on something you thought was on, that’s the signal to open the sub-page and check.

Order of operations on a fresh install

After a fresh install, work through settings in this order:

  1. Providers — paste at least one LLM API key so agents can run
  2. AI Models — pick the default model (the UI suggests one from the providers you configured)
  3. Budget — set daily and monthly caps so a mistake can’t burn through your billing
  4. Security — decide on cloud mode and skill signing; both default to off in a personal install and should be reconsidered for multi-tenant
  5. Notifications (optional) — wire up email if you want digests or alerts
  6. Agents, Data & storage — leave at defaults unless you have a specific reason

Most of the sub-pages are set-and-forget once you’re past the install checklist.

What’s not here

A handful of runtime knobs still live elsewhere by design:

The rule of thumb: if it affects what agents can do at all, it’s in Admin; if it affects how the instance behaves, it’s in Settings.

Where to go next

  • Providers — start here on a fresh install
  • Budget — set limits before running a real workload
  • Admin overview — the other half of the operator surface