API configurations

An API configuration combines one or more independent routing modules, client-facing model names, and Virtual Key limits into one callable unit. The product UI shows one current access key; the lower layer permits multiple keys during replacement rotation.

Platform models and connected models differ only by resource source. Once selected by an API configuration, they use the same candidates, routing, enabled client formats, and access-key logic. Platform models never receive a direct key that bypasses routing.

API configuration
  ├─ Name and enabled state
  ├─ Routing and models module 1
  │   ├─ Custom name, numbered from the routing mode by default
  │   ├─ Fixed, failover, auto, least-busy, or lowest-latency routing
  │   ├─ Candidate model resources
  ├─ Routing and models module 2 ...
  ├─ Inference endpoint and downstream models
  │   ├─ Enabled client formats
  │   └─ Downstream model ID -> routing module or specific candidate
  └─ Current access-key rate and model limits

Create a configuration

1. Basic information

Enter a unique name and choose its enabled state. Disabling a configuration blocks all of its active inference keys through configuration synchronization.

2. Routing and candidates

One configuration may contain multiple routing-and-model modules. Each module has its own editable name, mode, and candidates. Names are numbered from the mode by default, such as Fixed model1, Fixed model2, and Failover1, and can be replaced with business names. Only healthy, routable resources should enter a production candidate pool.

Auto routing uses Lumoswitch Runtime auto_router/complexity_router with explicit session affinity, which also implies a deployment pin in the reviewed LiteLLM version. Failover, least-busy, and lowest-latency modules compile to independent global Runtime routing groups, while each Access Key exposes only the Configuration's public model aliases.

3. Downstream output

The inference and downstream-model section is independent from the module editor. Set the client-facing model names used by clients and enable OpenAI-compatible, Anthropic Messages, and/or Gemini generateContent. Each format points directly to the Lumoswitch inference service.

• Client-facing model name: the value clients send in the model field. A configuration accepts up to 20 unique names.
• Routing module: each name can select any module without switching the module editor first.
• Whole module: the name uses the selected module's routing mode and every candidate.
• Specific candidate: the name maps directly to one candidate in the selected module and bypasses routing.

Each non-fixed module creates one whole-module name by default; a fixed module creates direct outputs for its candidates. A multi-model fixed module cannot be selected as a whole-module target, but any subset of its candidates may be published directly. Names must be unique across the configuration. Update every client before deleting, renaming, or retargeting an existing name.

4. Access-key limits

Optionally set requests per minute. The allowed model set is generated from every module's client-facing names. Production applications should have explicit capacity limits.

5. Save the key

Saving creates the configuration and its current access key.

The full key appears only in the completion dialog. If it is lost, rotate the key; plaintext cannot be recovered.

Edit safely

The existing key remains unchanged, while new routing, output, and limits affect later requests immediately.

1. Verify the health of every new candidate.
2. Keep at least one known fallback where availability matters.
3. Warm lowest-latency observations with non-production traffic before switching production.
4. Avoid changing, deleting, or retargeting a client-facing model name until clients are ready.
5. Send a minimal request immediately after saving.

Configuration presets

My, official, and community presets in the editor come from persisted Configuration Template data. A preview resolves requirements against the regional model catalog before applying; missing required models never downgrade silently. Personal presets support immutable new versions, publishing, favorites, forks, import, sanitized export, and archival.

Call the configuration

curl "https://api.lumoswitch.com/v1/chat/completions" \
  -H "Authorization: Bearer YOUR_LUMOSWITCH_ACCESS_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "YOUR_CLIENT_FACING_MODEL_NAME",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

Disable and delete

• Disable: preserves the configuration but blocks calls through its key.
• Delete: revokes the configuration and all associated keys.

Migrate every client to a replacement configuration and validate the new key before deleting the old one.