Cline 的 SDK 在 v0.0.95 里做了一批适配，核心是让 OpenAI 兼容请求能正确对接 GPT-6 系列模型。其中最有信息量的一条改动是：GPT-6 系列的请求把 max_tokens 换成了 max_completion_tokens。这看起来是个字段名的小变化，背后却是新一代模型 API 的一个信号，值得单独说清楚。
本次适配的内容
release 说明里最关键的一句话是：针对 GPT-6 模型（gpt-6-sol、gpt-6.1-sol、gpt-6-1-sol，以及后续 gpt-5 到 gpt-9 的 id）发 OpenAI 兼容请求时，发送 max_completion_tokens 而不是 max_tokens，这样 OpenAI 和 Azure 就不会再拒绝这些请求。而 Azure 的 gpt-35-turbo 仍然保留 max_tokens。
换句话说，新老模型对「限制输出长度」这个参数的字段名要求不同：GPT-6 系列认 max_completion_tokens，老模型认 max_tokens。如果一个工具还是无脑发 max_tokens，遇到 GPT-6 就会被打回。
两种参数的分工
max_tokens 是 OpenAI 最早用的字段，控制「生成的最大 token 数」。max_completion_tokens 是新一批模型的替代字段，语义基本一致，都是限制补全的输出长度，但新模型只认后者。对开发者来说，这事迁移成本不高，但要写对：
| 模型 | 用哪个字段 |
|---|---|
| gpt-6-sol / gpt-6.1-sol / gpt-6-1-sol | max_completion_tokens |
| gpt-5 到 gpt-9 后续 id | max_completion_tokens |
| Azure gpt-35-turbo | max_tokens（保留） |
| 老一批 GPT 模型 | max_tokens |
自己封装请求时，最稳的做法是让参数名跟着模型走：
# 根据模型族选择输出长度字段
def output_limit_field(model_id: str) -> str:
if model_id.startswith("gpt-6") or model_id.startswith("gpt-5"):
return "max_completion_tokens"
return "max_tokens"
模型目录的连锁调整
除了这个字段，这次更新还刷新了模型目录（6,952 → 7,041 个模型），新增了 CommandCode 和 Reflection 两个 provider。默认模型也动了：Cline 推荐列表重新以 Claude Sonnet 5.5 打头，所以 cline provider 内置的默认模型从 Gemini 4 Argon 切回了 Claude Sonnet 5.5。另外一批 provider 的默认模型跟着变——302.AI 用 Gemini 4 Argon、CoreWeave 用 Reflection Beam 1.0、Pioneer 用 Nemotron 3.5 Super VL、Scaleway 用 DeepSeek V4.1 Flash。
还有两条偏工程的改动：hub daemon 现在会记录是谁启动的它（CLINE_HUB_LAUNCHER_CLIENT / VERSION / TRANSPORT），作为 OTel 资源属性发布，SSH 远程 hub 会把本地客户端以 transport=ssh 上报；遥测自检报告里多了 traces_exporter 一项。这些对普通使用者不可见，对排障和可观测性有用。
选型建议
对「要不要为了 GPT-6 迁这个字段」这个具体问题，答案很直接：如果你在 Cline 这类工具里用，工具已经替你适配好了，不用自己动手；如果你自己写 OpenAI 兼容客户端对接 GPT-6，记得把输出长度字段换成 max_completion_tokens，否则请求会被拒。迁移成本几乎为零，但不改就是硬伤。
更值得记的是这个信号本身：随着 gpt-6、gpt-5 到 gpt-9 的 id 铺开，max_tokens 在 OpenAI 生态里正在被逐步弃用。做多模型兼容层的团队，应该把「输出长度字段按模型族路由」当成一个常规处理，而不是临时的 if。
不适合谁
这次更新本身没有「不适合」的选型判断可下——它是一次适配性发布，不是能力新增。真正要提醒的是：别把「工具支持 GPT-6」误读成「GPT-6 已经全面开放」。release 只是把请求格式对齐了，模型能不能用、怎么计费，还是 OpenAI 那边的事。对追新模型的人，盯着 gpt-6 系列的开放状态，比盯着工具版本更实在。