opencode-go provider returns stale model list — deepseek-flash (V4.1 Flash) missing & custom provider fails with MissingSessionID

[Wumonly]

问题描述

DeepSeek Harness 内置的 opencode-go 提供商返回的模型列表不包含最新的 deepseek-flash（DeepSeek V4.1 Flash）。手动在设置中添加自定义提供商后，所有请求均返回 400: MissingSessionID 错误，导致 OpenCode Go 路由完全不可用。

复现步骤

1. 在 DSH 设置 → 模型 → 添加提供商中，选择内置的 opencode-go。
2. 点击“获取可用模型”，返回的列表中不包含 deepseek-flash。
3. 手动创建自定义提供商，Provider ID 填写 opencode-go，API 地址填写 https://opencode.ai/zen/go/v1，协议选择 openai-completions。
4. 添加模型 ID deepseek-flash 后尝试对话，收到报错：

400: {"type":"MissingSessionID","message":"Error from provider (Console Go): Request is missing x-opencode-session and cannot be routed efficiently. Please see https://opencode.ai/docs/go/#where-can-i-use-it"}

预期行为

1. opencode-go 的模型列表应包含 deepseek-flash（即 DeepSeek V4.1 Flash）。
2. 自定义或内置的 OpenCode Go 提供商应能正常发送请求，不出现 MissingSessionID 错误。

环境信息

• DSH 版本： 0.1.5-rc.2
• OpenCode Go 提供商配置：API 地址 https://opencode.ai/zen/go/v1，协议 openai-completions
• 操作系统：windows 25H2

已尝试的排查

• 确认 API Key 有效，且 GET https://opencode.ai/zen/go/v1/models 返回的列表中包含 deepseek-flash。
• 手动添加模型 ID deepseek-flash 后仍无法正常调用，报错始终为 MissingSessionID。
• 了解到社区插件 dsh-opencode-models 可以拉取完整模型列表，但该插件只解决模型发现问题，不解决自定义提供商的 x-opencode-session 请求头缺失问题。

请求

1. 为内置 opencode-go 路由实现实时模型发现，或在“获取可用模型”时调用真实端点 GET {baseURL}/models。
2. 让内置 opencode-go 路由自动附加 x-opencode-session 请求头（可参考社区插件的实现）。
3. 更新静态 catalog，补充 deepseek-flash（DeepSeek V4.1 Flash）等新模型。
4. 如果以上为有意设计，请在文档中说明推荐的 OpenCode Go 接入方式。

[PerryLink]

先说结论：你的两个判断都基本成立——内置 opencode-go 的模型列表是静态目录（跟随 pi-ai 库版本），不是实时拉取的；而 x-opencode-session 这个请求头在 dsh 核心里确实没有任何实现。

模型列表为什么"陈旧"：dsh 并没有自己维护这份目录。packages/llm/llm-pi-ai/src/catalog.ts:15 直接从上游库导入：

import { builtinProviders, getBuiltinModels, getBuiltinProviders } from '@earendil-works/pi-ai/providers/all'

而依赖版本在 packages/llm/llm-pi-ai/package.json:44 固定为 "@earendil-works/pi-ai": "^0.85.1"。所以列表里有没有 deepseek-flash，取决于安装的 pi-ai 版本收录没有，dsh 这边只是透传。opencode-go 确实是 pi-ai 的内置 provider id（packages/experimental/webworker-runtime/src/node/external_packages/pi-ai.ts:34-35）。

"获取可用模型"的行为：对目录里已有的 provider，它不做任何网络请求，直接返回安装目录（packages/llm/llm-pi-ai/src/discovery.ts:273-278）：

// A catalog route already has its answer, and a better one: the installed
// entries carry context windows and output caps no listing endpoint reports.

只有目录不认识的 provider（网关、自建服务）才会走 GET {baseURL}/models 实时探测（discovery.ts:286-306，路径拼装见 :117-122）。所以你期望的"实时发现"目前对 opencode-go 这类内置路由不存在——这条请求描述准确。社区插件 dsh-opencode-models 是否真的做实时发现，我这边没有源码可核（未验证）。

MissingSessionID 是怎么回事：我在 packages/**/*.ts 里 grep x-opencode-session，结果是 0 命中——dsh 核心完全没有发送这个头的代码，你的请求 2 准确。dsh 源码里唯一的 openai-completions 请求头集合（llm-deepseek 适配器）只有 authorization/attribution/x-deepseek-harness-* 这些（packages/llm/llm-deepseek/src/protocols/chat-completions/adapter.ts:257-269）；而你的自定义提供商实际上是 pi-ai 的一条手工 profile（config.ts:90："the providers dict key IS the route"），由 pi-ai 适配器服务，其请求头逻辑在库内部。有意思的是 pi-ai 自己其实有会话亲和头的概念：catalog.ts:255 把 sendSessionAffinityHeaders 标为 'withhold'，即这个开关被 dsh 刻意不开放给配置——内置路由靠 pi-ai 目录条目自带的值生效，你没法在设置里手动打开。手工声明路由时，若 api 与目录条目不一致，继承的 compat（含会话亲和配置）会被丢弃、退回 pi-ai 对 baseURL 的探测（catalog.ts:790-795）；对不认识的 URL，探测"当作 OpenAI 本尊"处理（catalog.ts:341-351）。这很可能就是 400 的直接原因——但 pi-ai 库内部何时发这个头、探测逻辑细节，本仓库里没有源码可读（未验证，仅推断）。

可行的绕法：别另建自定义提供商，继续用内置 opencode-go 路由，用 modelOverrides 或 models 把 deepseek-flash 补进去——它复用目录条目自带的 API 实现和会话亲和配置（catalog.ts:167-176、:618-640），风险最小。注意别在条目上显式改 api，那会触发上面说的 compat 丢弃。

如果方便，贴一下你的 settings.yaml 里该路由片段和一次完整报错，我可以帮你核对路由解析细节。

[Wumonly]

感谢定位，你列的几条我都验证过了。

一、为什么 chat/completions 这条路必然 400

三条，都在代码里能指到位置：

1. pi-ai 库里根本没有这个头的出口。 我装的是 @earendil-works/pi-ai@0.85.1（也就是 npm 上的最新版），全库 grep x-opencode-session 是 0 命中。它只有一个 SessionAffinityFormat，三档：openai（发 session_id + x-client-request-id + x-session-affinity）、openai-nosession（发后两个）、openrouter（发 x-session-id）。没有 opencode 这一档，所以走协议层的会话头永远轮不到它。
2. Harness 其实已经把会话 id 递下去了，只是没转成头。 安装包里发请求的地方是 streamSimple(model, context, { …, sessionId: String(options.sessionId), headers: requestHeaders(profile.headers) })——id 到手了，可 requestHeaders() 只做 attribution 合并，没把它写成这个头。
3. 配置层确实也被堵死。 确认了 COMPLETIONS_COMPAT_GATE 里 sendSessionAffinityHeaders 和 sessionAffinityFormat 都是 "withhold"，responses 和 anthropic 的 gate 里同样。

存在"部分模型路径有会话信息、另一些没有"问题，具体差异在与：opencode-go.json 里 openai-responses 那四个条目带 sessionAffinityFormat: "openai-nosession"，于是能发出 x-client-request-id；而 openai-completions 那二十几个条目一个 session 字段都没有，就是裸奔 400。原因是同一条路由、两半表现分裂，不是自定义提供商的问题。

二、真机复现

POST https://opencode.ai/zen/go/v1/chat/completions，model: deepseek-v4.1-flash：

不带会话头  → HTTP 400
{"type":"error","error":{"type":"MissingSessionID","message":"Error from provider (Console Go):
 Request is missing x-opencode-session and cannot be routed efficiently. …"}}

带 x-opencode-session: <一个固定串>  → HTTP 200
{"id":"…","object":"chat.completion","model":"deepseek-v4.1-flash","choices":[…],"cost":"0"}

同一个固定串就能从 400 变 200，说明网关只校验这个头在不在，不校验内容。同批测试里 deepseek-flash、deepseek-v4-flash、glm-5.3-flash、hy3、mimo-v2.5 也都通了。

三、现在的临时做法

headers 是 provider 级的，而且只有 attribution 的 user-agent 算保留名，x-opencode-session 能原样透传；pi-ai 三个协议客户端都会把调用方 headers 放在最后合并，所以能到线上。于是在自己的 settings 里给路由加了一行：

llm-pi-ai:
  providers:
    <route>:
      apiKeyEnv: <credential>
      api: openai-completions
      baseURL: https://opencode.ai/zen/go/v1
      headers: { x-opencode-session: <固定串> }

settings.yaml

局限：固定串只补上"头存在"，所有会话挤在同一个亲和桶里，OpenCode 要的按会话路由和 prompt cache 亲和拿不到。真正要解决还得靠在代码里补。

四、建议的修法

最小改动是在发请求那一步，把已经拿到的 options.sessionId 转成这个头，只对 opencode 系路由生效：

// packages/llm/llm-pi-ai/src/adapter.ts（示意）
function requestHeaders(headers, sessionId) {
  const attribution = attributionHeaders()
  const reserved = new Set(Object.keys(attribution).map(n => n.toLowerCase()))
  return {
    ...Object.fromEntries(Object.entries(headers ?? {}).filter(([n]) => !reserved.has(n.toLowerCase()))),
    ...(sessionId === undefined ? {} : { 'x-opencode-session': sessionId }),
    ...attribution,
  }
}
// 调用处：headers: requestHeaders(profile.headers, options.sessionId)
// 判据可以用 profile.baseURL 是否指向 opencode.ai，免得给所有路由都挂上

另一个方向是改 pi-ai：给 SessionAffinityFormat 加一档 "opencode" 发 x-opencode-session，Harness 这边再把 sessionAffinityFormat 放开。这样以后别的网关要自家会话头也能复用。

五、400完整的报错session

dsh-session-session-5fdb1590-4dbc-45b3-a8a8-7eefd2e0190c.zip

[Teresa-CoCo]

同样出现这个问题+1