[Bug/Feature][llm-pi-ai] 自定义路由无法使用 google-generative-ai，OpenCode Go 的 Gemini 4 Argon Contributor 完全不可用

[Xenon1112]

[Bug/Feature][llm-pi-ai] 自定义路由无法使用 google-generative-ai，导致 OpenCode Go 的 Gemini 4 Argon Contributor 在 DSH 中完全不可用

TL;DR (EN). llm-pi-ai's config layer accepts only three wire protocols (openai-completions / openai-responses / anthropic-messages). Google's google-generative-ai is already implemented in the bundled pi-ai (the shipped Zen route wraps googleGenerativeAIApi()), but a user-declared route may not name it, model-level api/baseURL are ignored by resolveRouteModels, and declaring it on a new route makes the entire llm-pi-ai provider set disappear. Result: a model that speaks only the Google protocol — OpenCode Go's gemini-4-argon-contributor — cannot be used from DSH at all, even though the same model answers HTTP 200 with a direct API call.

TL;DR (中文). OpenCode Go 的 Gemini 4 Argon Contributor 实测可用（直连它只认 Google 协议），但 DSH 的 llm-pi-ai 配置层只允许三种协议，且不接受用户声明 google-generative-ai；手写路由还会让整组提供方一起失效。请求：把该协议开放给自定义路由（pi-ai 里已有实现），或允许在模型条目上声明 api/baseURL。

---

环境

• DeepSeek Harness Desktop（Windows x64，nightly 通道）
  • resources/app-update.yml: provider: generic / url: https://download.deepseek.com/dsh-desk/feeds/win-x64/ / channel: nightly
• 随包 pi-ai 目录生成时间："generatedAt":"2026-09-22T19:31:44.346Z"（schemaVersion: 3）
• OS：Windows；profile desktop；配置：$DSH_HOME/profiles/desktop/cordis.patch.yml → llm-pi-ai.config.providers
• 使用中的 provider：opencode-go（OpenCode Go 订阅，密钥经 apiKeyEnv: OPENCODE_API_KEY 解析）

目标模型（OpenCode Go 官方文档 https://opencode.ai/docs/go/）

项	值
model id	gemini-4-argon-contributor
端点	https://opencode.ai/inference/go/v1/models/gemini-4-argon-contributor
AI SDK	@ai-sdk/google（Google 原生协议）
规格 / 价格	1,048,576 上下文 / 65,536 输出；$4 / $20 每百万 token；Contributor 档（prompt 可能用于训练 Google 模型）

实测（2026-10-15，直连 OpenCode Go，密钥取自本机 OpenCode 凭据）

（1）模型确实在账号的 Go 套餐里 —— 两种 API 主机都返回 200 且列表含它：

GET https://opencode.ai/inference/go/v1/models   → 200，37 个模型，含 gemini-4-argon-contributor
GET https://opencode.ai/zen/go/v1/models         → 200，同上

（2）Google 协议调用正常，x-goog-api-key 与 Authorization: Bearer 都可用：

POST https://opencode.ai/inference/go/v1/models/gemini-4-argon-contributor:generateContent
     headers: x-opencode-session: dsh-probe-gen-1
     body:    {"contents":[{"role":"user","parts":[{"text":"只回答两个字：可以"}]}],"generationConfig":{"maxOutputTokens":64}}
→ 200 {"responseId":"…","modelVersion":"gemini-4-argon-contributor",
       "candidates":[{"finishReason":"STOP","content":{"role":"model","parts":[{"text":"可以"}]}}]}

（3）流式同样正常：

POST …/models/gemini-4-argon-contributor:streamGenerateContent?alt=sse
→ 200  content-type: text/event-stream
   data: {"candidates":[{"content":{"parts":[{"text":"一"}]}}], …}
   data: {"candidates":[{"content":{"parts":[{"text":"、二、三。"}]}}], …}

（4）但该模型只讲 Google 协议，其余三种协议在网关上全部被拒（分别用 Authorization: Bearer / x-api-key + anthropic-version 试过）：

请求	结果
POST /inference/go/v1/chat/completions（OpenAI）	400 {"type":"error","error":{"type":"ModelProtocolUnsupported","message":"Model does not support this protocol."}}
POST /zen/go/v1/chat/completions（OpenAI，对照组 kimi-k3 正常返回）	同上
POST /inference/go/v1/messages（Anthropic）	同上
POST /zen/go/v1/messages（Anthropic）	同上
model: gemini-4-argon（Zen 按量付费 id）	{"error":{"type":"server_error","message":"Upstream request failed: Model is unavailable."}}

（顺带：/zen/go/v1/models/<id>:generateContent 这类路径会返回官网 SPA 的 HTML —— 只有 /inference/go/v1 是 Google 协议的 API 路由。）

复现

尝试 A：把模型追加到内置 opencode-go 路由，并在条目上声明协议

      opencode-go:
        models:
          # …既有 28 个模型…
          - id: gemini-4-argon-contributor
            name: Gemini 4 Argon Contributor
            api: google-generative-ai
            baseURL: https://opencode.ai/inference/go/v1
            contextWindow: 1048576
            maxTokens: 65536
            input: [text, image]

结果：设置 → 模型 页报错（原文）

llm-pi-ai: provider "opencode-go" model "gemini-4-argon-contributor" needs an api; the installed catalog does not describe it, so set the route's api to the wire protocol its endpoint speaks

该模型能在设置页 opencode-go 卡片里看到，但聊天侧模型选择器里不出现。按提示去设路由级 api 会把整条跨三种协议的 opencode-go 一起带偏，不可行。

尝试 B：照 opencode-haiku 的写法手写一条新路由（路由级 api）

      opencode-gemini-argon:
        displayName: OpenCode Go · Gemini 4 Argon
        apiKeyEnv: OPENCODE_API_KEY
        api: google-generative-ai
        baseURL: https://opencode.ai/inference/go/v1
        models:
          - id: gemini-4-argon-contributor
            name: Gemini 4 Argon Contributor
            contextWindow: 1048576
            maxTokens: 65536
            input: [text, image]

结果：整组 llm-pi-ai 提供方一起失效 —— openrouter、opencode-go、opencode 的模型全部从选择器消失，运行中的会话回落到官方账号的 deepseek-flash；删掉这段后全部恢复。推测是该路由的 api 未通过 supportedProtocols() 的 zod 校验，导致整个 profile 配置被拒，而不是只跳过这一条路由。

根因（nightly 包内代码定位）

1. 配置层只认三种协议：

   // app.asar:860205
   const PROTOCOLS = {
     "openai-completions": openAICompletionsApi,   // 860206
     "openai-responses":   openAIResponsesApi,     // 860207
     "anthropic-messages": anthropicMessagesApi    // 860208
   };
   function supportedProtocols() { return Object.keys(PROTOCOLS); }   // 860218-860219

2. 路由级 api 用该列表做 schema 校验：api: z.union(supportedProtocols())（860423）→ google-generative-ai 属非法值。

3. 运行时第二道门：const factory = spec.api === void 0 ? void 0 : PROTOCOLS[spec.api];（860300），未命中即抛

   llm-pi-ai: provider "<p>" names api "<api>", which this build cannot serve; supported protocols are <…>
   

4. 模型条目上的 api/baseURL 不参与解析，resolveRouteModels 只有路由级回退链：

   const routeApi = sharedCatalogApi(defaults);                              // 仅当 apis.size === 1
   const api      = request.api ?? base?.api ?? routeApi;                    // 860074：request = 路由
   const baseUrl  = request.baseURL ?? base?.baseUrl ?? providerBaseUrl;     // 860076

   → 目录里没有该模型（base 为 undefined）+ opencode-go 跨三种协议（routeApi 为 undefined）+ 模型级 api 不读 ⇒ 必然报 "needs an api"。这也解释了「设置页能看到、选择器看不到」。

5. 另有一份 const LISTABLE_PROTOCOLS = new Set([ "anthropic-messages", "openai-completions" ])（861543），看起来决定哪些协议下的模型可被列出；openai-responses 系的模型（grok-4.6/grok-4.7/muse-spark-1.2/1.3-contributor）若同样在设置页可见却不进选择器，可能同源。

6. 能力不存在缺口：pi-ai 已实现该协议，随包的 Zen 路由正是用它跑 Gemini 3.x：

   // app.asar:1106088-1106091
   "anthropic-messages":   withOpenCodeSessionHeader(anthropicMessagesApi()),
   "google-generative-ai": withOpenCodeSessionHeader(googleGenerativeAIApi()),
   "openai-completions":   withOpenCodeSessionHeader(openAICompletionsApi()),
   "openai-responses":     withOpenCodeSessionHeader(openAIResponsesApi()),

   缺的只是配置层把它开放给用户自定义路由（外加 PROTOCOLS / LISTABLE_PROTOCOLS 两处名单）。

期望（任选其一即可解锁这一类模型）

1. 最小改动：把 google-generative-ai 加入 PROTOCOLS（pi-ai 内实现随包可用），使手写路由能声明它；
2. 或允许在模型条目上声明 api/baseURL（models[] / modelOverrides），这样目录外的单个模型可以直接挂到既有路由上，无需新开路由；
3. 或至少让不被支持的 api 只拒绝该条路由并给出可读错误 —— 目前表现为整组提供方一起消失，用户只看到模型凭空没了。

临时绕过（供其他用户参考）

• 本地起一个协议桥：DSH 侧声明 api: openai-completions + baseURL: http://127.0.0.1:<port>/v1，桥把 OpenAI chat/completions 翻成 Google :streamGenerateContent?alt=sse（带上 x-goog-api-key 或 Authorization: Bearer，以及 x-opencode-session），再把 Google SSE 翻回 OpenAI SSE；
• 或直接使用 OpenCode 自己的 CLI/TUI（原生支持 Google 协议）。

[Xenon1112]

wow thank you for answering me at the night time.And btw I wanna know whether language you prefer | | 徐诺 | | ***@***.*** |

…

---- 回复的原邮件 ---- | 发件人 | Prithwish ***@***.***> | | 日期 | 2026年10月16日 01:38 | | 收件人 | ***@***.***> | | 抄送至 | ***@***.***>***@***.***> | | 主题 | Re: [deepseek-ai/deepseek-harness] [Bug/Feature][llm-pi-ai] 自定义路由无法使用 google-generative-ai，OpenCode Go 的 Gemini 4 Argon Contributor 完全不可用 (Discussion #9752) | I think supporting the native Google protocol would be a useful addition, especially since the underlying library already seems to support it. One thing I'd be careful about is how configuration errors are handled. If one custom model has an unsupported API type, it shouldn't make every other provider disappear too. Maybe each route could be validated independently, with a clear error for the one that failed. That would make debugging config files much easier. I'd also like to see a test with a normal OpenAI-compatible route and a Google-protocol route in the same config. That would help confirm that adding support for another API doesn't accidentally break the existing providers. Allowing a model to specify its API type and base URL sounds useful too, as long as the configuration is validated and the right authentication and streaming behavior are used for that protocol. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[Xenon1112]

Oh noop I found it in my mail and thought you are a developer of dsh()-_- | | 徐诺 | | ***@***.*** |

…

---- 回复的原邮件 ---- | 发件人 | Prithwish ***@***.***> | | 日期 | 2026年10月16日 01:38 | | 收件人 | ***@***.***> | | 抄送至 | ***@***.***>***@***.***> | | 主题 | Re: [deepseek-ai/deepseek-harness] [Bug/Feature][llm-pi-ai] 自定义路由无法使用 google-generative-ai，OpenCode Go 的 Gemini 4 Argon Contributor 完全不可用 (Discussion #9752) | I think supporting the native Google protocol would be a useful addition, especially since the underlying library already seems to support it. One thing I'd be careful about is how configuration errors are handled. If one custom model has an unsupported API type, it shouldn't make every other provider disappear too. Maybe each route could be validated independently, with a clear error for the one that failed. That would make debugging config files much easier. I'd also like to see a test with a normal OpenAI-compatible route and a Google-protocol route in the same config. That would help confirm that adding support for another API doesn't accidentally break the existing providers. Allowing a model to specify its API type and base URL sounds useful too, as long as the configuration is validated and the right authentication and streaming behavior are used for that protocol. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>