Problem
During onboarding, the Choose your LLM provider step currently shows only a small curated subset of Raven's supported providers, followed by:
Other (OpenAI-compatible endpoint)
Raven's provider registry supports more providers than the onboarding picker displays. When a provider is missing from the visible list, less-experienced users may assume that Raven does not support it. They are then forced into the generic OpenAI-compatible flow, where they need to know the correct base URL, model identifier, and other provider-specific details.
This creates unnecessary setup cost and makes the provider support already implemented in Raven difficult to discover.
Proposal
Make the onboarding provider picker display all providers supported for Raven's main chat model, instead of maintaining a small hard-coded subset.
Suggested behavior:
- Populate the picker from the provider registry, or add explicit registry metadata such as
show_in_onboarding and ordering/group information.
- Keep intentional ordering rules, such as OpenRouter at the top as the recommended gateway and highlighted open-source partners near the top.
- Let users navigate the complete list with the Up/Down arrow keys.
- When the list is taller than the terminal, scroll the visible viewport while keeping the current selection clear.
- Optionally support type-to-filter for long provider lists.
- Keep Other (OpenAI-compatible endpoint) as the final item for genuinely unsupported or custom endpoints.
- After the provider is selected and credentials are entered, continue using the existing provider-specific model discovery/selection flow.
Example structure:
Choose your LLM provider:
OpenRouter (recommended — one key, many models)
MiniMax (open-source partner)
OpenAI
Anthropic
Gemini
DeepSeek
...all other supported providers...
GitHub Copilot (OAuth)
Codex (OAuth)
─────────────────────────
Other (OpenAI-compatible endpoint)
↑/↓ Navigate · Enter Select
Acceptance criteria
- Every user-configurable provider supported for the main Raven agent can be discovered in the onboarding picker.
- Users can browse the complete list with Up/Down arrow keys, including in a small terminal window.
- The selected provider uses its existing registry metadata and provider-specific configuration flow.
Other (OpenAI-compatible endpoint) remains available and is always the final option.
- English and Chinese labels are supported.
- Tests ensure that eligible registry providers appear in onboarding and that
Other remains last.
Alternatives considered
Keep the current curated list and add documentation for the missing providers. This still requires users to leave onboarding and already know which provider names or endpoints to search for.
Area
Providers / CLI / TUI
Additional context
The current picker is defined separately from the full registry:
raven/cli/onboard_commands.py: _CURATED_PROVIDERS
raven/providers/registry.py: PROVIDERS
Using the registry as the source of truth would reduce the risk that provider support and onboarding visibility drift apart.
Related: #197 proposes highlighting MiniMax as an open-source partner near the top of the same picker.
Problem
During onboarding, the Choose your LLM provider step currently shows only a small curated subset of Raven's supported providers, followed by:
Raven's provider registry supports more providers than the onboarding picker displays. When a provider is missing from the visible list, less-experienced users may assume that Raven does not support it. They are then forced into the generic OpenAI-compatible flow, where they need to know the correct base URL, model identifier, and other provider-specific details.
This creates unnecessary setup cost and makes the provider support already implemented in Raven difficult to discover.
Proposal
Make the onboarding provider picker display all providers supported for Raven's main chat model, instead of maintaining a small hard-coded subset.
Suggested behavior:
show_in_onboardingand ordering/group information.Example structure:
Acceptance criteria
Other (OpenAI-compatible endpoint)remains available and is always the final option.Otherremains last.Alternatives considered
Keep the current curated list and add documentation for the missing providers. This still requires users to leave onboarding and already know which provider names or endpoints to search for.
Area
Providers / CLI / TUI
Additional context
The current picker is defined separately from the full registry:
raven/cli/onboard_commands.py:_CURATED_PROVIDERSraven/providers/registry.py:PROVIDERSUsing the registry as the source of truth would reduce the risk that provider support and onboarding visibility drift apart.
Related: #197 proposes highlighting MiniMax as an open-source partner near the top of the same picker.