Configuration examples

Replace each example candidate model with a healthy, routable resource from your console; choose client-facing model names independently. Saving synchronously updates every module's Lumoswitch Runtime routing group and the same Virtual Key.

Fixed: testing and consistency

Name: support-test
Mode: Fixed
Model: Qwen / qwen-plus
Client-facing model name: support-test

Lumoswitch Runtime sends every request to one model and returns its upstream error directly. Use this for evaluation, prompt testing, or version-pinned behavior.

Failover: production availability

Name: support-prod
Mode: Failover
Candidates: Qwen / qwen-plus -> DeepSeek / deepseek-chat -> OpenAI / gpt-4o-mini
Client-facing model name: support-prod

Candidate order is priority, not round robin. Lumoswitch Runtime advances to the next deployment when the current candidate fails. Verify request shape, tools, streaming, and output quality against every fallback before launch.

Auto routing: complexity-based model selection

Name: assistant-auto
Mode: Auto routing
Candidates: lightweight model -> general model -> reasoning model
Client-facing model name: assistant

Lumoswitch deterministically maps the ordered candidates onto Lumoswitch Runtime's SIMPLE, MEDIUM, COMPLEX, and REASONING tiers. Two or three candidates are valid and adjacent tiers reuse a model. Order by capability from lightest to strongest, not by failover priority.

Least busy: concurrent throughput

Name: batch-throughput
Mode: Least busy
Candidates: two or more interchangeable model resources

Lumoswitch Runtime selects the candidate with the fewest active requests. Candidates should have compatible interfaces and quality because list order is not priority.

Lowest latency: interactive response

Name: chat-low-latency
Mode: Lowest latency
Candidates: two or more interchangeable model resources

Lumoswitch Runtime selects from observed response latency. Warm a new configuration with realistic non-production requests, then monitor latency across request types, regions, and streaming modes.

Multiple client-facing model mappings

Configuration: support-prod
Client-facing model name: support-prod -> Production failover (whole module)
Client-facing model name: support-primary -> Qwen / qwen-plus (direct candidate)

One configuration can expose multiple model names. Each name selects a routing module and then either the whole module or a specific candidate, independently from the module currently open in the editor. A whole-module target uses the complete routing policy; a direct candidate bypasses routing for testing or explicit selection.

Multiple strategies in one configuration

Configuration: mixed-production
Module 1: support -> a -> b -> c (failover)
Module 2: batch -> d / e / f (least busy)

Clients share one Access Key and select a routing module through the model name. The modules compile and select candidates independently; separate configurations are not required.

Separate test and production

Create distinct configurations and Access Keys for each environment. After changing candidates or client-facing model mappings, wait for the configuration to report ready and send a minimal request to the Lumoswitch inference endpoint immediately.