OpenCode怎么接第三方API？自定义Provider与Responses配置实战

OpenCode安装完成后，如果不想只使用默认模型，下一步通常就是配置第三方API。相比普通聊天客户端，OpenCode需要多注意一项：不同模型可能走Chat Completions，也可能走Responses API，Provider配置不能只换一个Base URL就结束。

截至2026年8月28日，OpenCode官方文档已经支持添加自定义OpenAI兼容Provider，并允许配置API Key、Base URL和Model ID；新版Provider体系还分别提供OpenAI Compatible、Chat和Responses相关运行包。

一、OpenCode接第三方API，本质上先确认四项

可以把配置理解成：

text 复制代码

OpenCode
   ↓
Provider
   ↓
API Key + Base URL
   ↓
Model ID
   ↓
目标模型

真正容易出错的是：

配置	常见问题
Provider	Chat和Responses类型选错
API Key	凭据没有正确保存
Base URL	`/v1`层级错误
Model ID	自己简写模型名称

OpenCode官方建议，自定义Provider先通过/connect添加凭据，再在配置文件中定义Provider和模型；出现问题时可以使用opencode auth list确认凭据是否已经写入。

二、普通OpenAI兼容接口可以这样配置

当前OpenCode新版文档中的自定义Provider结构类似：

json 复制代码

{
  "$schema": "https://opencode.ai/config.json",
  "providers": {
    "my-api": {
      "name": "My API",
      "env": ["MY_API_KEY"],
      "package": "@opencode-ai/ai/providers/openai-compatible",
      "settings": {
        "baseURL": "https://api.example.com/v1"
      },
      "models": {
        "coding-model": {
          "name": "Coding Model"
        }
      }
    }
  }
}

其中最值得注意的是baseURL和模型ID。OpenCode官方文档明确支持通过settings.baseURL把Provider指向兼容Endpoint，同时可以在models中定义或覆盖实际模型。

配置完成后，再从OpenCode选择对应模型测试即可。

三、Chat能用，不代表Responses一定能用

这是OpenCode接第三方API时比较容易忽略的一点。

传统OpenAI兼容接口通常是：

text 复制代码

POST /v1/chat/completions

而部分Coding Agent或新模型会使用：

text 复制代码

POST /v1/responses

OpenCode当前官方故障排查文档明确指出：普通OpenAI兼容Provider可以使用对应Chat兼容包；如果模型走/v1/responses，则需要选择Responses对应的Provider实现。

因此，如果出现：

text 复制代码

Chat测试成功
↓
OpenCode Agent任务却异常

不要马上判断模型不可用。

先确认：

当前模型实际需要Chat还是Responses？

四、4SAPI适合怎么接入OpenCode？

如果团队本来就需要GPT、Claude、Gemini、DeepSeek、Kimi、Qwen等多个模型，就没有必要为OpenCode再单独维护很多Provider账户。

4SAPI（4sapi.cn）现有文档同时提供/v1/chat/completions和/v1/responses接口，并要求调用时使用模型列表中的完整Model ID。平台资料也显示其定位是多模型API统一接入与集中管理。

因此在OpenCode里可以按目标模型选择对应Provider类型，再把Base URL、Key和Model ID配置进去。

不过这里不建议一次添加几十个模型。更实用的是先选择：

text 复制代码

一个代码主模型
+
一个备用模型
+
一个低成本模型

先验证真实开发任务。

五、第一次测试不要只问"Hello"

OpenCode属于Coding Agent，真正需要验证的是Agent链路。

可以直接给一个小任务：

阅读当前项目的README和package配置，告诉我项目如何启动，不修改任何文件。

然后继续测试：

能否读取多个文件；
是否能正确理解项目；
Tool Calling是否正常；
长任务是否中断；
Streaming是否持续；
Token和调用记录是否正常。

如果基础聊天成功，但一涉及文件和工具就失败，问题通常已经不是Key，而是Provider或协议兼容层。

六、什么时候值得从单模型切到统一API？

如果目前只是：

text 复制代码

OpenCode
+
一个固定模型

官方API通常最简单。

但如果逐渐变成：

text 复制代码

OpenCode
Cursor
Codex
Dify
+
多个模型

同时还要维护不同Key、Base URL和账单，那么统一API入口的价值才真正开始体现。

更稳妥的做法是先创建独立测试Key，用现有项目跑20---50次真实Agent任务。如果代码读取、工具调用、Responses和调用日志都符合要求，再决定是否迁移长期开发环境。

FAQ

OpenCode支持第三方OpenAI兼容API吗？

支持。官方目前允许创建自定义Provider并配置API Key、Base URL和模型。

为什么Chat接口正常，OpenCode还是不能稳定运行？

可能是目标模型实际使用Responses API，或者Tool Calling、模型能力配置没有正确适配。

Model ID可以自己写简称吗？

不建议。应该直接复制API服务提供的完整模型ID，避免出现Model Not Found或错误路由。

结语

OpenCode接第三方API真正需要确认的不是"能不能返回一句话"，而是：

Provider类型、Base URL、Model ID以及Chat/Responses协议是否匹配。

如果只使用单一模型，官方直连已经够用；当OpenCode开始和Codex、Cursor以及多个模型同时进入开发流程后，再考虑统一API管理，会比单纯增加更多Provider更容易维护。