Auto detect providers #5147
Closed
Auto detect providers #5147
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collaborator
DOsinga
commented
Oct 12, 2025
DOsinga
commented
Collaborator
Author
|
@spencrmartin - can you use this as the basis for the onboarding? I added the UI in a haphazardly way |
Collaborator
Author
spencrmartin
added a commit
that referenced
this pull request
Oct 30, 2025
- Replace format-based detection with parallel testing approach - Test all providers simultaneously using tokio::spawn for better accuracy - Simplify API response (404 for no match instead of structured errors) - Remove complex Ollama rejection logic - let parallel testing handle it - Should properly detect Anthropic, OpenAI, Google, Groq, xAI, and Ollama - Maintains existing Quick Setup UI with improved backend detection This integrates the robust parallel testing approach from PR #5147 into our Quick Setup onboarding flow for better API key detection.
spencrmartin
added a commit
that referenced
this pull request
Oct 30, 2025
- Add detect_cloud_provider_from_api_key() function that excludes Ollama - Add /config/detect-cloud-provider endpoint for Quick Setup use - Update ApiKeyTester to use cloud-only detection endpoint - Remove frontend Ollama rejection since backend won't return it - Ensures Quick Setup only works with cloud API providers - Maintains full detection (including Ollama) for other use cases This prevents unwanted Ollama fallbacks in Quick Setup while preserving the parallel testing approach from PR #5147 for better accuracy.
spencrmartin
added a commit
that referenced
this pull request
Oct 30, 2025
The pure parallel approach from PR #5147 was testing Anthropic keys against OpenAI API, causing incorrect rejections. This hybrid approach: 1. Detects key format first (sk-ant- → anthropic) 2. Tests the likely provider first with the key 3. Falls back to parallel testing if format detection fails 4. Includes OpenRouter support (sk-or- format) This should correctly route sk-ant- keys to Anthropic API for proper validation while maintaining the robustness of parallel testing for unknown formats. Benefits: - Anthropic keys test against Anthropic API (not OpenAI) - Faster detection (test likely provider first) - Robust fallback (parallel testing if needed) - Supports more providers (OpenRouter)
spencrmartin
added a commit
that referenced
this pull request
Oct 30, 2025
- Enhanced frontend format detection for all major providers (Anthropic, OpenRouter, OpenAI, Google, Groq, xAI) - Added smart workarounds for backend parallel testing issues - Prevent unwanted redirects during API key testing by maintaining userInActiveSetup state - Reject Ollama fallback in Quick Setup to ensure cloud-only provider detection - Configure providers directly when backend detection fails but format is recognized - Use correct model names: claude-3-haiku-20240307 for Anthropic, anthropic/claude-3-haiku for OpenRouter - Add input validation to prevent console log injection issues - Provide detailed error messages and suggestions for failed key validation - Integrate parallel testing approach from PR #5147 with frontend filtering Fixes the core issue where users entering incorrect API keys would be redirected away from setup screen, now they stay on setup with clear error feedback.
Contributor
|
This pull request has been automatically marked as stale because it has not had recent activity for 23 days. What happens next?
Thank you for your contribution! 🚀 |
Collaborator
|
Seems interesting and nice for making it more "works out of the box" Do we still want to do this one? |
Collaborator
Author
|
closing, assuming @spencrmartin will integrate this |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.