feat(channel): add dual endpoint support for ali and minimax token plans - #4639
feat(channel): add dual endpoint support for ali and minimax token plans#4639kewell-tsao wants to merge 1 commit into
Conversation
Add ali-token-plan and minimax-token-plan to ChannelSpecialBases, enabling direct routing to provider-specific endpoints based on RelayFormat (Claude vs OpenAI) without format conversion.
WalkthroughThis PR introduces special-base routing for channel adapters. New entries are added to the ChannelSpecialBases constant map ("ali-token-plan", "minimax-token-plan", and updated "doubao-coding-plan"), and the Ali and Minimax adapters are modified to check these entries and route requests through the corresponding Claude or OpenAI base URLs. ChangesSpecial-Base Channel Routing
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@relay/channel/ali/adaptor.go`:
- Around line 96-102: The early-return in adaptor.go that maps
ChannelSpecialBases[baseURL] to either specialPlan.ClaudeBaseURL for
types.RelayFormatClaude or specialPlan.OpenAIBaseURL for others can misroute
requests and bypass relay-mode paths; update the routing so it does not
unconditionally pick Claude vs OpenAI by RelayFormat alone but instead reuses
the same special-plan resolution logic used by ConvertClaudeRequest and
DoResponse (so path, payload shape and response parsing remain consistent),
i.e., determine the intended upstream route based on the request's intended mode
(embedding/rerank/image/response) and the model-gated conversion logic, then
build the URL from specialPlan accordingly rather than short-circuiting on
info.RelayFormat.
In `@relay/channel/minimax/relay-minimax.go`:
- Around line 18-24: When a specialPlan is found the code currently forces all
non-Claude traffic to specialPlan.OpenAIBaseURL + "/chat/completions", dropping
relay-mode routing; change the branch so that after handling RelayFormatClaude
(using specialPlan.ClaudeBaseURL + "/v1/messages") you select the OpenAI
endpoint based on the same relay-format/mode logic used for the normal
(non-special) path, i.e. use info.RelayFormat / any RelayMode fields to choose
the correct path and then return specialPlan.OpenAIBaseURL + that path instead
of always "/chat/completions" (inspect and reuse the routing logic applied
elsewhere for non-special bases).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 1e5756e0-5cef-4485-832b-f24ce58fe6fe
📒 Files selected for processing (3)
constant/channel.gorelay/channel/ali/adaptor.gorelay/channel/minimax/relay-minimax.go
| if specialPlan, ok := channelconstant.ChannelSpecialBases[baseURL]; ok { | ||
| switch info.RelayFormat { | ||
| case types.RelayFormatClaude: | ||
| return fmt.Sprintf("%s/v1/messages", specialPlan.ClaudeBaseURL), nil | ||
| default: | ||
| return fmt.Sprintf("%s/chat/completions", specialPlan.OpenAIBaseURL), nil | ||
| } |
There was a problem hiding this comment.
Special-plan early return can mismatch URL with request/response format paths.
Line 98-101 forces Claude requests to anthropic URL and all non-Claude to chat-completions. That conflicts with existing model-gated conversion/response logic (Line 75-87, Line 255-263) and bypasses relay-mode routes (embeddings/rerank/images/responses), causing invalid upstream calls for reachable paths.
Suggested direction
baseURL := info.ChannelBaseUrl
if specialPlan, ok := channelconstant.ChannelSpecialBases[baseURL]; ok {
switch info.RelayFormat {
case types.RelayFormatClaude:
- return fmt.Sprintf("%s/v1/messages", specialPlan.ClaudeBaseURL), nil
+ if supportsAliAnthropicMessages(info.UpstreamModelName) {
+ return fmt.Sprintf("%s/v1/messages", specialPlan.ClaudeBaseURL), nil
+ }
+ // fallback to existing OpenAI-compatible routing path below
default:
- return fmt.Sprintf("%s/chat/completions", specialPlan.OpenAIBaseURL), nil
+ // only short-circuit chat-completions; keep other relay modes on existing switch below
+ if info.RelayMode == constant.RelayModeCompletions || info.RelayMode == constant.RelayModeChatCompletions {
+ return fmt.Sprintf("%s/chat/completions", specialPlan.OpenAIBaseURL), nil
+ }
}
}Also ensure ConvertClaudeRequest/DoResponse use the same special-plan rule so URL, payload shape, and response parser stay consistent.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@relay/channel/ali/adaptor.go` around lines 96 - 102, The early-return in
adaptor.go that maps ChannelSpecialBases[baseURL] to either
specialPlan.ClaudeBaseURL for types.RelayFormatClaude or
specialPlan.OpenAIBaseURL for others can misroute requests and bypass relay-mode
paths; update the routing so it does not unconditionally pick Claude vs OpenAI
by RelayFormat alone but instead reuses the same special-plan resolution logic
used by ConvertClaudeRequest and DoResponse (so path, payload shape and response
parsing remain consistent), i.e., determine the intended upstream route based on
the request's intended mode (embedding/rerank/image/response) and the
model-gated conversion logic, then build the URL from specialPlan accordingly
rather than short-circuiting on info.RelayFormat.
| if specialPlan, ok := channelconstant.ChannelSpecialBases[baseUrl]; ok { | ||
| switch info.RelayFormat { | ||
| case types.RelayFormatClaude: | ||
| return fmt.Sprintf("%s/v1/messages", specialPlan.ClaudeBaseURL), nil | ||
| default: | ||
| return fmt.Sprintf("%s/chat/completions", specialPlan.OpenAIBaseURL), nil | ||
| } |
There was a problem hiding this comment.
Special-plan path drops relay-mode routing for non-Claude requests.
At Line 23, all non-Claude traffic is forced to /chat/completions, so image/audio relay modes are misrouted when baseUrl is a special plan.
Suggested fix
if specialPlan, ok := channelconstant.ChannelSpecialBases[baseUrl]; ok {
switch info.RelayFormat {
case types.RelayFormatClaude:
return fmt.Sprintf("%s/v1/messages", specialPlan.ClaudeBaseURL), nil
default:
- return fmt.Sprintf("%s/chat/completions", specialPlan.OpenAIBaseURL), nil
+ switch info.RelayMode {
+ case constant.RelayModeChatCompletions:
+ return fmt.Sprintf("%s/chat/completions", specialPlan.OpenAIBaseURL), nil
+ default:
+ return "", fmt.Errorf("relay mode %d is not supported for special base %q", info.RelayMode, baseUrl)
+ }
}
}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@relay/channel/minimax/relay-minimax.go` around lines 18 - 24, When a
specialPlan is found the code currently forces all non-Claude traffic to
specialPlan.OpenAIBaseURL + "/chat/completions", dropping relay-mode routing;
change the branch so that after handling RelayFormatClaude (using
specialPlan.ClaudeBaseURL + "/v1/messages") you select the OpenAI endpoint based
on the same relay-format/mode logic used for the normal (non-special) path, i.e.
use info.RelayFormat / any RelayMode fields to choose the correct path and then
return specialPlan.OpenAIBaseURL + that path instead of always
"/chat/completions" (inspect and reuse the routing logic applied elsewhere for
non-special bases).
|
无支持计划 |
Add ali-token-plan and minimax-token-plan to ChannelSpecialBases, enabling direct routing to provider-specific endpoints based on RelayFormat
(Claude vs OpenAI) without format conversion.
📝 变更描述 / Description
为
ChannelTypeAli和ChannelTypeMiniMax新增双端点支持。当渠道的base_url设置为特定标识字符串时(如ali-token-plan、minimax-token-plan),系统可根据请求的RelayFormat(Claude 格式 vs OpenAI 格式)自动路由到对应的 provider原生端点,无需进行请求格式转换。
实现方式:
ChannelSpecialBases映射中新增ali-token-plan和minimax-token-plan条目GetRequestURL()方法中优先检查ChannelSpecialBases,匹配时按格式路由到对应端点路由规则:
ali-token-plan: Claude 格式 →https://token-plan.cn-beijing.maas.aliyuncs.com/apps/anthropic/v1/messages;其他格式 →https://token-plan.cn-beijing.maas.aliyuncs.com/compatible-mode/v1/chat/completionsminimax-token-plan: Claude 格式 →https://api.minimaxi.com/anthropic/v1/messages;其他格式 →https://api.minimaxi.com/v1/chat/completions🚀 变更类型 / Type of change
🔗 关联任务 / Related Issue
ali-token-plan,本次补充minimax-token-plan✅ 提交前检查项 / Checklist
go build编译通过,gopls check无错误📸 运行证明 / Proof of Work
$ go build ./relay/channel/minimax/... ./relay/channel/ali/... ./constant/...
✅ Build passed
$ gopls check relay/channel/minimax/relay-minimax.go relay/channel/ali/adaptor.go constant/channel.go
✅ gopls check passed1
$ go vet ./relay/channel/minimax/... ./relay/channel/ali/... ./constant/...
✅ go vet passed
$ go test ./relay/channel/minimax/... -v
=== RUN TestGetRequestURLForImageGeneration
--- PASS: TestGetRequestURLForImageGeneration (0.00s)
=== RUN TestConvertImageRequest
--- PASS: TestConvertImageRequest (0.00s)
=== RUN TestDoResponseForImageGeneration
--- PASS: TestDoResponseForImageGeneration (0.00s)
PASS
ok github.com/QuantumNous/new-api/relay/channel/minimax 0.008s
📚 参考文档 / Reference Documentation
MiniMax 文档:
阿里云百炼文档:
Summary by CodeRabbit