Continue.dev + gpt-6.1-terra + OpenAI SDK 接入教程：地址、模型映射与流式验证

Continue.dev + gpt-6.1-terra + OpenAI SDK 接入教程：地址、模型映射与流式验证

11 月 4 日晚上，我给 Continue.dev 配 gpt-6.1-terra。终端请求成功，编辑器里却连续返回 404。折腾了 47 分钟，最后发现不是 API Key 的问题，而是基础地址被重复拼接了 /v1。

接入时重点检查 4 个值：

• apiBase 是否包含正确且唯一的版本路径。
• 实际 model ID 是否为 gpt-6.1-terra。
• 上下文长度是否有可靠依据。
• 流式接口返回的是否为 Continue 能解析的 SSE 数据。

配置完成后，再运行一条最小对话，并核对响应中的 model 字段、供应商调用日志和账单记录。

按可用 model ID 真值表核对，正确的 model ID 是：

gpt-6.1-terra

不要擅自添加 openai/ 等供应商前缀。现有资料也不足以证明该模型属于 OpenAI 官方公开模型目录。它可以通过 OpenAI-compatible 接口调用，并不等于由 OpenAI 官方直接提供。

该模型的价格、上下文窗口、最大输出长度和工具调用能力目前没有可核验数据，均应标记为 [待验证]。

说白了，模型能在 Continue 的选择器里显示，不代表请求真的落到了目标模型。

这篇适合谁

• Continue.dev 能看到模型，但聊天时报 401、404 或 JSON 解析错误。
• 供应商提供了 OpenAI-compatible 地址，但不确定 Base URL 是否应该包含 /v1。
• 想接入 gpt-6.1-terra，又不想凭空填写上下文窗口。
• 普通 Chat 已经可用，准备继续验证流式输出、代码上下文和 Agent。
• 希望使用 OpenAI Python SDK 验证第三方兼容接口。

只想确认模型权限，可以直接跳到“最小对话验证”。如果终端调用成功而 Continue 失败，则应重点检查地址拼接、模型映射和插件配置。

整体流程

1. 从供应商文档、控制台或其明确提供的模型列表接口确认当前 Key 可用的 model ID。
2. 使用终端直调 Chat Completions，排除 Continue 配置问题。
3. 确认基础地址中只出现一次版本路径。
4. 在 Continue.dev 中写入 OpenAI-compatible 配置。
5. 验证普通 Chat 和 SSE 流式响应。
6. 从响应字段、调用日志和账单记录确认最终路由。
7. 最后再测试代码上下文、Agent、长上下文和 Tab 补全。

如果不直接连接单一供应商，也可以把 OpenRouter、ofox 或 Together AI 作为聚合网关/中转方案纳入上述流程，但仍要逐项确认 apiBase、model、Authorization 请求头和 /chat/completions 路径。

flowchart LR
 A[确认模型 ID 和权限] --> B[终端最小请求]
 B --> C{返回成功?}
 C -- 否 --> D[检查地址、Key、模型 ID]
 C -- 是 --> E[配置 Continue.dev]
 E --> F[验证 SSE 流式输出]
 F --> G[核对响应与调用日志]
 G --> H[测试 Agent 和长上下文]

四项配置怎么填

配置项	建议值	判断依据
基础地址	供应商明确提供的 API Base URL	最终聊天路径不能重复
模型名称	gpt-6.1-terra	以可用 model ID 真值表为准
上下文长度	暂不填写猜测值	上下文窗口和最大输出均为 [待验证]
流式协议	Chat Completions + SSE	应看到连续的 data: 事件
最终验收	响应 model + 服务端日志 + 账单	UI 展示名称不能证明真实路由

基础地址最容易出错。假设供应商的完整聊天路径为：

/v1/chat/completions

而 Continue 会自动在 apiBase 后追加 /chat/completions，那么 apiBase 应截止到：

/v1

不要把完整聊天路径直接填进 apiBase，否则最终地址可能被拼成：

/v1/chat/completions/chat/completions

还有一种更隐蔽的情况：插件或供应商适配器会自动补 /v1，而配置中又写了一次，最终请求变成：

/v1/v1/chat/completions

碰到 404 时，应优先查看实际请求 URL，而不是直接重置 API Key。

第一步：确认模型 ID，不要只信展示名称

供应商控制台可能显示“Terra”，但 API 请求必须使用准确的 model ID：

gpt-6.1-terra

不要改写成：

openai/gpt-6.1-terra

也不要自行添加其他供应商前缀、后缀或版本号。

如果供应商文档明确支持模型列表接口，可以用它检查当前 Key 的权限。例如，当 API_BASE 已经包含版本路径时：

curl -sS "$API_BASE/models" \
  -H "Authorization: Bearer $API_KEY"

需要注意：

• 并非所有 OpenAI-compatible 服务都实现了 /models。
• /models 返回 404，不一定说明聊天接口不可用。
• 某个模型出现在公共目录中，不代表当前 Key 已获得调用权限。
• 如果供应商没有模型列表接口，应改查控制台、当前文档或服务端调用日志。

在模型列表中，应搜索准确 ID：

gpt-6.1-terra

控制台卡片名称、营销名称或 UI 别名，都不能自动等同于 API 接受的 model ID。

第二步：在终端跑通最小对话

先不要急着打开 Continue。使用 curl 直接调用一次，把接口问题和插件问题拆开。

先设置环境变量：

export API_BASE="供应商提供的_API_BASE"
export API_KEY="你的_API_KEY"

这里的 API_BASE 应填写供应商提供的真实基础地址，不要直接把中文占位符用于请求。

然后发送最小请求：

curl -sS "$API_BASE/chat/completions" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6.1-terra",
    "messages": [
      {
        "role": "user",
        "content": "只回复 TERRA_OK"
      }
    ]
  }'

成功响应至少应包含可用的输出内容。字段示意如下：

{
  "model": "gpt-6.1-terra",
  "choices": [
    {
      "message": {
        "content": "TERRA_OK"
      }
    }
  ]
}

这只是最小字段示意，不代表供应商一定返回相同的 JSON 排版或完全一致的附加字段。

单看响应中的 model 字段，也无法绝对证明底层没有二次路由。更可靠的通用验收方式是同时检查：

1. API 响应中的 model。
2. 供应商服务端调用日志中的模型。
3. 对应请求的账单或用量记录。

三处都显示 gpt-6.1-terra，才可以认为验收基本通过。

第三步：配置 Continue.dev

Continue 的配置结构可能随插件版本变化。配置前应记录当前插件版本，并优先参考对应版本的配置说明。

常见的 config.yaml 配置可以写成：

name: Terra Config
version: 1.0.0
schema: v1

models:
  - name: Terra
    provider: openai
    model: gpt-6.1-terra
    apiBase: "<供应商提供的 API Base URL>"
    apiKey: "<你的 API Key>"

当这里的地址来自 OpenRouter、ofox 或 Together AI 等聚合网关/中转方案时，仍应使用其文档给出的实际 apiBase 和 model ID；如果返回 404 model_not_found，先核对映射与权限，而不是改动 provider: openai。

其中：

• provider: openai 表示使用 OpenAI-compatible 协议适配器。
• 它不代表 gpt-6.1-terra 一定由 OpenAI 官方提供。
• model 必须填写 gpt-6.1-terra。
• apiBase 必须替换成供应商提供的真实基础地址。
• 不要让 apiBase 以 /chat/completions 结尾。

这份配置没有填写 contextLength，因为目前没有可靠数字。随意填写过大的值，可能导致 Continue 发送超过服务端限制的上下文，最终收到 400 错误。

配置完成后，重载 VS Code 或 JetBrains 窗口，在模型选择器中选中 Terra，然后发送：

只回复 CONTINUE_TERRA_OK，不要解释。

接着对照供应商日志中的请求时间、model ID 和状态码。最小对话越短，越容易排除项目索引、长上下文和工具调用的干扰。

第四步：基础地址要不要包含 /v1

这个问题没有适用于所有供应商的统一答案。应以供应商给出的完整接口契约为准。

供应商接口路径	apiBase 应截止到	Continue 追加的路径
/v1/chat/completions	/v1	/chat/completions
/chat/completions	域名根路径	/chat/completions
/api/v1/chat/completions	/api/v1	/chat/completions
私有 Responses 接口	不能直接套用	先确认 Continue 是否支持

判断方法是：

1. 找到供应商明确给出的完整 Chat Completions 路径。
2. 去掉末尾的 /chat/completions。
3. 将剩余共同前缀作为 apiBase。
4. 查看 Continue 实际发送的请求，确认路径没有重复。

如果供应商同时实现了模型列表接口，可以分别测试：

/models
/chat/completions

如果它没有实现 /models，则只测试文档明确支持的聊天接口，不要把 /models 成功当成必要条件。

我一开始就是把完整聊天地址塞进 apiBase。结果插件又补了一次路径，404 得非常稳定。

第五步：验证流式协议

普通请求成功，不等于流式请求也能使用。Continue 的聊天体验通常依赖流式响应，OpenAI-compatible Chat Completions 一般使用 SSE。

curl -N "$API_BASE/chat/completions" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6.1-terra",
    "stream": true,
    "messages": [
      {
        "role": "user",
        "content": "输出 ABC"
      }
    ]
  }'

正常情况下，终端应连续收到以 data: 开头的事件，而不是等待完整 JSON 一次性返回。

常见的兼容实现可能返回类似结构：

data: {"choices":[{"delta":{"content":"A"}}]}
data: {"choices":[{"delta":{"content":"B"}}]}
data: {"choices":[{"delta":{"content":"C"}}]}

部分服务会使用结束标记，但具体形式应以供应商协议为准。

出现以下情况，说明“非流式能聊，但流式还没有打通”：

• 服务直接返回完整 JSON，没有分块。
• Content-Type 不是事件流类型。
• 代理层缓冲响应，几十秒后一次性输出。
• 数据块不是 Continue 期待的 Chat Completions 增量结构。
• 服务只实现了 Responses API 或私有流式协议。
• 网关发送了 SSE，但中间代理进行了压缩或缓存。

在拿到实测数据前，不应声称首 token 延迟是多少。延迟、吞吐和稳定性都需要通过真实请求记录。

第六步：上下文长度怎么配

gpt-6.1-terra 的以下参数目前均为 [待验证]：

• 总上下文窗口。
• 最大输入 token。
• 最大输出 token。
• 输入与输出是否共享总窗口。
• 超出长度时的截断策略。
• Continue 是否会自动裁剪上下文。

不要把其他模型的参数直接搬过来，也不要因为模型名称看起来较新，就默认它具有更大的上下文窗口。

建议按以下顺序确认：

1. 查供应商当前模型文档。
2. 查控制台中的模型详情。
3. 咨询供应商技术支持。
4. 逐步增加输入长度，记录首次出现长度错误的位置。
5. 区分总上下文、输入上限和最大输出。
6. 拿到可靠整数后，再写入 Continue 的 contextLength。

确认数字后，可以增加：

contextLength: VERIFIED_INTEGER

VERIFIED_INTEGER 只是占位符，不能直接使用。当前更安全的配置是省略该字段。

实测记录可以使用下面的表格：

场景	首 token 延迟	总耗时	输出 token	是否成功
普通 Chat	[待实测]	[待实测]	[待实测]	[待实测]
当前文件问答	[待实测]	[待实测]	[待实测]	[待实测]
Agent 工具调用	[待实测]	[待实测]	[待实测]	[待实测]
Tab 补全	[待实测]	[待实测]	[待实测]	[待实测]

使用 OpenAI Python SDK 验证

OpenAI Python SDK 可以测试 OpenAI-compatible 地址。先通过环境变量提供地址和 Key：

export API_BASE="供应商提供的_API_BASE"
export API_KEY="你的_API_KEY"

Python 示例：

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["API_KEY"],
    base_url=os.environ["API_BASE"],
)

response = client.chat.completions.create(
    model="gpt-6.1-terra",
    messages=[
        {
            "role": "user",
            "content": "只回复 SDK_OK",
        }
    ],
)

print(response.model)
print(response.choices[0].message.content)

这里的 base_url 必须指向供应商实际提供的 OpenAI-compatible 基础地址。

只有在 OpenAI 官方接口明确返回并允许调用 gpt-6.1-terra 时，才能把 base_url 改为 OpenAI 官方入口。现有资料无法确认这一点，因此不能默认该模型可通过 OpenAI 官方 API 调用。

Python SDK 流式验证

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["API_KEY"],
    base_url=os.environ["API_BASE"],
)

stream = client.chat.completions.create(
    model="gpt-6.1-terra",
    stream=True,
    messages=[
        {
            "role": "user",
            "content": "输出 ABC",
        }
    ],
)

for chunk in stream:
    if not chunk.choices:
        continue

    content = chunk.choices[0].delta.content
    if content:
        print(content, end="", flush=True)

print()

如果 curl -N 能持续收到 SSE，但 SDK 无法解析，应检查：

• 数据块是否符合 OpenAI Chat Completions 增量结构。
• 每个 SSE 事件是否以正确的空行分隔。
• 网关是否返回了私有字段结构。
• SDK 版本是否过旧。
• 响应是否被反向代理缓存或修改。

其他工具怎么配

Cline

选择 OpenAI-compatible 类型后，填写：

Base URL: 供应商提供的 API Base URL
Model ID: gpt-6.1-terra
API Key: 你的 API Key

不要让 Base URL 以 /chat/completions 结尾。配置完成后，先关闭复杂工具调用，只测试普通聊天。

Cherry Studio

新增自定义 OpenAI 服务时，核心仍然是三项：

API Host: 供应商提供的 API Base URL
Model: gpt-6.1-terra
API Key: 你的 API Key

如果“连通性测试”成功而聊天失败，应检查连通性测试是否只访问了模型列表接口。模型列表成功，不代表 Chat Completions 一定成功。

反过来也一样：某些服务没有实现 /models，但聊天接口可以正常使用。

Zed

Zed 的字段名会随版本和 provider 配置变化，核心映射不变：

{
  "api_url": "<供应商提供的 API Base URL>",
  "model": "gpt-6.1-terra"
}

应按当前安装版本，把这两个值放入对应 provider。不要直接把示意片段当成完整设置文件。

Codex CLI

只有当当前版本允许配置 OpenAI-compatible 基础地址和自定义 model ID 时，才能沿用同一组 Base URL、API Key 和 gpt-6.1-terra。

具体字段名应以本机命令帮助和对应版本文档为准。

Claude Code

Claude Code 主要使用 Anthropic 协议。某个网关同时提供 OpenAI-compatible 和 Anthropic 两类入口，不代表两种入口支持完全相同的模型。

除非供应商明确提供：

• Anthropic 到 OpenAI-compatible 的协议转换。
• gpt-6.1-terra 的模型映射。
• 工具调用字段转换。
• 流式事件格式转换。

否则不要假设 Claude Code 可以直接调用该模型。普通 Chat 能通，也不代表工具调用一定能通。

不同场景怎么选

使用场景	建议方案	原因
只想验证模型权限	模型列表接口或最小对话	变量最少，排障最快
Continue 聊天接入	OpenAI-compatible 配置	可直接验证 Chat Completions
多个工具共用接口	OpenRouter、ofox 或 Together AI 等聚合网关/中转方案	可以复用地址和模型映射规则，但要分别核对 model、SSE 与 tools 参数
企业代理使用自签证书	企业代理地址	还要处理 TLS 和额外请求头
Agent 编程	单独建立 Agent 配置	必须额外验证 tools 和流式结构
Tab 自动补全	不要默认复用 Chat	补全更看重低延迟和专用接口
长文件问答	先实测上下文上限	当前窗口数字没有可靠出处

我的做法是把 Chat、Agent 和 Tab 拆开。一个配置包打天下看起来省事，但排障时容易把不同问题混在一起。

完整排错表

下面的错误文本是常见兼容返回示意，不是已经验证的 gpt-6.1-terra 实测日志。发布文章或提交工单时，应替换成自己的原始响应。

现象	可能原因	处理方法
404 model_not_found	model ID 错误或 Key 无权限	使用 gpt-6.1-terra，检查授权
401 invalid_api_key	Key 错误、过期或请求发错地址	用同一地址和 Key 做终端测试
404 路径不存在	/v1 或聊天路径重复	查看实际 URL，删除重复部分
/models 返回 404	服务未实现模型列表接口	查文档并直接测试聊天接口
400 unsupported_parameter	不支持 tools 等参数	将 Chat 与 Agent 分开验证
429 Too Many Requests	并发、速率或额度限制	降低并发并读取重试响应头
流式 JSON 解析失败	返回非 SSE 或数据块不兼容	用 curl -N 查看原始响应
终端成功、Continue 失败	配置未重载或 URL 被二次拼接	重载窗口并检查实际请求
Chat 成功、Agent 失败	缺少工具调用支持	单独验证 tools 和 tool_choice

模型无权限时，可能看到类似响应：

HTTP 404: {"error":{"message":"The model `gpt-6.1-terra` does not exist or you do not have access to it.","type":"invalid_request_error","param":"model","code":"model_not_found"}}

API Key 错误时可能看到：

HTTP 401: {"error":{"message":"Incorrect API key provided","type":"invalid_request_error","param":null,"code":"invalid_api_key"}}

Chat 成功但 Agent 失败时，可能看到：

HTTP 400: {"error":{"message":"Unsupported parameter: 'tools'","type":"invalid_request_error","param":"tools","code":"unsupported_parameter"}}

这几类错误不能混着处理：

• 404 模型错误：检查 model ID 和权限。
• 404 路径错误：检查 Base URL 和路径拼接。
• 401：检查 API Key、请求地址和请求头。
• 400 工具错误：检查模型或网关是否支持工具调用。
• 429：检查额度、并发和速率限制。

不要一看到错误就重装插件，大多数情况下问题出在地址、权限或参数映射。

常见问题 FAQ

Q1：Continue.dev 的 Base URL 到底要不要带 /v1？

看供应商给出的完整聊天接口。

如果完整路径以 /v1/chat/completions 结尾，通常应把 /v1 保留在 apiBase 中，但不要把 /chat/completions 也填进去。

如果供应商的接口没有 /v1，就不要自行添加。

Q2：模型名填什么？

填写：

gpt-6.1-terra

不要改成 openai/gpt-6.1-terra，也不要自行添加其他前缀。

最终还要确认当前 API Key 是否拥有该模型的调用权限。

Q3：为什么终端能调用，Continue.dev 还是 404？

优先检查：

1. Continue 实际拼出的请求 URL。
2. /v1 是否重复。
3. /chat/completions 是否重复。
4. 配置字段是否适用于当前 Continue 版本。
5. 修改配置后是否已经重载窗口。
6. 终端和 Continue 是否使用完全相同的 Base URL、Key 和 model ID。

Q4：/models 返回 404 怎么办？

不要继续使用返回 404 的模型列表地址。

部分 OpenAI-compatible 服务没有实现 /models。此时应通过供应商文档、控制台或技术支持确认模型权限，再直接测试其明确提供的 Chat Completions 接口。

Q5：上下文长度应该填多少？

目前没有可核验数字，应标记为 [待验证]。

建议先省略 contextLength，拿到供应商文档或完成边界实测后再填写。

Q6：怎么确认请求真的落到了 gpt-6.1-terra？

同时核对：

• 响应中的 model。
• 供应商调用日志。
• 对应账单或用量记录。

只看 Continue 的模型选择器不够，响应字段也可能经过别名映射。

Q7：普通聊天成功，为什么 Agent 不能用？

Agent 还依赖：

• tools
• tool_choice
• 工具参数 Schema
• 结构化输出
• 流式工具调用增量
• 多轮工具结果回传

基础 Chat Completions 成功，只能证明普通聊天接口可用。

Q8：能把这个模型直接用于 Tab 自动补全吗？

可以尝试，但不能默认它适合。

目前没有可引用的首 token 延迟、生成速度或补全基准。应单独记录延迟、成功率和补全接受率，再决定是否保留。

Q9：provider: openai 是否代表模型来自 OpenAI 官方？

不代表。

在 Continue 等工具中，provider: openai 也可能只是表示使用 OpenAI-compatible 请求格式。模型的实际提供方和底层路由仍应通过供应商资料、调用日志与账单确认。

小结

Continue.dev 接入 gpt-6.1-terra，重点是以下几件事：

1. model ID 使用准确的 gpt-6.1-terra。
2. 不要擅自添加 openai/ 等前缀。
3. 基础地址只保留一次版本路径。
4. apiBase 不要包含 /chat/completions。
5. /models 仅在供应商明确支持时使用，返回 404 就应停止依赖该地址。
6. 上下文长度不要填写猜测值。
7. 普通请求成功后，还要单独验证 SSE 流式响应。
8. 最终通过响应字段、服务端日志和账单记录确认真实路由。

推荐验收顺序是：

确认模型 ID 与权限
→ 终端最小对话
→ Continue 普通 Chat
→ SSE 流式输出
→ 当前文件问答
→ Agent 工具调用
→ 长上下文
→ Tab 补全

慢一点没关系。按层验证，出了问题至少能准确判断是地址、权限、协议、插件还是模型能力。