Credential pools
An upstream can store several provider API keys. A credential pool manages keys that share a provider and base URL, and makes them available by priority.
When to use a pool
- Separate provider accounts supply capacity.
- A primary and fallback key need explicit priority.
- A key should be restricted to selected models.
- Old and new credentials must overlap during rotation.
Use separate upstreams when credentials require different regions, base URLs, or security boundaries.
Fields and selection
| Field | Meaning |
|---|---|
| Name | Identifies the account, environment, or purpose |
| Priority | Controls preferred selection order |
| Enabled | Excludes a credential when disabled |
| Model scope | Restricts which models can use the key |
| Recent failure | Indicates authentication, quota, or connectivity problems |
Full provider keys are not shown again. Enabled credentials that allow the target model are compiled into Lumoswitch Runtime deployment tiers. Lower numeric priorities are tried first and different priorities form ordered fallback tiers. Credentials at the same priority are selected by the current Lumoswitch Runtime policy and must not be assumed to use strict round robin.
Discovery limitation
Current model discovery primarily uses the upstream's main credential. Pool credentials can participate in calls but are not guaranteed to receive independent full discovery. Keep the main credential able to list target models and test fallback credentials with an actual chat request.
Safe rotation
- Add and enable the new credential.
- Test connectivity and the target model.
- Move the new credential to the preferred priority.
- Confirm client calls still succeed.
- Disable and later delete the old credential.