OpenCode 可以使用来自云端 Provider、AI Gateway、订阅服务和本地 Runtime 的模型。根据当前官方 Provider 文档，stable OpenCode 通过 AI SDK 和 Models.dev 支持 75 个以上的 Provider，也支持本地模型。
但这不代表整个生态里的每个模型都会自动出现在每个 OpenCode 项目中。真正可用需要满足三项条件：
- Provider 已经在运行 OpenCode 的环境中完成连接并启用；
- 模型以准确的
provider/model-id出现在当前项目的/models选择器中； - 这个 Provider 与模型的组合支持任务真正需要的工具、输入模态、上下文、额度和稳定性。
这个区别很重要，因为 OpenCode 是 Agent harness，不是模型本身。如果这些层级还容易混淆，可以先看 Agent harness 与模型的区别，再决定连接哪个 Provider。
最后核验：2026-08-27。 Provider 数量、模型 ID、目录、命令以及 stable/v2 行为都可能变化。依赖某个组合前，应重新查看 OpenCode 当前文档和实际
/models选择器。
OpenCode 的支持范围是实时目录，不是永久名单
一张“OpenCode 支持的所有模型”静态表格很快就会过期。Provider 会增加或移除 Endpoint，模型 ID 会变化，访问资格取决于账号和凭证，本地 Runtime 则只会暴露当前机器真正安装并正确启动的模型。
因此，OpenCode 会从多个来源构建可用目录：
- OpenCode 自带的 Provider Integration；
- Models.dev 提供的模型元数据；
- 用户在 OpenCode 配置中添加的 Provider 与模型；
- 当前环境可用的凭证和订阅；
- 已正确配置的本地模型 Runtime。
最终结果与项目环境有关。一个模型出现在 Provider 官网，并不代表没有连接 Provider 的 OpenCode 会显示它；一位开发者电脑上可见的模型，也可能不在另一位同事的环境中。同一个模型由不同 Provider 提供时，价格、Rate Limit、延迟和参数支持也可能不同。
所以，更可靠的问题不是“OpenCode 在某个地方是否支持模型 X”，而是“当前项目是否暴露了我准备使用的准确 provider/model 组合”。
先分清三层：Harness、Provider 与 Model
这三个名称经常同时出现，但各自承担不同工作。
同一个模型系列可能由多个 Provider 提供，同一个 Provider 也可能暴露多个模型。即使界面里的模型名称相似，改变其中任何一层，都可能改变最终结果。
这也是为什么“支持 Function Calling”不等于“能可靠完成 Coding Agent 任务”。模型要生成有效 Tool Call，Provider 要保留所需的请求和返回行为，Harness 还要把调用转换为正确工具，并处理失败恢复。
如果比较的是 Harness 本身，应从 Provider 灵活性、认证、权限、Runtime 与产品入口出发，比较 OpenCode 与 Codex 这两个 Agent Harness，而不是把模型访问当成全部选择。
如果候选的一方是 Anthropic 第一方 harness，可以继续看 Claude Code 与 OpenCode 对比，再比较 Provider 控制、权限、Runtime、价格与迁移成本。
如何查看当前 OpenCode 项目可用的模型？
先从你真正准备使用的 stable OpenCode 环境开始。如果还没有安装或连接，可以先按stable OpenCode 安装指南完成基础设置。
1. 连接有权使用的 Provider
在 OpenCode TUI 中运行：
选择 Provider，并使用你有权使用的认证方式。不同 Provider 的条件不同：有的需要 API Key，有的提供订阅登录，本地 Runtime 则可能依赖当前电脑上运行的服务。
如果你准备使用 OpenAI 订阅登录而不是 API Key，可以按单独的指南在 OpenCode 中使用 ChatGPT Plus 或 Pro 订阅，并在认证后核对该账户实际显示的模型。
不要把真实密钥写进已提交的 opencode.json、截图、公开 Issue 或共享 Transcript。凭证保存方式和账号限制应以当前 Provider 官方页面为准。
2. 打开模型选择器
连接 Provider 后，在 OpenCode 中运行：
这个选择器是当前环境真正能选择哪些模型的直接证据。请复制界面显示的完整模型 ID，不要根据营销名称自行拼一个 ID。
如果目标模型没有出现，先检查 Provider 连接、账号资格、地区、项目配置和当前官方模型目录。反复猜测不同 ID，不会让一个暂时不可用的模型变得兼容。
3. 记录完整模型引用
Stable OpenCode 使用下面的格式标识模型：
Provider 前缀是选择的一部分。即使底层属于同一个模型系列，provider-a/model-x 与 provider-b/model-x 也是两条不同运行路径。
4. 用一个有边界的任务确认
模型出现在 /models，只证明可以选择，不证明适合生产。应该给它一个会真正用到所需能力的小任务：读取几个相关文件、调用一个安全工具、提出 Patch、运行一条验证命令，并在明确验收条件完成后停止。
比较候选模型时，保持代码库起点、Prompt、工具和验收测试一致。否则最后无法判断差异来自模型，还是来自另一个运行层。
不猜 ID，正确配置默认模型
Stable 模型文档允许在 opencode.json 中设置默认模型：
请把占位内容替换为 /models 中显示的准确引用。不要假设界面名称、API 营销名称和 OpenCode Catalog ID 完全一致。
当前 Session 选择模型，与写入默认模型配置是两件事。Session 中的选择可以改变而不重写配置；配置则为以后满足条件的 Session 提供默认值。OpenCode 也允许 Agent 或 Command 指定自己的模型，因此 Planning 或 Review Agent 可以与主要执行 Agent 使用不同模型。
Model Variant 又增加了一层。Variant 可能改变推理强度或 Provider 特定设置，但名称并不通用。应该使用 OpenCode 为当前模型真正显示的 Variant，不要默认每个模型都有 low、high 或 max。
OpenCode 可以使用哪些类型的 Provider？
当前 stable Provider 目录大致包括几种访问方式。
模型厂商的直接 Provider
这类路径把 OpenCode 连接到模型公司的 API 或经过授权的订阅入口。账号资格、计费、Rate Limit、可用模型与数据处理条款由对应 Provider 决定。
AI Gateway 与路由 Provider
Gateway 可以通过一个 API 提供多个模型厂商的模型，可能简化账单或路由，但也会增加 Provider 自己的行为。同一个模型通过不同路径使用时，Fallback、量化、延迟、参数支持和数据控制都可能不同。
OpenCode Go 与 Zen
OpenCode 也提供可选的 Provider 产品。Go 对一个筛选后的模型池采用订阅额度，Zen 使用按量余额。它们是 Provider 选择，不是使用 OpenCode harness 的必要条件。计费差异可以查看单独的 OpenCode Go 与 Zen 对比。
本地与自定义 Provider
OpenCode 文档也包含本地 Runtime 和 OpenAI-compatible 自定义 Endpoint。HTTP 接口兼容只代表起点；配置中的模型 ID、上下文限制、最大输出、输入模态和工具支持，仍然要与真实服务一致。
本地部署可以增加对基础设施和数据流的控制，但也让用户承担硬件、Runtime 配置、更新、吞吐和安全责任。“本地”不会自动等于更快、更私密或配置正确。
OpenCode 模型兼容性检查表
在让一个模型执行 Agentic Coding 前，至少检查下面六部分合同。
可用性
- Provider 能否在真正运行任务的环境中连接？
/models是否显示准确模型引用？- 账号在目标地区和计费方案中是否有权访问？
工具行为
- 这条 Provider/模型路径是否支持 Tool 或 Function Calling？
- Tool 参数能否通过 Harness Schema？
- 模型能否从工具错误中恢复，并在通过验收后停止？
上下文与输出
- 真实上下文窗口是否能容纳 Harness 发送的文件和工具输出？
- 最大输出是否足以容纳 Patch 或结构化结果？
- Provider 是否保留工作流依赖的 Streaming、Reasoning 或 Structured Output 字段？
输入模态
- 任务包含截图或文件时，准确的 Provider/模型组合是否接受这些输入？
- Harness 是否用这条路径要求的格式传递内容？
成本与额度
- 当前输入、输出、缓存、请求和工具费用分别是什么？
- 是否存在 Rate、Session、周或月额度？
- 把失败重试计入后，一个真正通过验证的任务成本是多少？
数据与运维
- Prompt、文件和输出在哪里处理？
- 选定 Provider 的日志和保留条款是什么？
- 谁负责凭证轮换、故障处理和 Provider 变化？
通过六项检查也不能保证质量，但可以说明这次比较至少在技术上成立。
选择 OpenCode 模型时常见的错误
把所有 Provider 路径当成相同服务
模型名称无法概括 Provider 行为。应该记录完整 provider/model-id，不能只记模型系列。
从旧教程复制静态名单
使用 /models 和当前官方文档。过期名单可能包含已经下线的 ID、旧价格或只属于 Beta 的配置结构。
混用 stable 与 v2 配置
OpenCode 分开记录 stable 与 v2 轨道。本文示例使用 2026 年 8 月 27 日核验的 stable 根路径文档。除非准备完整迁移，否则不要把 v2 的复数字段或 opencode2 命令复制到 stable opencode 环境。
以为大上下文等于理解整个代码库
容量不等于正确检索。文件选择、搜索、Instructions、Compaction 和验证仍由 Harness 工作流决定。
没检查运行路径就开放写权限
先使用只读或需要批准的任务。确认 Provider 与模型行为符合预期后，再在授权写入前设置 OpenCode 权限。
一套可执行的选型流程
与其寻找一个通用“最强 OpenCode 模型”，不如走一遍短而有证据的流程：
- 定义一个有代表性的 Coding 任务和验收命令。
- 只连接你有权使用的 Provider。
- 从
/models复制候选模型 ID。 - 核对工具、输入模态、上下文和额度。
- 从相同代码库状态、相同权限运行候选模型。
- 比较通过验收的质量、耗时、重试次数和总成本。
- 保存完整模型引用与决策日期。
OpenCode 广泛的 Provider 支持带来更多选择，但不会自动产生兼容性。更持久的答案，是核验实时目录、保留 Provider 与 Model 的区别，并测试你真正准备运行的完整 Agent 循环。
FAQ
OpenCode 自带模型吗？
OpenCode 主要是 Agent harness。它连接模型 Provider，其中包括可选的 OpenCode Go 与 Zen 服务，但不会把某一个捆绑模型作为使用产品的唯一方式。
OpenCode 可以使用本地模型吗？
可以。官方 Provider 文档记录了本地模型和 OpenAI-compatible 自定义 Endpoint。实际工具支持、限制、速度和质量仍取决于模型服务与配置。
为什么模型没有出现在 /models？
常见原因包括 Provider 尚未连接、账号或地区没有访问资格、模型当前不可用、项目配置不匹配，或者假设了错误的 Provider/模型组合。应检查当前官方文档和真实环境，而不是自己编一个 ID。
Plan 与 Build 可以使用不同模型吗？
OpenCode 的 Agent 配置可以为 Agent 指定模型，所以专用 Agent 可以使用不同模型。请核对当前 stable Agent 语法，并且只选择相关环境中真正可见的模型引用。
OpenCode Provider 支持某模型，是否代表 Agent.Space 也支持？
不是。OpenCode 上游目录与 Agent.Space 生产兼容性是两个独立事实。需要以当前 Agent.Space 模型选择器为准。