跳到正文
FunCoding

搜索

搜索文档、Skill 和 MCP

OpenAI API 路由与 Responses

使用 wireApi 选择请求格式,处理旧配置、推理状态和请求体覆盖。

新配置在 openai 模型条目上设置 wireApi。它是本地路由元数据,不属于 generationConfig,也不会作为请求体字段发送。

选择 API

{
  "modelProviders": {
    "openai": [
      {
        "id": "my-model",
        "wireApi": "responses",
        "envKey": "OPENAI_API_KEY",
        "baseUrl": "https://api.openai.com/v1"
      }
    ]
  },
  "security": { "auth": { "selectedType": "openai" } },
  "model": { "name": "my-model" }
}

将 my-model 替换为真实可用的 Responses 模型。wireApi 仅接受 chat-completions 与 responses;openai 省略该字段时使用 Chat Completions,自定义映射到 openai 的 provider 也相同。

Anthropic、Gemini、Vertex AI 或 Qwen OAuth 条目不能使用 wireApi。api 也不是它的别名。交互设置时从 /auth → Custom Provider 选择 OpenAI-compatible,再选择 API 格式。

两种路由如何共存

同名模型和同一个 baseUrl 可以同时定义两个 API 路由,选择器与会话记录保留有效协议,因而能分别选择和恢复。启动 selectedType 为 openai 时,如果所选端点没有匹配 Chat 路由,可以解析到显式 Responses 路由。

请求失败不会触发端点探测或自动改用另一 API。配置两条路由与自动故障回退是不同能力。

自定义设置向导会为同一 OpenAI 端点的两种 API 共用凭据槽,轮换 Key 会影响两条路由。手工配置独立 envKey 可分开凭据。

旧格式兼容

v0.23.3 发布的 modelProviders.openai-responses 与映射到 openai-responses 的 providerProtocol 仍可读取。显式 provider 映射优先于桶名称,显式 wireApi 优先于二者。

读取不会直接重写配置或改变 Key 引用。重新配置时,只迁移可写范围内选中的匹配旧条目;包含点号的 provider ID 保留原位,无关模型、端点、API 与范围不受影响。

推理内容与恢复

兼容端点返回 reasoning.encrypted_content 时,可在后续轮次和 --resume 时重放不透明推理状态。只提供 response.reasoning_text.delta 的端点可显示思考文本,但没有 encrypted_content 就不能重放该不透明状态。

推理强度使用 generationConfig.reasoning.effort。Responses 的 extra_body 只补充生成请求中尚不存在的字段,不能覆盖已有 model、input、reasoning、temperature 或 max_output_tokens。

旧 extra_body.enable_thinking 不会原样发送;未显式配置 reasoning 时,true 会转换为 medium effort。新配置应直接设置 reasoning,避免依赖兼容转换。