1. 自定义 provider 接入后推理程度为什么总是不受控很多人第一次在 open code 里接自定义 provider注意力都放在“能不能连上”这件事上Base URL 填对、Key 填对、模型名填对发一条请求能出字就觉得大功告成。真正用起来才发现另一个问题——模型要么话太多要么想太浅。写个正则表达式它给你输出三段推理过程问个简单概念它又一句话带过完全不受你控制。这个现象在本地/自建模型服务场景里尤其明显。因为官方托管的模型往往在服务端就帮你把推理预算调好了而自定义 provider 把这份控制权交回给了你。open code 作为客户端本身不会替你做“这个任务该想多深”的判断它只负责把请求发出去。于是推理程度也就是大家常说的思考程度、reasoning effort到底给多少取决于你在opencode.json里怎么声明。我试过在同一个自建服务上跑两类任务一类是补全一个 TypeScript 类型定义另一类是让它分析一段有并发 bug 的代码。如果都用默认配置前者会浪费大量 token 在无意义的推理上后者又可能因为推理预算不足而漏掉关键路径。解决办法不是换模型而是在 open code 里给同一个模型挂上不同档位的 variant用快捷键或斜杠命令切换。这篇内容就围绕opencode.json展开讲清楚三件事自定义 provider 的模型怎么声明推理档位、配置改完怎么验证生效、以及不同任务怎么匹配不同思考深度。全程给可复制的配置片段和验证动作你跟着改完重启就能对比输出长度和耗时的变化。需要先说明一个前提推理程度这个参数能不能真正生效取决于你的自定义 provider 背后的服务是否支持对应的字段。open code 负责把reasoningEffort这类参数透传出去服务端认不认是另一回事。所以下面的验证步骤里我会让你同时观察输出长度和耗时用这两个指标反推参数有没有被消费。2. TaoToken 前置把自定义 provider 的 Base URL 和 Key 准备好在动opencode.json之前得先有一个能用的 provider 端点。如果你用的是自建服务Base URL 通常是你本机的地址加端口比如http://127.0.0.1:8000/v1这种形式。如果你希望走一个统一的网关来管理多个模型、统一计费和鉴权可以用 TaoToken 的 API 端点作为 provider 的 Base URL。TaoToken 的 API 地址是https://taotoken.net/api注意这个地址后面不加任何查询参数。在 open code 的 provider 配置里你需要填的是这个 Base URL 加上你的 API Key。Key 的获取入口在控制台的 API Keys 页面登录后新建一个即可。模型对话的入口可以用来先手动验证某个模型能不能正常出字确认链路通了再写进配置文件。这里要强调一个容易踩的坑open code 的 provider 配置里Base URL 的写法和你直接 curl 时不完全一样。有些 provider 需要你在 URL 末尾带上/v1有些则不需要取决于它内部的路径拼接逻辑。TaoToken 的 API 端点https://taotoken.net/api是标准写法open code 会在此基础上拼接具体的模型路径。如果你填成https://taotoken.net/api/v1可能会出现路径重复导致 404。另外自定义 provider 的模型 ID 必须和你服务端注册的模型名完全一致大小写敏感。比如服务端注册的是my-local-qwen你在配置里写成My-Local-Qwen就会报模型不存在。这个错误在 open code 里通常表现为请求发出后返回一个明确的错误信息而不是静默失败所以排查起来不算难。准备好这两样东西——Base URL 和 API Key——就可以进入下一步写配置了。如果你还没有 Key先去控制台建一个如果你已经有自建服务的地址直接用它也行。下面的配置示例里我会用占位符你替换成自己的实际值即可。3. 可复制的 opencode.json 配置给模型挂上 reasoningEffort 档位open code 的配置文件位置在 Windows 上是C:\Users\你的用户名\.config\opencode\opencode.json在 macOS 和 Linux 上通常是~/.config/opencode/opencode.json。如果这个文件不存在手动创建一个即可。配置的核心结构是provider下面挂各个 provider每个 provider 下面挂models每个模型可以带一个variants字段。下面是一个完整的可复制片段你可以直接改掉 Base URL、Key 和模型名后使用{ provider: { taotoken: { npm: ai-sdk/openai-compatible, options: { baseURL: https://taotoken.net/api, apiKey: sk-你的实际Key }, models: { my-reasoning-model: { name: my-reasoning-model, variants: { low: { reasoningEffort: low }, medium: { reasoningEffort: medium }, high: { reasoningEffort: high }, max: { reasoningEffort: max } } } } } } }这段配置做了几件事。npm字段声明用 OpenAI 兼容协议来对接这对大多数自建服务和网关都适用。options里的baseURL和apiKey是连接信息。models下面定义了一个模型my-reasoning-model它的variants里有四个档位每个档位对应一个reasoningEffort值。这里的关键点是variants是挂在模型级别的不是 provider 级别。也就是说同一个 provider 下的不同模型可以有完全不同的档位定义。比如你有一个快速补全模型和一个深度推理模型前者可能只需要low和medium后者才需要high和max。配置写完后保存文件然后重启 open code。重启这一步不能省因为 open code 在启动时读取配置运行中修改文件不会热加载。重启后你可以用快捷键Ctrl T来切换当前模型的 variant或者输入/variants命令来查看和选择。如果这两个操作都没反应说明配置没有生效需要回到文件检查 JSON 语法是否正确。一个常见的 JSON 语法错误是尾随逗号。比如max: { reasoningEffort: max },后面如果还有内容这个逗号是合法的但如果它是最后一个字段逗号就会导致解析失败。open code 在配置解析失败时通常不会给出很详细的提示所以建议改完后用编辑器的 JSON 校验功能先过一遍。另外reasoningEffort的取值不是所有服务端都支持max这个档位。有些服务只认low、medium、high三档你写max它可能会忽略或者报错。这种情况下你可以把max映射成high或者干脆去掉这一档。验证方法在下一节。4. 验证请求改配置、重启、发测试请求对比输出配置改完重启后怎么确认reasoningEffort真的生效了最直接的办法是发一条测试请求对比不同档位下的输出长度和耗时。这里给一个可复现的验证流程。先准备一条测试 prompt要求它做一件需要一定推理但又不至于太复杂的事比如“用 TypeScript 写一个函数判断一个字符串是否是合法的 IPv4 地址要求处理边界情况。”这条 prompt 的好处是推理程度低的时候模型可能直接给一个简单正则推理程度高的时候它会考虑前导零、段数、数值范围等边界。然后按以下步骤操作第一步用Ctrl T或/variants把当前 variant 切到low发送这条 prompt记录输出字符数和从发送到完成的时间。你可以用秒表粗略计时或者看 open code 界面上的耗时显示。第二步切到high发送同样的 prompt再次记录输出字符数和耗时。第三步切到max如果你的服务端支持重复一次。如果配置生效你应该能观察到low档位的输出明显更短、更快可能只给了一个基础正则high和max档位的输出更长会包含边界处理的说明耗时也相应增加。如果三个档位的输出完全一样长度和耗时都没有变化那说明reasoningEffort没有被服务端消费。这种情况下先检查你的服务端是否支持这个参数。有些自建推理服务用的是自己的参数名比如thinking_budget或reasoning_tokens而不是reasoningEffort。open code 透传的是reasoningEffort如果服务端不认它可能会忽略这个字段导致所有档位行为一致。另一个验证角度是看请求日志。如果你能访问 provider 服务端的日志可以直接搜索请求体里有没有reasoningEffort字段以及它的值是什么。这是最确定的验证方式比看输出长度更可靠。如果服务端确实不支持reasoningEffort但你用的网关支持参数映射可以在网关层做一层转换把reasoningEffort映射成服务端认识的参数。TaoToken 的接入文档里有关于参数透传和映射的说明可以参考。这种情况下open code 侧的配置不用改改的是网关侧的规则。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth配置自定义 provider 时报错信息往往比较隐晦。下面列几个高频错误和对应的排查方向。401 Unauthorized这个最直接Key 不对或者没带上。检查opencode.json里apiKey字段的值确认没有多余空格确认 Key 没有过期或被撤销。如果你用的是 TaoToken去控制台的 API Keys 页面确认这个 Key 的状态是启用。另外注意有些 provider 要求 Key 以Bearer前缀传递open code 的 OpenAI 兼容模式通常会自动加但如果你用的是自定义 npm 包可能需要手动在options里加headers。local proxy failed这个错误通常出现在你配置了本地代理或者网关地址但 open code 连不上那个地址。检查baseURL是否可达用curl或浏览器访问一下。如果是本机服务确认端口没有被防火墙拦截确认服务进程在运行。如果是远程网关确认网络连通性。这个错误和推理程度无关是连接层的问题。reading choices 相关报错这类错误通常意味着服务端返回的响应结构不符合 OpenAI 兼容格式。open code 期望响应里有choices数组如果服务端返回的是自定义结构就会解析失败。解决办法是在 provider 配置里指定正确的响应解析方式或者用网关做一层格式转换。如果你用的是自建服务检查它的 API 是否真的兼容 OpenAI 的/v1/chat/completions格式。OAuth 相关报错如果你配置的 provider 需要 OAuth 而不是 API Keyopen code 的apiKey字段就不适用了。这种情况下需要走 OAuth 流程通常涉及在浏览器里授权然后回调。open code 对 OAuth 的支持取决于你用的 npm 包和 provider 类型。如果你只是想用 API Key 方式接入确认你的 provider 支持这种鉴权方式。排查时的一个通用技巧把 open code 的日志级别调高或者在启动时加--verbose之类的参数取决于版本这样能看到完整的请求和响应。很多错误在详细日志里一目了然。另外如果你在配置里同时写了variants和模型级别的其他参数注意 JSON 的层级不要写错。variants是models下面某个模型的字段不是provider的字段也不是options的字段。写错层级会导致配置被忽略但不报错表现为切换 variant 没反应。6. 按任务匹配思考深度把 variant 用成日常习惯配置生效之后真正的价值在于把不同 variant 用在不同任务上。我的习惯是代码补全、格式化、简单重命名这类任务用low让它快速出结果不要浪费推理预算代码审查、bug 分析、架构讨论用high或max让它把边界情况想清楚。切换方式就是Ctrl T循环切换或者/variants选择。你可以在 open code 里为不同项目设置不同的默认 variant这样打开项目时就自动匹配。具体做法是在项目根目录放一个.opencode配置或者在工作区设置里指定取决于你的 open code 版本。如果你希望把多个模型统一管理并且在不同项目间共享 provider 配置用 TaoToken 的 API 端点作为 Base URL 会比较省事。Key 在控制台统一管理模型对话入口可以快速验证某个模型在当前档位下的表现。长期做编码和 Agent 任务的话Coding Plan 提供了更稳定的调用额度适合把 variant 切换变成日常操作。最后给一个实用技巧在切换 variant 后不要只看输出长度还要看输出质量。有时候low档位虽然短但恰好给出了你需要的答案high档位虽然长但可能绕了弯路。推理程度高不等于结果一定好关键是匹配任务。你可以为常用任务建一个简单的对照表记录哪个 variant 在哪个任务上表现最好用几次就有感觉了。