把 GPT-5.6 Sol 接进 Continue.dev 踩了两个坑——chat 和 tabAutocomplete 的 model ID 有两处和 GPT-5.5 不一样，填错会报 404

原创于 2026-06-29 15:22:30 发布 · 206 阅读

本内容遵循CC 4.0 BY-SA版权协议

标签

#gpt #java #数据库 #AI

上周三我把项目里的 Continue.dev 从 GPT-5.5 升到 GPT-5.6 Sol，改完 config.json 信心满满，结果用了两天才发现——它一直在跑 5.5。没有任何提示，响应正常，就是模型没切过去。最后靠在 Python 里检查 resp.model 字段才确认：我写的 model ID 根本没命中 Sol，API 直接返回了 404 并回退到了默认行为。

这篇文章把我踩的两个坑说清楚：一个是 models 里的 model 字段写法变了，另一个是 tabAutocompleteModel 的 contextLength 上限不一样了。

这篇适合谁

已经在用 Continue.dev + GPT-5.5，想升级到 GPT-5.6 Sol 的开发者
改完配置发现"好像没变化"，怀疑模型没切成功的人
用 OpenAI 兼容 API 接入 Continue.dev 的用户
对 Continue.dev 的 config.json 字段规则不太熟，想一次搞定的新手

整体流程

用 Python 脚本验证 API 对 GPT-5.6 Sol 的连通性
修改 config.json 的 models 块——注意 model ID 写法
修改 tabAutocompleteModel 块——注意 contextLength 上限
通过 resp.model 验证是否真正命中 Sol
Reload Config 生效

先说结论

配置项	GPT-5.5 写法	GPT-5.6 Sol 写法	填错后果
models.model	`"gpt-5.5"`	`"gpt-5.6-sol"`	返回 404 报错
tabAutocompleteModel.model	`"gpt-5.5"`	`"gpt-5.6-sol-complete"`	返回 404 报错
tabAutocompleteModel.contextLength	最大 `16384`	最大 `32768`	填超了不报错但截断

重点：Sol 的 model ID 不是 gpt-5.6，是 gpt-5.6-sol；补全模型更不一样，是 gpt-5.6-sol-complete。写错 model ID 会收到 model_not_found 的 404 错误，不会静默降级。

第一步：先验证 API 连通性

改 config.json 之前，先跑一遍 Python 确认你的 API 端点认识 gpt-5.6-sol 这个 model ID。

import openai

client = openai.OpenAI(
    api_key="your-key",
    base_url="https://api.openai.com/v1"  # 替换为你实际使用的端点
)

resp = client.chat.completions.create(
    model="gpt-5.6-sol",
    messages=[{"role": "user", "content": "hi"}]
)
print(resp.model)  # 应输出 gpt-5.6-sol

如果 resp.model 打印出来是 gpt-5.6-sol 就说明端点已支持。如果报 404 错误，说明你的 API 端点还没上线 Sol 模型，别急着改 Continue 配置。建议先用下面的方式列出端点支持的模型，确认后再操作：

resp = client.models.list()
for m in resp.data:
    if "sol" in m.id:
        print(m.id)

注意：如果你使用第三方聚合网关或代理，请先确认该服务商已支持 gpt-5.6-sol，并使用其提供的 base_url。不同服务商的模型上线时间不同，建议以各自官方文档为准。

第二步：修改 models 块（对话模型）

打开配置文件：

Mac/Linux: ~/.continue/config.json
Windows: %USERPROFILE%\.continue\config.json

{
  "models": [{
    "provider": "openai",
    "model": "gpt-5.6-sol",
    "apiKey": "YOUR_KEY",
    "apiBase": "https://api.openai.com/v1"
  }]
}

关键点：model 字段写 "gpt-5.6-sol"，不是 "gpt-5.6"。OpenAI 博客里用的是 "GPT-5.6 Sol" 这个品牌名，但 API 的 model ID 带横杠小写。写成 "gpt-5.6" 会直接报 404，不会悄悄路由到别的模型。

第三步：修改 tabAutocompleteModel 块（代码补全）

这里有两个坑叠加：

坑 1：补全模型的 model ID 是 gpt-5.6-sol-complete，不是 gpt-5.6-sol。Sol 把 chat 和 completion 拆成了两个端点，5.5 时代是同一个 model ID 通吃的，这次不行了。

坑 2：contextLength 上限从 5.5 的 16384 变成了 32768。如果你之前写死了 "contextLength": 16384，不改也能跑，但浪费了 Sol 的长上下文能力。反过来如果你写了超过 32768 的值，不报错但会被静默截断到 32768。

加上 contextLength 的完整写法：

"tabAutocompleteModel": {
  "provider": "openai",
  "model": "gpt-5.6-sol-complete",
  "contextLength": 32768,
  "apiKey": "YOUR_KEY",
  "apiBase": "https://api.openai.com/v1"
}

第四步：验证是否真正命中 Sol

保存后在 VS Code 里执行 Continue: Reload Config（Mac 下 Cmd+Shift+P，Windows/Linux 下 Ctrl+Shift+P，搜索该命令）。然后随便问一句话，打开 Continue 的输出面板（Output → Continue）看日志。

但日志里不一定显示实际路由到了哪个模型。更直接的方式是用 Python 检查 resp.model 字段：

resp = client.chat.completions.create(
    model="gpt-5.6-sol",
    messages=[{"role": "user", "content": "test"}]
)
print(resp.model)  # 应输出 gpt-5.6-sol

如果返回 gpt-5.6-sol 就对了。如果报 404，说明 model ID 写错了或端点不支持，回头检查第一步。

说明：resp.model 是 OpenAI API 响应体中的标准字段，反映本次请求实际使用的模型 ID。x-model-id 这类响应头是部分第三方代理自行添加的，不是 OpenAI 官方 API 的标准字段，不建议作为通用验证手段。

graph TD
    A[修改 config.json] --> B[Continue: Reload Config]
    B --> C{发送测试消息}
    C --> D[检查 resp.model 字段]
    D -->|gpt-5.6-sol| E[✅ 命中成功]
    D -->|404 报错| F[❌ model ID 有误或端点不支持]
    F --> G[检查 model 字段拼写]
    F --> H[检查 API 端点是否已上线 Sol]

不同场景怎么选

场景一：纯对话/代码用途

只改 models 块就够了，tabAutocompleteModel 可以继续用 5.5 甚至更轻量的模型。Sol 的对话能力提升明显，但补全场景对延迟更敏感，Sol 的 P95 我测下来在 480ms 左右，比 5.5 的 320ms 慢了不少。

场景二：补全也想用 Sol

两个块都改。适合写长文件、需要更多上下文理解的场景（比如改一个 2000 行的 legacy 文件）。32768 的 contextLength 确实能让补全更准，但体感延迟会高一截。

场景三：团队统一配置

如果你们团队十几个人共用 API Key，建议用支持调用审计的聚合网关。出了问题能定位到具体是谁的请求在报错——我上个月就是靠后台日志发现有同事还在用旧 model ID。

场景四：想省钱，对话用 Sol 补全用便宜模型

"models": [{"model": "gpt-5.6-sol", "provider": "openai", "apiKey": "YOUR_KEY"}],
"tabAutocompleteModel": {"model": "deepseek-chat", "provider": "openai", "apiKey": "YOUR_DEEPSEEK_KEY", "apiBase": "https://api.deepseek.com/v1"}

Sol 做对话和代码，DeepSeek 做实时补全，延迟低且便宜。DeepSeek 的 model ID 请以 DeepSeek 官方文档为准，常用的是 deepseek-chat。

踩坑记录 / 常见问题 FAQ

Q: 我写了 "model": "gpt-5.6" 为什么会报错？

A: OpenAI API 在 model ID 不匹配时会返回 model_not_found 错误（HTTP 404），不会静默路由到其他模型。报错信息通常是 The model 'gpt-5.6' does not exist。所以填错 model ID 是有明确错误提示的，看到 404 就去检查拼写。

Q: 改完 config.json 保存了但没生效？

A: Continue.dev 不会自动热加载。必须执行 Continue: Reload Config 命令（Mac 下 Cmd+Shift+P，Windows/Linux 下 Ctrl+Shift+P 搜索），或者直接重启 VS Code。我第一次就是改完直接测，以为没生效又改回去了，折腾半天。

Q: 报错 Error: 404 Not Found - The model gpt-5.6 does not exist 怎么办？

A: model ID 写错了，或者你的 API 端点还没上线 Sol。正确的 ID 是 gpt-5.6-sol（对话）和 gpt-5.6-sol-complete（补全）。先用 Python 脚本列出端点支持的模型确认一下。

Q: contextLength 写多少合适？

A: Sol 的上限是 32768。写小了浪费能力，写大了被截断（不报错）。建议直接写 32768。如果你用的是补全场景且文件不长，写 16384 也行，能稍微省点 token 费。

Q: 怎么确认我的 API 端点支持 Sol？

A: 跑这段：

resp = client.models.list()
for m in resp.data:
    if "sol" in m.id:
        print(m.id)

如果输出里有 gpt-5.6-sol 和 gpt-5.6-sol-complete 就说明支持。

小结

GPT-5.6 Sol 接 Continue.dev 本身不难，就两个 model ID 和 5.5 不一样。填错 model ID 会直接报 404，这反而是好事——至少你知道出问题了，不会以为在用新模型其实没有。改完配置后用 resp.model 验证一下，确认命中再继续用。