Repository navigation
[Bug] 自定义 provider 选择的 API 风格（Responses）被内置 catalog 覆盖，实际请求发往 chat/completions #1331
Description
Activity
已在最新 main 上核实：这个问题已被合入 main 的修复 a93b788（
fix(models): honor custom limits and API styles）解决，尚未包含在 0.16.0 发布版中。该提交在
providerRequestTransport中为 custom endpoint 增加了专用分支：当vendorKey === "custom"时，API 风格直接取provider.apiStyle ?? modelStyle，即用户为自定义 provider 显式选择的 API 风格（如 Responses）优先于任何基于模型 id 的 catalog/relay 匹配，不再被静默覆盖为chat/completions。对应代码（packages/agent-runtime/src/provider-binding.ts）：
const apiStyle = customEndpoint ? provider.apiStyle ?? modelStyle : (isCompatible ? modelStyle : undefined) ?? provider.apiStyle;
请等下一个包含 a93b788 的版本发布后再验证；若届时仍有覆盖，欢迎重新打开并附抓包日志。
问题描述
为一个自定义（OpenAI 兼容）provider 显式选择了 API 风格「Responses」，但当模型 id 命中内置 catalog（models.dev 数据）里的同名条目时，该设置会被 catalog 静默覆盖，请求实际发往
/v1/chat/completions，而不是/v1/responses。影响：用户在自定义 provider 上显式选择的接口风格被忽略；对于只实现单一端点的中转/网关，会导致请求打到错误的端点。
复现步骤
https://<host>/v1，API 风格 = Responsesglm-5.3预期行为
POST /v1/responses（与配置的 apiStyle=responses 一致）实际行为
POST /v1/chat/completions，且请求体使用max_tokens字段应用版本
0.16.0
操作系统
Windows
其他环境信息
Windows 11 · protocol 11 · host 0.16.0 · NSIS 安装
日志
代理抓到的出站请求：
provider 配置：vendorKey=custom、apiStyle=responses、baseUrl=https:///v1
根因（来自打包后的 bundle）
providerRequestTransport：const apiStyle = resolveApiStyle(provider.modelConfig?.api) ?? provider.apiStyle;—— catalog 提供的
api优先于用户配置的provider.apiStyle。findModelOfType会回退到relayChatMetadata(models, "glm-5.3")，命中内置条目{"id":"glm-5.3","api":"openai-completions", ...}，从而覆盖用户显式选择的responses。建议修复
自定义/非 catalog provider 应优先采用用户配置的
provider.apiStyle，或至少不要让基于模型 id 的 relay 匹配覆盖用户的显式选择。