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 billing incidents backed by immutable source evidence.

Unpriced usage

A platform model stores only the billing meters an administrator explicitly configures. A new price card shows uncached input, cache-read input, and output tokens by default; the other 21 meters can be added according to model capability. When a Reasoning Token price is not explicit, reasoning tokens inherit the ordinary output rate selected for the same request context. An explicit Reasoning Token price overrides that fallback, and an explicit zero intentionally makes reasoning free. Apart from the established cache-write and reasoning-token fallbacks, Lumoswitch does not send an implicit zero-price field to LiteLLM for any other unconfigured meter. If such a valid meter reports positive usage, the current request retains the complete usage and settles that line at zero while creating a model-scoped UNPRICED_USAGE incident. Embedding models use the ordinary input-token meter; image and OCR usage follow mutually exclusive billing branches to prevent double charging.

The risk page shows the model, meter, quantity, user, Configuration, Access Key, and related request. A new incident first blocks affected keys as a safety fence. Reconciliation then removes the restricted model from runtime authorization and routing: configurations with another healthy candidate recover as DEGRADED, while configurations with no healthy candidate remain RESTRICTED. An administrator can add a normal price or choose Make entire meter free to replace its rules with one unconditional zero-price rate. The price-publishing transaction validates every unresolved usage context for the incident. Full coverage releases the restriction and queues synchronization. Disabling the published model also retires its deployments, resolves the incident as taken offline, and rebuilds affected configurations without inventing a price. Partial coverage remains restricted; an unrepairable source requires an evidence-backed waiver approved by a different administrator.

Unified action queues

One billing-incident queue covers SOURCE_CONFLICT, INVALID_SOURCE_PAYLOAD, USAGE_INTEGRITY, UNPRICED_USAGE, and terminal SETTLEMENT_FAILURE. Each incident has evidence, remediation history, and a minimally scoped runtime restriction. Refund manual review retains its separate payment semantics and requires an outcome, reason, and provider evidence.

Gateway controls

Administrators can manage:

• Per-model-deployment concurrency (general_settings.max_parallel_requests in Lumoswitch Runtime).
• Global concurrency for the Lumoswitch Runtime gateway.
• 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. Configuration lifecycle and runtimeEligibility are displayed separately; eligibility is READY, DEGRADED, FUNDING_REQUIRED, SYNCING, RESTRICTED, REFUND_PREPARING, or DISABLED. Team budgets remain derived from the Lumoswitch ledger, so the console cannot create manual budgets that bypass it.

A new user can configure and enable a Configuration and Access Key before funding the wallet. A Configuration containing paid platform models is FUNDING_REQUIRED at zero balance and requests fail closed, but it is not mislabeled as disabled or abusive. Funding or credit moves it through SYNCING to READY after Runtime confirms the budget. Pure BYOK/free configurations are not wallet constrained.

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 project is fixed to LiteLLM OSS. The page directly manages Virtual Key models, routes, aggregate and per-model RPM/TPM, concurrency and blocking; Team budgets and blocking; gateway concurrency and request controls; and global Guardrails. It neither probes nor presents commercial-license capabilities.

The console does not create non-functional switches for non-OSS capabilities, including assigning Guardrails to individual Keys or Teams, per-model budgets, and some advanced budget policies. Those fields are rejected consistently by types, validation, and the runtime request boundary.

Billing safety remains separate from content risk

Idempotent Spend import, quarantine of usage that cannot be settled, and minimally scoped runtime restrictions remain mandatory Lumoswitch ledger safeguards. A metered request can settle only after its Runtime amount matches the exact price and exchange-rate snapshot in effect for that request; missing-snapshot NOT_COMPARABLE records fail closed. Settlement errors retry first; only non-retryable errors or the 12-attempt/1,800-second terminal boundary create an incident. Fresh evidence automatically supersedes a pending waiver.

Avatar and community content safety remain focused review pages so their state machines do not get mixed with billing and runtime decisions. The risk page links directly to avatar review, community review, request logs, and user management.

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