Settings

Settings is the platform configuration surface at /admin/config (route admin_config_index, menu Platform → Settings). Opening it lands you on the first section you’re allowed to view.

​

Sections & fields

Settings are grouped into sections at /admin/config/{section} — for example General, Email / SMTP, Identity, and Widget. Sections come from the modules you have installed, so the list grows as you add modules. Each field shows its:

• Label and description,
• Current value, and
• A scope badge — Default, inherited, or overridden.

​

Scopes & inheritance

Values resolve along a chain: Global → Organization → Workspace. The most specific value wins — a workspace override beats an organization value, which beats the global default. A segmented control at the top switches which scope you’re editing.

​

Editing

​

Encrypted fields

Sensitive fields — SMTP passwords, API keys — are shown empty. Click Reveal to fetch the plaintext on demand (gated by the section’s edit permission). The secret is never embedded in the page.

​

Publicly readable fields

A few settings are meant to be read by the anonymous widget embed — the widget’s appearance values and its quick-question prompts. Those fields are served to visitors by the public read endpoint (GET /api/public/v1/config/{section}) and republished automatically every time you save. A field is exposed there only when the module that ships it declares public_readable: true in its configuration schema — there is no toggle in the UI, so saving a section never makes anything else public. Encrypted or sensitive fields can never be declared public; the platform rejects such a schema outright. See the Public read API.

​

API-readable fields

A separate, orthogonal allowlist serves authenticated integrations: a field a module declares api_readable: true can be read — never written — over the Configuration read API (REST with a personal access token, or the config.list / config.get MCP tools). The same rules apply as for public fields: there is no UI toggle, encrypted or sensitive fields can never be declared readable, and callers only see sections their role lets them view.

​

History

Each field keeps a timeline: who changed what, when, the before/after values, and the scope. Use Restore to roll a field back to an earlier value.

​

Feature flags

Flag fields add an Enabled toggle plus a rollout / audience target so you can ship a change to a subset before everyone. Managing flags needs the comerix.config.flags.manage permission.

​

Table fields (“rows”)

Some settings are dynamic tables you grow row by row — the rows field type. Each row carries one cell per declared column, and a column is either a free-text input or a single select. A select’s options are either a fixed inline list or a live list fetched when the page renders (for example, the current workspace’s flows). Selections are suggestions — neither list is enforced when you save. Use Add row to append a row and the row’s delete control to remove one; the whole table is stored as one value at the scope you’re editing. Two settings use this field type:

• LLM model pricing (below), and
• Quick Questions on the Widget — the one-tap prompts shown when a visitor opens the chat.

​

LLM model pricing & token cost

The AI / LLM section (/admin/config/llm) holds the Token pricing table the platform uses to estimate what each agent reply costs. Open it and edit the Model prices table — a rows field with three columns:

​

Built-in defaults

Pricing works before you configure anything: a built-in table covers common models so replies are costed out of the box. Each row you add overrides the default for that model id; a model you don’t list falls back to its built-in price, and a model that’s neither listed nor known is costed at zero. The shipped defaults (USD per 1,000 tokens, prompt / completion) are: A reported model id is matched exactly first, then by the longest known prefix — so a versioned id such as gpt-4o-2024-08-06 resolves to the gpt-4o row.

​

Scope inheritance

Like other settings, the price table resolves along Global → Organization → Workspace, and the most specific value wins. Set a baseline table at Global, then let an organization or workspace override it where its rates differ. See Scopes & inheritance.

​

Where the cost shows up

The estimate is computed per reply when an agent turn finishes, summing each node’s tokens priced by the model that produced them. That single figure then drives:

• the per-reply cost shown under each agent message in Transcripts (rendered as … tokens · $0.0000),
• the Token spend figure on the dashboard, and
• the cost_usd value inside the token_usage block returned to the chat widget API (also carried as cost_micros, micro-USD, so totals sum without rounding drift), and aggregated into the Analytics Hub’s token-spend report.

​

Permissions

You only see the sections you can view; each section gates read and write independently. Grant these per role on Users, roles & permissions.