Spec OpenAI-compatible BYOK endpoints#9620
Spec OpenAI-compatible BYOK endpoints#9620kenrogers wants to merge 1 commit intowarpdotdev:masterfrom
Conversation
|
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have the users @kenrogers on file. In order for us to review and merge your code, each contributor must visit https://cla.warp.dev to read and agree to our CLA. Once you have done so, please comment |
|
@cla-bot check |
|
The cla-bot has been summoned, and re-checked this pull request! |
|
I'm starting a first review of this spec-only pull request. You can view the conversation on Warp. I completed the review and posted feedback on this pull request. Comment Powered by Oz |
![oz-for-oss[bot]](https://avatars.githubusercontent.com/in/3450139?s=60&v=4){kind=small}
There was a problem hiding this comment.
Overview
This PR adds product and tech specs for a generic OpenAI-compatible BYOK endpoint flow, including Settings > AI configuration, synthetic model picker entries, and request-time endpoint metadata.
Concerns
- The specs promise local OpenAI-compatible servers while preserving the current backend-routed BYOK architecture, which makes localhost/private endpoints ambiguous or unreachable.
- Backend routing to arbitrary user-provided URLs needs explicit SSRF/egress controls, redirect/DNS rebinding handling, timeouts, and secret redaction rules.
- The tech spec is ambiguous about clearing stored endpoint config when BYOK becomes disabled, which conflicts with the product spec's non-destructive gating behavior.
- The backend request contract remains unresolved enough to block implementation handoff.
Verdict
Found: 2 critical, 2 important, 0 suggestions
Request changes
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
|
|
||
| ## Summary | ||
|
|
||
| Users should be able to configure a custom OpenAI-compatible model endpoint for Warp Agent by entering a provider label, base URL, API key, and model ID. This gives users a narrow, predictable way to use OpenRouter, LiteLLM, internal OpenAI-compatible gateways, and local OpenAI-compatible servers without requiring Warp to add a bespoke provider integration for each one. |
There was a problem hiding this comment.
🚨 [CRITICAL] This promises local OpenAI-compatible servers, but the tech flow sends endpoint metadata to Warp's backend; localhost would resolve from the backend, not the user's machine. Specify client-side/local routing for local endpoints or remove local servers from the first-version scope.
|
|
||
| Validation: | ||
|
|
||
| - Parse base URL with `url::Url`. |
There was a problem hiding this comment.
🚨 [CRITICAL] Syntax-only URL validation is not enough for a backend-routed arbitrary endpoint. The spec needs server-side egress rules for private/link-local/metadata IPs, redirects, DNS rebinding, timeouts, and redaction of the URL/API key from logs before implementation.
|
|
||
| - On blur or Enter, persist the full config via `ApiKeyManager`. | ||
| - Empty base URL, API key, or model ID keeps the config incomplete. | ||
| - If BYOK is disabled for the workspace, clear/disable the endpoint editors using the same `UserWorkspacesEvent::TeamsChanged` handling as the fixed provider key fields. |
There was a problem hiding this comment.
clear/disable conflicts with the product spec's non-destructive gating. Specify that BYOK-disabled workspaces preserve the stored custom endpoint but disable editing/selection unless the user explicitly deletes it.
| ## Open questions | ||
|
|
||
| 1. Should the first implementation support exactly one custom endpoint, or should the persistence shape support a list immediately while the UI initially exposes one? | ||
| 2. Should custom endpoint metadata live in the existing `api_keys` request payload or a distinct `custom_model_endpoint` request field? |
There was a problem hiding this comment.
ApiKeys, including versioning/backward compatibility with the backend.
captainsafia
added
the
external-contributor
Warp Dev Github Integration
2 participants
Description
Adds a draft product spec and tech spec for issue #4687: a generic OpenAI-compatible BYOK endpoint flow.
The spec frames OpenRouter as the proof case, but keeps the proposed implementation generic: provider label, base URL, API key, and model ID. That avoids a one-off provider button while still making OpenRouter, LiteLLM/internal proxies, and local OpenAI-compatible gateways possible through the same surface.
It also calls out how this relates to #9253: OpenRouter-specific BYOK is useful partial progress, but the broader issue still needs custom endpoint/model metadata instead of relying only on server-approved model choices.
Linked Issue
Fixes #4687 after approval and implementation.
ready-to-specorready-to-implement.Note: #4687 is currently
enhancement/triagedbut notready-to-spec. I am opening this as a draft spec PR to give maintainers a concrete scope to accept, edit, or reject before any code implementation.Screenshots / Videos
Not applicable; spec-only PR.
Testing
git diff --cached --checkgit show --check --stat --oneline HEADNo runtime tests were run because this PR only adds Markdown specs and does not change application code.