Studio: Add custom provider support [Frontend] #4902
Studio: Add custom provider support [Frontend] #4902rolandtannous merged 1 commit intounslothai:feature/chat-apifrom
Conversation
Imagineer99
requested review from
Manan17,
Shine1i and
rolandtannous
as code owners
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0980cf62c2
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if (!isCustomProvider && !apiKey.trim()) { | ||
| toast.error("API key is required."); | ||
| return; |
There was a problem hiding this comment.
This branch now lets custom providers bypass API-key validation (!isCustomProvider), but createOpenAIStreamAdapter still aborts any external request when no key is stored (if (isExternalRequest && !externalApiKey)). In practice, users can save a custom provider with an empty key (the UI even labels it optional) and then every chat request fails at send time, so keyless OpenAI-compatible endpoints are unusable despite being accepted in this form.
Useful? React with 👍 / 👎.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces support for "Custom" chat providers, enabling users to configure OpenAI-compatible endpoints with custom names, base URLs, and manual model IDs. The changes include updates to the provider logo component, the chat adapter for backend mapping, and the provider configuration dialog. Review feedback identifies a regression where the Base URL input was made exclusive to custom providers, which prevents standard providers from using local proxies or regional overrides. Additionally, the error handling for connection tests is noted as brittle because it relies on specific string matching for illegal header values, suggesting a more robust validation mechanism should be used instead.
| } else { | ||
| if ( | ||
| provider.providerType === CUSTOM_PROVIDER_TYPE && | ||
| result.message.includes("Illegal header value b'Bearer '") |
There was a problem hiding this comment.
Checking for the specific string Illegal header value b'Bearer ' is brittle as it relies on a specific error message format from the backend's HTTP library (likely Python's h11 or httpx). If the backend implementation or its dependencies change, this check will fail. It would be better to handle this via a specific error code or a more robust validation on the backend.
|
will merge and we can resolve bugs in the main PR |
2 participants
Adds custom provider frontend.
As discussed, backend implementation will be added separately.