提案：新增 Native Passthrough 模式，用於同 API surface 的帳號/憑證路由

[ChengYen-Tang]

背景

最近 Google / Claude 對不合規或非預期的第三方使用方式偵測變得更嚴格。這本身可以理解，因為平台需要避免濫用或違反服務條款的使用情境。

但我的使用情境不是要偽裝官方客戶端，也不是要透過非官方協定去繞過限制。

我的主要需求是：

• 我本來就是使用官方 vibe coding 工具
• 我有多個官方帳號 / 憑證
• 我希望把這些帳號放進 CLIProxyAPI 管理，可以依照既有 routing 策略自動切換到下一個帳號
• 不希望每次都要手動登出、登入或切換帳號

也就是說，我想讓 CLIProxyAPI 扮演「帳號池 / 憑證路由器」的角色，而不是「協定翻譯器」或「客戶端偽裝器」。

目前問題

目前 CLIProxyAPI 很強的一點是支援跨 provider / 跨 API surface 的翻譯，例如把某種格式轉成另一種 upstream 格式。這對相容性很有幫助。

但在官方 vibe coding 工具的使用情境下，我反而希望有一個更保守的模式：

• 保留官方工具送出的原始 API surface
• 保留原始 request body
• 不做跨 provider / 跨 surface 翻譯
• 不做 payload default / override / filter
• 不做 thinking 或其他 request mutation
• 只根據 CLIProxyAPI 選中的 credential 替換授權身分

也就是「原始內容直通，只替換身分授權」。

這樣是不是可以避免因為 proxy 額外改寫 request body、欄位、工具格式、stream 格式或 provider-specific payload，導致請求看起來不像原本官方工具送出的內容。

提議功能

新增一個全域 config：

native-passthrough: true

啟用後，CLIProxyAPI 會切換到新的 native passthrough pipeline，不再走原本的跨協定翻譯 pipeline。

映射如下：

輸入 API surface	允許的 upstream
openai	openai / codex
claude	claude
gemini	gemini
gemini-cli	gemini-cli

如果找不到對應 native upstream，應該直接回傳錯誤，例如：

native passthrough enabled, but no native upstream is available for this API surface/model

而不是 fallback 到其他 provider 或翻譯 pipeline。

如果 native-passthrough 未啟用，則維持目前既有的跨 provider / 跨 API surface 翻譯行為。