Settings

Settings is where the deployment is configured — the root of the cascade that organizations and departments inherit from and narrow. It is a tabbed page, and edits are held as a draft until you save, so a half-finished change is never partly applied.

Tab	What it holds
Policy	Rate limits, caching, default routing strategy
Providers	Provider credentials — the only place they are set
Access	Allowed providers and models, model aliases, hierarchy labels
Logging	Request logging, including body capture and retention
Sign-in	The deployment’s own SSO configuration
Deployment	Deployment identity, plan, status, licence tier

The Policy tab uses the same editor that organization and department pages use, which is what makes the cascade legible: the fields you set here are the fields they override, shown the same way.

The Sign-in tab configures SSO for the deployment’s own sign-in, reached under the reserved slug system. Each organization configures its own identity provider on the organization itself, and does not fall back to this one — see Organizations & Departments.

Hierarchy labels

Under Access, rename the tiers shown throughout the admin. By default the two middle tiers are called Organizations and Departments; relabel them to match your terminology (e.g. “Teams” / “Projects”).

Model aliases

Also under Access. Map a name your callers already use to a model the gateway knows — gpt4 to gpt-4o, for example — so client code does not have to change when the underlying model does.

Rate Limiting

Global rate limits protect the gateway and upstream providers from excessive traffic. Three limits can be configured (set a value to 0 for unlimited):

Setting	Description
Requests per Minute	Maximum requests per minute (maxRequestsPerMinute).
Requests per Day	Maximum requests per day (maxRequestsPerDay).
Tokens per Day	Maximum total tokens processed per day (maxTokensPerDay).

These are system-wide defaults. Per-API-key rate limits (configured on the API Keys page) override these for their respective scopes.

Caching

The gateway includes a semantic cache that stores and reuses responses for similar prompts, reducing latency and cost.

Setting	Description
Enabled	Toggle semantic caching on or off (cachingEnabled).
TTL (seconds)	How long cached responses remain valid (cacheTTLSeconds).

The cache similarity threshold is a deployment-time setting (CACHE_SIMILARITY_THRESHOLD, default 0.96), not a field on this page — see Environment Variables.

Default Routing Strategy

Select the system-wide default routing strategy. This applies to any request that does not match a specific routing config on the Routing page. All ten selectable strategies are available:

• Priority
• Round Robin
• Weighted
• Least Latency
• Least Cost
• Free Tier First
• Task Optimized
• Cost Optimized
• Failover
• Random

review-panel is the eleventh strategy and is deliberately not offered here. It calls every route at the top priority level and then a synthesiser, so it is chosen per routing rule where that cost is intended — never as the default for everything.

See the Routing Configuration page for detailed descriptions of each strategy.

Allowed Providers

Under Settings → Access, tick which providers this deployment may route to. Unchecked providers are excluded from routing.

The list is built from the providers you have actually configured, not from a fixed set — so it reflects your catalogue rather than the 49 adapters the gateway ships with. Selecting none means no restriction: every configured provider is allowed.

Organizations and departments narrow this further with their own allow-lists; they cannot widen it beyond what the deployment permits.

Allowed Models

Restrict which model IDs can be used through the gateway. Enter one model ID per line (e.g. gpt-4o, claude-sonnet-4-6). Leave the field empty to allow all models.

This acts as an allowlist — only models listed here will be routable. Combined with per-provider model registrations, this gives you two layers of control over which models are accessible.

SSO Configuration

Single Sign-On can be enabled and configured directly from the Settings page. Toggle Enable Single Sign-On and select a provider type — SAML 2.0 or OpenID Connect (OIDC).

OIDC (OpenID Connect)

Field	Description
Issuer URL	The OIDC discovery endpoint (e.g. https://accounts.google.com).
Client ID	OAuth client identifier.
Client Secret	OAuth client secret (leave blank to keep the current value).
Scopes	Space-separated OIDC scopes (default: openid email profile).

SAML 2.0

Field	Description
IdP SSO URL	The identity provider’s single sign-on entry point.
IdP Entity ID	The issuer identifier from your identity provider.
IdP Signing Certificate	The X.509 certificate in PEM format used to verify SAML assertions.

SIEM Integration

SIEM export is deployment configuration, not a stored setting. Audit entries are streamed by the worker process, which reads its destination at startup, so the Settings card shows the configuration read-only. It appears only when the licence includes siem-export.

Set it on the worker:

Variable	Value	Example
SIEM_TYPE	splunk, elk or webhook	splunk
SIEM_URL	Destination endpoint	https://splunk:8088/services/collector
SIEM_TOKEN	Authentication credential	—
SIEM_BATCH_SIZE	Events per batch	100

The Send test event control posts a single event to an endpoint you supply, to check it would be accepted. It saves nothing and does not change where audit entries are sent.

Why it is read-only

An earlier version rendered editable fields here, never included them in the save request, and then showed a success message — so an operator could believe they had configured an export that did not exist. Showing the real, immutable source is the correction.

Saving Changes

All settings on this page are saved atomically via PUT /api/admin/settings. The Save Settings button is disabled while a save is in progress to prevent duplicate submissions.