Lumoswitch risk controls

All public inference traffic goes directly to Lumoswitch Runtime. Lumoswitch stores business configuration and synchronizes desired state through the Lumoswitch internal management API; request authentication, rate limits, blocking, and Guardrails are enforced by Lumoswitch Runtime in the realtime request path.

The Lumoswitch Runtime risk-controls page displays and edits options the runtime can actually enforce. Lumoswitch does not maintain a second set of content-risk thresholds. Settlement creates narrowly scoped local billing events when it detects positive usage for an unpriced meter. Marking a meter free replaces its existing rules with one unconditional zero-price rate. A hold is considered repaired only when the latest active price matches the triggering usage context.

Unpriced usage

A platform model stores only the billing meters an administrator explicitly configures; three token prices are no longer expanded into five stored prices. If an unconfigured image, audio, video, reasoning, cache-write, or other meter reports positive usage, the current request retains the usage and settles that line at zero. Lumoswitch then creates an UNPRICED_USAGE risk and billing hold that blocks future runtime access for the user. The request meter is an optional fixed surcharge: omitting it means no surcharge and does not trigger this risk.

The risk page shows the model, meter, quantity, user, Configuration, Access Key, and related request. An administrator can add a normal price or choose Make entire meter free to replace its rules with one unconditional zero-price rate and release the corresponding hold. Force-releasing an unresolved source requires evidence and approval from a different administrator.

Gateway controls

Administrators can manage:

• Per-model-deployment concurrency (general_settings.max_parallel_requests in Lumoswitch Runtime).
• Global concurrency for the Lumoswitch Runtime gateway.
• Maximum request and response sizes.
• Cancellation of upstream requests after a client disconnects.
• Rejection of client-supplied metadata tags.

An empty numeric field removes the database override and restores the active Lumoswitch Runtime configuration or default.

Configurations and Virtual Keys

Each Lumoswitch Configuration maps to a managed Lumoswitch Access Key. The console directly controls:

• blocked: block or restore the key.
• rpm_limit: requests per minute.
• tpm_limit: tokens per minute.
• model_rpm_limit and model_tpm_limit: per-model request and token limits.
• max_parallel_requests: per-key concurrency.
• models and allowed_routes: generated from the Configuration model and protocol settings.

Saving updates Lumoswitch desired state and immediately synchronizes Lumoswitch Runtime. Platform blocks such as account disablement and billing holds take precedence and cannot be cleared from this page. Team budgets continue to be derived from the Lumoswitch ledger and synchronized to Lumoswitch Runtime, so the console does not allow manual budgets that bypass the ledger.

Guardrails

The page reads the Guardrail providers and modes supported by the running Lumoswitch Runtime instance and lists Guardrails from both config.yaml and the Lumoswitch Runtime database.

Administrators can create database Guardrails with a provider, mode, default_on, description, and provider-specific JSON parameters. default_on=true makes Lumoswitch Runtime apply the Guardrail globally to applicable requests. The console can delete database Guardrails only; Guardrails declared in config.yaml must be changed through deployment configuration.

Current-version boundary

The page reads /health/license to show the active Lumoswitch Runtime license scope. The current Community deployment supports direct management of Virtual Key models, routes, aggregate and per-model RPM/TPM, concurrency and blocking; Team budgets and blocking; gateway hard limits; and global Guardrails.

The console does not create non-functional switches for Lumoswitch Runtime Enterprise-only capabilities, including assigning Guardrails to individual Keys or Teams, per-model budgets, and some advanced budget policies. If the deployment is upgraded to a version exposing those APIs, extend and verify the Admin Client contract before enabling the corresponding forms.

Billing safety remains separate from content risk

Idempotent Spend import, quarantine of usage that cannot be settled, insufficient balance, and billing holds remain mandatory Lumoswitch ledger safeguards. They can affect Lumoswitch Runtime through Team and Key synchronization. Lumoswitch does not run a general scheduled risk evaluator; local events are limited to explicit billing conditions such as unpriced usage.

For troubleshooting, check Configuration sync state, Virtual Key state, Team budget, Guardrails, and active billing holds. Never send full access keys, upstream API keys, verification codes, or passwords in logs, screenshots, chat, or support tickets.