BYOK providers should discover and support actual model lists from the configured key

[ThePlenkov]

Summary

Kilo BYOK providers should read the actual model list from the configured key instead of relying on a hardcoded catalog. Today, many providers expose a per-key, per-account, or per-tenant set of models, and those lists can change over time. A static list creates noise, hides valid models, and prevents valid custom router names or provider-defined aliases from being used.

Problem

When using BYOK providers such as OpenRouter (and similar providers), the current behavior is too rigid:

• Kilo may show a large hardcoded list of models even when the active key only supports a small subset.
• Users cannot see or select models that are valid for their key but not included in the static catalog.
• Providers that support custom routing logic or aliases (for example, router names like orcarouter/code-review, orcarouter/auto, or user-defined routes) are blocked by the static model list.
• This causes unnecessary noise in the UI and makes provider-native custom routing impossible to use.

Proposed solution

Kilo should fetch the actual list of models from the configured provider using the provider key, and use that as the source of truth for available models. It should also support custom provider-defined aliases or route names when the provider exposes them.

The system should prefer dynamic discovery and allow additional filtering or aliasing when needed, instead of assuming a fixed list is always correct.

Use cases

1. Reduce noise for keys that expose only a small subset of models
   • A user with a key that only allows a few models should not see hundreds of irrelevant entries.
2. Support custom provider routes
   • A user should be able to use names such as orcarouter/code-review or orcarouter/auto when the provider exposes them.
3. Support dynamic provider-specific model catalogs
   • Model availability may vary by account, API key, or provider configuration.
4. Support BYOK providers beyond hardcoded defaults
   • A provider's available models should be discoverable from the provider instead of encoded into Kilo.

Acceptance criteria

• BYOK providers read and display the actual model list from the active key/account when the provider API exposes it.
• Generic or custom route names provided by the provider are accepted without requiring a Kilo hardcoded entry.
• The UI reduces noise by surfaces only the models actually available for the configured key.
• Kilo still has a safe fallback when provider metadata is unavailable or partially supported.

Notes

This request is especially relevant for ORCA/OpenRouter-style routing use cases where custom route names are first-class and not limited to a predeclared set.

Relevant references

• BYOK providers / provider configuration in Kilo
• Model catalog / provider catalog logic
• OpenRouter-style router aliases and routing metadata