渠道配置中增加使用ResponsesAPI开关以将OpenAI Compatible转换为OpenAI Responses请求

[raoczh]

Summary by CodeRabbit

• New Features
  • Added a per-channel Responses API toggle in channel configuration settings. Users can now enable or disable Responses API format conversion on individual channels, providing granular control over request handling at the channel level while maintaining compatibility with existing global configuration.

[coderabbitai]

Walkthrough

The PR introduces a per-channel UseResponsesAPI configuration flag that allows individual channels to opt into Responses API format conversion for chat completions. Changes span the backend DTO, relay handlers, frontend UI component, and localization strings.

Changes

Cohort / File(s)	Summary
Backend Configuration dto/channel_settings.go	Added UseResponsesAPI boolean field with json:"use_responses_api,omitempty" tag to ChannelSettings struct.
Relay Handler Logic relay/claude_handler.go, relay/compatible_handler.go	Extended conditional checks in both handlers to trigger Responses API conversion when the per-channel UseResponsesAPI flag is true, in addition to the existing global gate.
Frontend UI & State web/src/components/table/channels/modals/EditChannelModal.jsx	Added use_responses_api field to component state, form initialization, channel data parsing, and modal reset logic. Introduced Form.Switch UI element with label and helper text for toggling the setting.
Localization web/src/i18n/locales/en.json	Added two new translation keys for the feature label and description in English.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• fix: 使用openai兼容接口调用部分渠道在最终端点为claude原生端点下还是走了openai扣减input_token的逻辑 #2883: Modifies chat-completions routing logic in relay/compatible_handler.go, directly overlapping with the conditional changes introduced here.
• feat: /v1/chat/completion -> /v1/response #2629: Enables chat-completions→responses routing in the same handler control flow paths.
• fix: volcengine claude DoResponse #2296: Changes how Claude requests are routed and converted to OpenAI format, affecting the same conversion logic extended by this PR.

Suggested reviewers

• seefs001

Poem

🐰 A switch for each channel, so fine and so neat,
The Responses API now makes the conversion complete!
Per-channel control, a flag shining bright,
Let handlers decide what feels just right. ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The pull request title accurately describes the main change: adding a UseResponsesAPI configuration switch at the channel level to enable conversion of OpenAI-compatible requests to OpenAI Responses format, which is reflected across all modified files.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

web/src/components/table/channels/modals/EditChannelModal.jsx (1)

3882-3896: Only show this toggle on channel types that actually support Responses conversion.

Right now every channel can save use_responses_api, but this feature is scoped much narrower than “all channels”. Rendering it unconditionally makes unsupported types look configurable even if the relay path ignores the flag. Wrapping this switch in a supported-type check would avoid misleading config.

♻️ Suggested direction

+const RESPONSES_API_SUPPORTED_TYPES = new Set([
+  // keep this aligned with the backend handlers that honor `use_responses_api`
+  1,
+  14,
+]);
...
-                    <Form.Switch
-                      field='use_responses_api'
-                      label={t('使用 Responses API')}
-                      checkedText={t('开')}
-                      uncheckedText={t('关')}
-                      onChange={(value) =>
-                        handleChannelSettingsChange(
-                          'use_responses_api',
-                          value,
-                        )
-                      }
-                      extraText={t(
-                        '开启后，该渠道收到 chat/completions 请求时自动转换为 Responses API 格式发送给上游',
-                      )}
-                    />
+                    {RESPONSES_API_SUPPORTED_TYPES.has(inputs.type) && (
+                      <Form.Switch
+                        field='use_responses_api'
+                        label={t('使用 Responses API')}
+                        checkedText={t('开')}
+                        uncheckedText={t('关')}
+                        onChange={(value) =>
+                          handleChannelSettingsChange(
+                            'use_responses_api',
+                            value,
+                          )
+                        }
+                        extraText={t(
+                          '开启后，该渠道收到 chat/completions 请求时自动转换为 Responses API 格式发送给上游',
+                        )}
+                      />
+                    )}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@web/src/components/table/channels/modals/EditChannelModal.jsx` around lines
3882 - 3896, The Form.Switch for 'use_responses_api' is rendered unconditionally
(Form.Switch, field='use_responses_api', onChange ->
handleChannelSettingsChange), which exposes the toggle for channel types that
don't support Responses conversion; wrap this Form.Switch in a conditional that
checks the channel's type (e.g., channel.type or currentChannel.type) against
the explicit set of supported types (create a const like
SUPPORTED_RESPONSE_CONVERSION_TYPES or reuse an existing list) so the toggle
only renders when the channel type is in that set; keep the onChange handler
(handleChannelSettingsChange) and texts unchanged when visible.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@web/src/components/table/channels/modals/EditChannelModal.jsx`:
- Around line 3882-3896: The Form.Switch for 'use_responses_api' is rendered
unconditionally (Form.Switch, field='use_responses_api', onChange ->
handleChannelSettingsChange), which exposes the toggle for channel types that
don't support Responses conversion; wrap this Form.Switch in a conditional that
checks the channel's type (e.g., channel.type or currentChannel.type) against
the explicit set of supported types (create a const like
SUPPORTED_RESPONSE_CONVERSION_TYPES or reuse an existing list) so the toggle
only renders when the channel type is in that set; keep the onChange handler
(handleChannelSettingsChange) and texts unchanged when visible.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 8620f9ac-3e31-4f5a-8e82-11906a6b0dcd

📥 Commits

Reviewing files that changed from the base of the PR and between c706a5c and 77617cd.

📒 Files selected for processing (5)

• dto/channel_settings.go
• relay/claude_handler.go
• relay/compatible_handler.go
• web/src/components/table/channels/modals/EditChannelModal.jsx
• web/src/i18n/locales/en.json