配置与验证示例
接入包检查模式不发请求；客户端与脚本按各自说明操作。
opencode --version
opencode run --model apizt/YOUR_SUPPORTED_MODEL_ID --format json \
"读取当前仓库失败测试，只修改实现，不修改测试。运行测试并报告结果。"
git diff --stat
git diff正在打开页面…
正在加载内容，请稍候。
报错排查 / OpenCode
OpenCode AI_APICallError：状态码、Provider 与协议
OpenCode AI_APICallError 是外层错误名称，先展开状态码、responseBody、请求路径和 provider/model。根据底层原因修复鉴权、协议或参数；短文本成功后再验证读取文件、修改与测试，不把它写成全部 Agent 功能通过。
全球顶尖大模型 · 一站式接入
先定位失败阶段按看到的错误，选择下一步
AI_APICallError
继续展开：状态码、responseBody、请求路径、provider/model
ProviderInitError 则先检查配置或依赖加载- 请求尚未发出：先看 ProviderInitError、配置语法与包加载，不重充值。官方建议从日志定位，macOS/Linux 日志目录为 ~/.local/share/opencode/log/。
- 收到 401 / 403：检查该平台的 Key、启动环境与模型授权。凭据可能在 ~/.local/share/opencode/auth.json，但不要把整个文件复制给别人。
- 收到 400 / 404：核对准确型号、最终路径、参数及协议。Chat Completions 使用 @ai-sdk/openai-compatible；Responses 使用 @ai-sdk/openai，并按目标型号的支持配置。
- 最小文本成功，工具任务失败：查工具调用格式、模型能力、权限和上下文；若已有文件变更先检查 diff，不直接重跑整个任务。
先区分配置、响应与重试
配置与检查示例
本站绘制的内容说明图：对照本页「AI_APICallError」与配置要点；图中均为正文示例，不含有效 Key，也不是修复成功截图。
本站绘制的内容说明图：只对应本页错误的现象、检查与恢复条件；复测需要保留原客户端、时间、模型和脱敏响应，未执行项目不标成功。
先按顺序处理
- 记录 opencode --version、时间、错误全文和目标 provider/model；先备份当前配置。
- 将最小 provider 定义合并到实际生效的 opencode.json / opencode.jsonc，Key 用环境变量，不覆盖全部配置。
- 先选一个当前分组授权且支持目标协议的准确 ID；用短文本验证响应，再添加所需工具与流式能力。
- 只有日志指向 provider 包问题时再处理缓存；先退出应用并备份，避免把会话/凭据目录误当缓存删除。
三处名称要对得上
示例的 provider ID 为 apizt，模型定义放在 provider.apizt.models 里，运行时使用 apizt/准确模型ID。name 是显示名称，不能替代 API 模型 ID。不要机械沿用另一个平台的型号前缀。
检查配置来源，再动凭据
全局和项目配置会合并，OPENCODE_CONFIG 可指定文件，环境变量也会参与解析。先在你实际启动 OpenCode 的环境中检查，不打印 Key。/connect 所用 provider ID 也要与定义一致。
把包故障与 HTTP 故障分开
官方故障文档提示过期 provider 包可能导致 API 调用错误。先核对当前版本及正确 npm 包；确实是包缓存问题时，退出并按官方方法重建 ~/.cache/opencode。不要删除保存认证和会话的 ~/.local/share/opencode。
固定一个能验收的工具任务
在独立测试仓库放一个失败用例，先运行测试保存失败结果。要求 OpenCode 读文件、只修改实现、保持测试不变并再次运行测试。检查会话中的工具事件、最终 diff 与独立复跑结果，不接受仅贴出代码的回答。
配置与检查示例
先备份并合并到对应配置，不覆盖原文件。真实 Key 留在本地；型号 ID 与协议从当前目录核对。
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"apizt": {
"npm": "@ai-sdk/openai-compatible",
"name": "apizt",
"options": {
"baseURL": "https://api.apizt.com/v1",
"apiKey": "{env:tokenba_API_KEY}"
},
"models": {
"REPLACE_WITH_SUPPORTED_MODEL_ID": {
"name": "当前分组支持的模型"
}
}
}
}
}怎样才算修好了
- 配置加载与模型选择通过；provider/model 与接口一致。可以先用配置生成器核对字段，不发送模型请求。
- 自行运行 opencode run --model apizt/准确模型ID --format json "只回复 OK"，检查有效文本。这是可能收费的真实请求，本页未代执行。
- 在测试仓库运行固定失败测试，要求只修改实现并调用测试工具。保留会话 JSON 事件、文件变更、工具退出状态和请求 ID。
- 独立复跑原测试，并用 git diff 检查没有改测试、删失败用例或无关文件。出现权限询问时只授权完成此测试任务需要的操作。
- 将所有请求的 usage 与控制台账单匹配。匹配前费用留空；终端的 token 估算、模拟响应与其他客户端的记录不能冒充实扣。
资料核对：2026-10-07。官方 OpenCode 文档区分 Chat Completions 与 Responses 的 provider 包，并说明配置合并、环境变量与日志入口。本机 OpenCode 版本 1.2.15；这里只核对版本、命令与离线故障，未执行真实网关工具任务。本站 GLM 单函数 API 示例是另一种调用方式，不能当作 OpenCode 客户端实测。
常见问题
OpenCode AI_APICallError 是 Key 错误吗？
不一定。它可包装鉴权、参数、路径、限流或上游错误。记录底层状态码与 responseBody；若是 ProviderInitError，先检查配置和依赖加载，而不是反复换 Key。
OpenCode AI_APICallError 需要删除缓存吗？
仅当日志指向 Provider 包加载或版本兼容问题时，才按官方流程处理对应缓存。先备份配置，保留认证和会话数据；网络或接口错误不会因为清空全部数据自动修复。
AI_APICallError 就是 Key 错了吗？
不是。它可能包装认证、请求参数、路径、限流或 provider 包问题。先读底层状态码和 responseBody。
Chat 成功为什么 Agent 失败？
Agent 还依赖工具格式、流式、权限和多回合上下文。必须在原模式完成文件修改及测试才能确认兼容。
一定要删除缓存吗？
不需要。先查日志；仅包加载或参数兼容问题指向过期 provider 包时，才按官方缓存处理流程重建。保留认证和会话数据。
本站 GLM 测试证明 OpenCode 可用吗？
不能。那是单函数 API 示例，客户端、工具执行和费用范围不同。本页提供 OpenCode 验收步骤，尚无本轮真实客户端工具任务记录。
相关步骤与官方依据
OpenCode 真正的通过条件：事件、文件与测试都要看
2026-10-07，本机 OpenCode 1.2.15 在隔离目录连接本地合成 401 端点，实际发出了 /v1/chat/completions 流式请求，并输出 APIError 事件；进程退出码却为 0。因此仅检查退出码不够。此记录没有真实模型、文件修改或实扣费用。
- 验收阶段
- 模型请求
- 要保留的证据
- 准确 provider/model、最终路径、状态码
- 通过条件
- 返回有效内容，日志对应同一次请求
- 验收阶段
- 客户端事件
- 要保留的证据
- --format json 输出及错误事件
- 通过条件
- 没有未处理的 error，不仅是进程退出 0
- 验收阶段
- 工具操作
- 要保留的证据
- 文件读取、修改、测试的工具记录与权限
- 通过条件
- 真的执行需要的操作，不只给出建议代码
- 验收阶段
- 结果检查
- 要保留的证据
- 独立复跑测试、git diff
- 通过条件
- 原测试通过，测试和无关文件没有被篡改
- 验收阶段
- 完整任务成本
- 要保留的证据
- 所有调用、缓存、重试、usage 与实际账单
- 通过条件
- 匹配后再填实扣；未匹配留空
按固定失败测试验证自己的 OpenCode
- 使用独立测试仓库与已备份的配置。先跑原测试确认失败，记下客户端版本、仓库 commit 和目标型号。
- 使用下方命令要求读取、修改实现并运行测试；自行按任务授权必要操作。该命令是在线验收步骤，可能产生 API 费用。
- 检查 JSON 错误和工具事件，再独立复跑原测试和查看 diff。本站单函数 API 示例只提供任务材料，不能代替这个客户端流程。
核验日期与验证范围见各页记录；历史实测保留原日期，示例和空白记录表不等于真实任务结果。