使用场景
CCH 同时配置了两类供应商：
- Codex（Responses API）供应商：用于日常代码任务，价格较低；
- OpenAI Compatible 图片供应商：只支持
/v1/images/generations，可用 gpt-image-* 模型，但价格较高。
客户端是 Codex，只配置一个 CCH Base URL 和 Key。期望普通代码请求继续使用 Codex 供应商，只有 Codex 内置生图请求才使用专门的图片供应商。
当前行为
Codex 内置生图发送的是：
POST /v1/responses
tools: [{ type: "image_generation" }]
CCH 会将请求识别为 response 格式，并只允许选择 providerType=codex 的供应商。providerType=openai-compatible 的图片供应商会在优先级比较之前被过滤：
reason: format_type_mismatch
原始格式 response 与供应商类型 openai-compatible 不兼容
因此：
- 直接请求
/v1/images/generations 可以正常使用图片供应商；
- Codex 内置生图无法使用该图片供应商；
- 调整优先级、模型限制、模型重定向或“图像生成工具覆写”均无法改变路由；
- 把图片供应商改成 Codex 类型也不可行，因为上游只实现 Images API，没有实现
/v1/responses。
期望功能
增加一个范围严格的“Responses 图片工具桥接”，仅将明确的内置生图请求转换为 OpenAI Images API 请求，而不是恢复完整的跨格式转换系统。
建议允许在后台配置：
- 是否启用 Responses 图片桥接；
- 目标图片供应商、供应商组或供应商类型；
- 目标图片模型，例如
gpt-image-2；
- 默认尺寸、质量等可选参数。
转换流程：
/v1/responses + image_generation
→ /v1/images/generations
→ 指定的 OpenAI Compatible 图片供应商
→ 将 Images 响应包装回 Responses image_generation_call
防止误伤普通代码任务
不建议仅根据 tools 中出现 image_generation 就触发，因为客户端可能在普通代码任务中预先声明多个工具。
建议只在以下条件同时成立时触发：
pathname == /v1/responses
AND tools 包含 image_generation
AND (
tool_choice.type == image_generation
OR allowed_tools 中只允许 image_generation
OR 存在明确的客户端生图标记
)
如果只是：
{
"tools": [{ "type": "image_generation" }, { "type": "function" }],
"tool_choice": "auto"
}则保持原有 Codex 路由，不触发桥接。
其他实现注意事项
- 桥接请求应跳过 sticky session 复用，避免继续绑定到代码供应商；
- 供应商筛选和模型限制应使用实际图片模型，而不是原始代码模型；
stream=true 时需要生成 Responses SSE 事件；- 图片费用应按实际图片模型、尺寸、质量和数量计算；
- 日志中建议同时记录原始 Responses 模型与实际图片模型；
- 上游错误应转换为客户端可识别的 Responses 错误。
与现有设计的关系
理解项目在 #709 中明确采用严格同格式路由，并且 #666、#707 表示完整转换器不在近期计划内。本需求不是要求恢复 Claude/OpenAI/Codex/Gemini 的通用转换器，而是希望增加一个边界清晰、仅覆盖内置生图的专用桥接。
现有 #1307 的“Codex 图像生成工具覆写”只负责注入或移除 image_generation 工具；#1070 已实现标准 OpenAI Images API 支持。希望可以在这两部分能力之间增加一个可选的专用路由桥接。
验收标准
- 普通
/v1/responses 代码请求行为完全不变；
- 仅声明图片工具但
tool_choice=auto 的普通请求不触发桥接；
- 明确强制
image_generation 的请求进入指定图片供应商；
- 非流式和流式 Responses 返回均可被 Codex 正常解析；
- 图片按实际图片模型计费；
- 后台可以关闭该功能并恢复当前严格同格式行为。
使用场景
CCH 同时配置了两类供应商：
/v1/images/generations，可用gpt-image-*模型，但价格较高。客户端是 Codex，只配置一个 CCH Base URL 和 Key。期望普通代码请求继续使用 Codex 供应商，只有 Codex 内置生图请求才使用专门的图片供应商。
当前行为
Codex 内置生图发送的是：
CCH 会将请求识别为
response格式，并只允许选择providerType=codex的供应商。providerType=openai-compatible的图片供应商会在优先级比较之前被过滤：因此：
/v1/images/generations可以正常使用图片供应商；/v1/responses。期望功能
增加一个范围严格的“Responses 图片工具桥接”，仅将明确的内置生图请求转换为 OpenAI Images API 请求，而不是恢复完整的跨格式转换系统。
建议允许在后台配置：
gpt-image-2；转换流程：
防止误伤普通代码任务
不建议仅根据
tools中出现image_generation就触发，因为客户端可能在普通代码任务中预先声明多个工具。建议只在以下条件同时成立时触发：
如果只是：
{ "tools": [{ "type": "image_generation" }, { "type": "function" }], "tool_choice": "auto" }则保持原有 Codex 路由，不触发桥接。
其他实现注意事项
stream=true时需要生成 Responses SSE 事件；与现有设计的关系
理解项目在 #709 中明确采用严格同格式路由，并且 #666、#707 表示完整转换器不在近期计划内。本需求不是要求恢复 Claude/OpenAI/Codex/Gemini 的通用转换器，而是希望增加一个边界清晰、仅覆盖内置生图的专用桥接。
现有 #1307 的“Codex 图像生成工具覆写”只负责注入或移除
image_generation工具；#1070 已实现标准 OpenAI Images API 支持。希望可以在这两部分能力之间增加一个可选的专用路由桥接。验收标准
/v1/responses代码请求行为完全不变；tool_choice=auto的普通请求不触发桥接；image_generation的请求进入指定图片供应商；