Custom provider "minimax" silently reuses built-in Anthropic provider when api is omitted

[kkskkkcc]

Summary

When creating a custom provider whose id is minimax and omitting the api field, DSH silently reuses the built-in catalog provider.

As a result, the custom OpenAI-compatible endpoint is routed through the built-in Anthropic provider.

Expected:

POST /v1/chat/completions

Actual:

POST /v1/messages

This results in:

404 page not found

when using MiniMax's OpenAI-compatible API.

---

Reproduction

1. Create a custom provider.

id: minimax
baseURL: https://api.minimax.cn/v1
api: (not specified)

2. Select MiniMax-M3.

3. Send a message.

DSH sends:

POST /v1/messages

instead of

POST /v1/chat/completions

---

Root Cause

buildProvider() currently contains:

if (catalog !== undefined && spec.api === undefined) {
    return reuseCatalogProvider(...)
}

Because the custom provider id collides with a built-in catalog provider, the OpenAI-compatible provider is never instantiated.

---

Proposed Fix

• Warn when a custom provider id collides with a built-in provider.
• Require explicit protocol selection in Settings.
• Continue supporting reuseCatalogProvider() for backward compatibility.

I implemented this locally and verified that:

• /v1/chat/completions is used correctly.
• Existing catalog providers remain backward compatible.
• Regression tests pass.
• If this approach is acceptable, I'd be happy to clean up the patch and submit it as a PR if external contributions are accepted.
  提交给deek官方的.zip

[denial123789]

这个根因与 pinned rc.2 b150a55 的实现一致。这里需要强调一个容易漏掉的边界：baseURL 与 wire protocol 是两个独立事实。

buildProvider() 先用 profile dict key 调 catalogProvider(spec.provider)；命中 catalog 且 api 省略时，reuseCatalogProvider() 虽然应用 materialized model 的 baseUrl，但 stream() / streamSimple() 仍委托给 catalog provider。因此“自定义 URL + catalog id + 未写 api”完全可能得到新 endpoint 和旧 protocol 的组合。

当前可立即验证的最小恢复是：

llm-pi-ai:
  providers:
    minimax-openai-cn:
      displayName: MiniMax OpenAI CN
      apiKeyEnv: MINIMAX_API_KEY
      api: openai-completions
      baseURL: https://api.minimax.cn/v1
      models:
        - id: MiniMax-M3

建议使用独立 id，而不是继续复用 minimax：这样 Session、默认模型、credential reference、日志和回滚都能明确区分。若为了兼容必须保留 catalog id，显式 api: openai-completions 也会走 configured-provider construction，但要回归验证被替换的 catalog 能力。

取证时不需要公开 key，只记录：provider dict key、api 是显式还是省略、脱敏后的 baseURL、最终 HTTP pathname 和首个状态码。/messages 404 是 protocol/path 证据；切到 /chat/completions 后出现 401/403 才进入 credential/entitlement 分支。务必用 fresh Session 验证，不要只看 Settings 保存成功。

我赞成你提出的“碰撞警告 + UI 显式协议”方向，但不建议全局取消 catalog reuse：Bedrock/Vertex/Codex 等 catalog provider 可能拥有通用 profile 无法重建的认证和实现状态。更稳妥的 acceptance gate 是：省略 api 保持向后兼容；显式 api 强制选择协议；catalog id + changed baseURL + omitted api 在 authoring surface 明确警告；测试断言最终 wire path。

完整决策矩阵、验证字段和 rollback：
https://sandbaseai.github.io/deepseek-harness-handbook/custom-provider-catalog-collision.html

[kkskkkcc]

Thanks for the detailed explanation.

You're absolutely right about the distinction between baseURL and the wire protocol.

After reproducing the issue locally, I confirmed that the root cause is the provider ID collision combined with an omitted api field.

I ended up implementing a local fix that:

• keeps reuseCatalogProvider() unchanged
• emits a warning when a custom provider collides with a built-in catalog provider and api is omitted
• requires explicit protocol selection in the Settings UI
• keeps backward compatibility for existing catalog providers

With this change, the custom MiniMax OpenAI provider correctly uses:

POST /v1/chat/completions

instead of:

POST /v1/messages

Thanks again for the feedback. I agree that preserving catalog reuse is the safer design.