feat: support custom Cohere reranker API URL - #498
Conversation
Adds an apiUrl option to CohereReranker, mirroring JinaReranker's existing apiUrl/JINA_API_URL pattern. Defaults to COHERE_API_URL (falling back to https://api.cohere.com/v2/rerank), letting callers point at a Cohere-compatible endpoint such as a self-hosted LiteLLM proxy. createReranker forwards a new cohereApiUrl field through.
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3b05e1a831
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| jinaApiKey?: string; | ||
| jinaApiUrl?: string; | ||
| cohereApiKey?: string; | ||
| cohereApiUrl?: string; |
There was a problem hiding this comment.
cohereApiUrl through the public search factory
When consumers configure the exported createSearchTool, this option cannot reach the newly updated factory: SearchToolConfig in src/tools/search/types.ts has no cohereApiUrl, and createSearchTool neither destructures nor forwards it in the call at src/tools/search/tool.ts:635-647. Consequently, a host-supplied custom Cohere endpoint is ignored and reranking still targets the environment/default URL; add the field to SearchToolConfig and pass it through alongside cohereApiKey.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Good catch — fixed in f1c5d0b: SearchToolConfig (types.ts) now declares cohereApiUrl, and createSearchTool (tool.ts) destructures and forwards it to createReranker alongside cohereApiKey, same as jinaApiUrl.
SearchToolConfig and createSearchTool destructured jinaApiUrl but not cohereApiUrl, so a host-supplied custom Cohere endpoint never reached createReranker — the option was accepted but silently ignored end to end. Forward it alongside cohereApiKey, mirroring jinaApiUrl.
|
@codex review the latest head |
|
Codex Review: Didn't find any major issues. 🎉 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
Great!! Thanks to all for the effort and @danny-avila for merging this! Really appreciated. |
Summary
CohereRerankernow accepts anapiUrloption, mirroringJinaReranker's existingapiUrl/JINA_API_URLpattern.COHERE_API_URLenv var, falling back tohttps://api.cohere.com/v2/rerankwhen unset.createRerankeraccepts and forwards a newcohereApiUrlfield.This lets callers point the Cohere reranker at a Cohere-compatible endpoint (e.g. a self-hosted LiteLLM proxy) instead of Cohere's own API, the same way
jinaApiUrlalready does for Jina.Companion PR on the LibreChat side wiring this through the web search config: LibreChat-AI/LibreChat#15518
Test plan
createRerankertests mirroring the existingJinaRerankersuitenpx jest cohere-reranker jina-reranker rag-api-reranker— 53/53 passingnpx tsc --noEmitandnpx eslint src/cleanA note on why this is a re-submission
This is at least the fourth independent submission of this exact feature on this repo. All add the same
apiUrl/COHERE_API_URLoption toCohereReranker. A one-file, backward-compatible, test-covered change going unreviewed for over a year — independently, from three different contributors — isn't a great signal about how community PRs get handled here.Related PRs:
The companion LibreChat-side PR (#9544, now closed in favor of #15518) has real users confirming the underlying need and the fix working in production. Happy to coordinate with @davidjrh and @npeham so effort isn't split four ways.