[Feature] 将供应商类型调整为端点类型，在同一供应商下的不同端点可以为不同的格式

[fangzhengjin]

由于目前大多 Coding Plan 或者其他上游，都是同一套 key 支持不同协议端点的请求

但是在 CCH 中如果对同一渠道添加不同协议的支持，就需要创建多个供应商，key 相同，可用模型 相同，模型映射 相同，限流 相同

除了 Endpoint 几乎完全相同，但是需要创建多套供应商，修改和更新也需要操作多次

目前看到在 provider_endpoints 表中其实对不同 Endpoint 其实有标记类型，所以是否能考虑将协议设置放置在 Endpoint 配置上

[github-actions]

Thank you for this feature suggestion.

Analysis:

I've analyzed the current architecture and found that your request is both valid and partially already supported in the data model. Here's what I discovered:

Current Architecture:

1. providers table (src/drizzle/schema.ts:160-189): Contains the providerType field (claude, claude-auth, codex, gemini, gemini-cli, openai-compatible) that controls the protocol/format

2. provider_endpoints table (src/drizzle/schema.ts:350-400): Already has a providerType field (lines 355-358), but it's currently only used for:

   • Unique constraint: vendorId + providerType + url
   • Index for filtering by vendor and type

The Key Issue:

In the runtime proxy flow (src/app/v1/_lib/proxy/forwarder.ts:572-575), endpoint selection uses the provider's providerType, not the endpoint's:

const preferred = await getPreferredProviderEndpoints({
  vendorId: providerVendorId,
  providerType: currentProvider.providerType,  // Uses provider's type, not endpoint's type
});

This means even though endpoints have their own providerType, it's not being used at runtime to override the provider's type.

Feasibility Assessment:

This feature is architecturally feasible because:

1. The provider_endpoints table already has the providerType field
2. The endpoint selection logic in getPreferredProviderEndpoints (src/lib/provider-endpoints/endpoint-selector.ts:41-52) already filters by providerType
3. The format-provider compatibility check exists in provider-selector.ts:141-159

Implementation Considerations:

To implement this feature, changes would be needed in:

1. Schema (src/drizzle/schema.ts): May need to make providers.providerType optional or add a way to inherit from endpoint

2. Provider Selection (src/app/v1/_lib/proxy/provider-selector.ts): Would need to allow a provider without a specific providerType to be selected for multiple format types

3. Endpoint Selection (src/app/v1/_lib/proxy/forwarder.ts:572-575): Would need to use the endpoint's providerType for format matching instead of the provider's

4. Frontend (src/app/[locale]/settings/providers/): UI updates to allow configuring providerType at the endpoint level

Related Existing Code:

• src/lib/provider-type-utils.tsx - Provider type utilities
• src/app/v1/_lib/proxy/provider-selector.ts:141-159 - Format compatibility checking
• src/repository/provider-endpoints.ts - Endpoint data access

---

Automated response from Claude AI