API configurations

An API configuration combines model selection, a Lumoswitch Runtime routing policy, one or more client-facing model names, and Virtual Key limits into one callable unit. Each configuration has one current access key; replacement rotation can keep the previous key active for a short grace period.

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
  ├─ Fixed, failover, auto, least-busy, or lowest-latency routing
  ├─ Candidate model resources
  ├─ Client-facing model mappings and enabled client formats
  └─ 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

Only healthy, routable resources should enter a production candidate pool.

Auto routing uses Lumoswitch Runtime auto_router/complexity_router with session affinity. Least-busy and lowest-latency routing are written to the current access key as router_settings.routing_strategy; switching back to fixed, failover, or auto routing clears the prior key-level strategy.

3. Downstream output

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.
• Whole configuration: the name uses the current routing mode and every candidate.
• Specific candidate: the name maps directly to one candidate resource and bypasses configuration-level failover.

The editor creates one name targeting the whole configuration by default. Add mappings to provide aliases for different clients or expose one candidate explicitly. Update every client before deleting, renaming, or retargeting an existing name.

4. Access-key limits

Optionally set requests per minute and allowed models. 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 both the configuration and its key.

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