关于opencode go套餐在dsh中的配置问题

[xiangziaa]

我想在dsh中添加一个opencode go的plan使用deepseek模型，那么在设置中只有两种添加方式：

1. 添加供应方：dsh内部自带的供应方，添加后从静态的配置文件中拉取模型，没有最新的模型，包括deepseek v4.1。我想要自己手动添加一个模型，报错“llm-pi-ai: provider "opencode-go" model "deepseek-v4.1-flash" needs an api; the installed catalog does not describe it, so set the route's api to the wire protocol its endpoint speaks”。
2. 添加自定义供应方：自己输入opencode的base api然后拉取模型列表，但是opencode没有提供允许输入类型、上下文长度、最大输出长度这些参数，导致需要自己手动设置，最关键的问题是余额插件只支持识别官方预设的“添加供应方”这种方式去添加的plan，导致余额插件识别不到api key。

我只想添加一个opencode go的plan，为什么要这么麻烦！！！！！！！

[PerryLink]

核实结论:两个现象都属实,且都有现成的正确路径;「被拒」不是 bug,是 catalog 校验的正常 fail-fast.

1. 静态 catalog 确实没有 v4.1:pi-ai 0.85.1(dsh 随附版本)里 opencode-go 只有 27 个条目(openai-completions 21 个,含 deepseek-v4-flash/-pro;anthropic-messages 2 个;openai-responses 4 个);全量扫描所有 provider,没有任何 deepseek v4.1 条目,官方 deepseek 供应方也只有 v4-flash/v4-flash-vision-exp/v4-pro 三个. 所以「自带供应方拉不到 v4.1」属实.
2. 手动加模型被拒的原因在 dsh-llm-pi-ai/src/catalog.ts:888-892:新模型 id 不在已装 catalog 里时,其 wire 协议(api)从「路由显式 api → 同 id 已装条目 → 路由全体条目共识」三级依次回退;opencode-go 的路由静态条目跨三种协议(catalog.ts:659-663 sharedCatalogApi 返回 undefined),三级全部落空 ⇒ 报「needs an api」. 报错文案本身就是解法提示:给路由声明 api. compat 平面绕不过去,它与 api 是两个正交字段.
3. 正确配方(settings.yaml 的 llm-pi-ai.providers 下,二选一):
   • 在 opencode-go 路由上声明 api: openai-completions + baseURL: https://opencode.ai/zen/go/v1 + models 列表(id: deepseek-v4.1-flash、contextWindow、maxTokens 等)——注意 models 列表会替换整个 catalog(config.ts:106-109),只想用这一个模型时正合适;
   • 或新建一个自定义路由名(如 opencode-go-v41),api/baseURL/models 全手写——未知路由名完全合法(catalog.ts:200-204、provider.ts:167-191).
   • 可选协议仅 openai-completions / openai-responses / anthropic-messages(provider.ts:47-51).
4. 补充:余额插件只认官方「添加供应方」流程,是第三方插件的识别范围问题,宿主侧无可核路径;先用第 3 条配方把模型跑起来,余额识别可单独向插件作者反馈.

[PerryLink]

两个现象我都核实了，结论先说：都有现成的正确配置路径，你看到的报错不是 bug，是 catalog 校验的正常 fail-fast。

1. 自带供应方确实拉不到 v4.1
dsh 随附的 pi-ai 0.85.1（dsh-llm-pi-ai 的依赖）静态 catalog 里，opencode-go 一共只有 27 个条目：openai-completions 21 个、anthropic-messages 2 个、openai-responses 4 个；其中 deepseek 系只有 v4-flash / v4-flash-vision-exp / v4-pro。全量扫描所有 provider 的数据文件，没有任何 deepseek v4.1 条目，官方 deepseek 供应方同样只有这三个 v4 型号。而且 catalog 路由的模型列表来自本地数据、不走网络（discovery 对 catalog 路由直接回本地目录），所以没有任何开关能“刷新”出 v4.1。

2. 手动添加报错的机制
dsh-llm-pi-ai/src/catalog.ts:888-892：新模型 id 不在已装 catalog 里时，它的 wire 协议按三级回退——路由显式 api → 同 id 已装条目 → 路由内所有条目的一致协议（sharedCatalogApi，catalog.ts:659-663）。opencode-go 的 27 个条目跨了三种协议，sharedCatalogApi 返回 undefined；你的新模型又没有同 id 条目，三级全部落空，于是报 “needs an api”。报错文案本身就是在提示解法：给路由声明 api。compat 平面解决不了这个错——api 与 compat 是两个正交字段，compat 只调协议内的行为开关，不决定协议本身。

3. 正确配方（settings.yaml 的 llm-pi-ai.providers 下，二选一）

方案 A：直接在 opencode-go 路由上声明 api + baseURL + models。注意 models 列表会整体替换该路由的 catalog（config.ts:105-109），只想用 v4.1 这一个模型时正好；modelOverrides 不能新增 catalog 没有的 id（catalog.ts:853-856），所以别走那条路：

llm-pi-ai:
  providers:
    opencode-go:
      apiKeyEnv: OPENCODE_API_KEY   # 需要鉴权时引用环境变量
      api: openai-completions
      baseURL: https://opencode.ai/zen/go/v1
      models:
        - id: deepseek-v4.1-flash
          name: DeepSeek V4.1 Flash
          contextWindow: 1000000
          maxTokens: 384000
          input: [text]
          reasoningEfforts:
            off: null
            low: low
            high: high
            max: max
          compat:
            supportsStore: false
            supportsDeveloperRole: false
            maxTokensField: max_tokens
            requiresReasoningContentOnAssistantMessages: true
            thinkingFormat: deepseek

方案 B：新建一个自定义路由名（如 opencode-go-v41），api / baseURL / models 全部手写——未知路由名完全合法（catalog.ts:200-204 返回空目录 + provider.ts:167-191 走协议工厂），也不会动到自带的 opencode-go 路由。可选协议只有 openai-completions / openai-responses / anthropic-messages 三种（provider.ts:47-51）。

4. 余额插件识别不到
这是第三方插件的识别范围问题：它只认官方“添加供应方”流程产生的配置形态，宿主侧没有为它兜底的路径。先用方案 A/B 把模型跑起来，识别问题单独向插件作者反馈。

核实基准：checkout D:\deepseek-harness @ c291e79（HEAD）——dsh-llm-pi-ai 的 catalog.ts / provider.ts / config.ts / discovery.ts，以及 node_modules 中 pi-ai 0.85.1 的 dist/providers/data/*.json（opencode-go 27 条目、全目录无 v4.1）。
未验证部分：① 示例中 contextWindow / maxTokens / reasoningEfforts / compat 是从同路由 v4-flash 条目抄来的，v4.1-flash 在 opencode 网关上的真实参数无法从代码确认，请以网关文档/实测为准；② opencode 网关当前是否真的提供 deepseek-v4.1-flash 这个 id 及其价格，代码无法验证；③ 余额插件的具体识别逻辑是第三方代码，未核对。