CC Switch 的 Provider 切換適合解決一個現實問題：同一台電腦同時使用官方服務、第三方 API 與本機模型時，手動修改多個客戶端設定很容易遺漏。正確流程是先跑通一個 Provider，再逐步加入本機接口與備用方案。
先建立單一 Provider
在 CC Switch 中選擇目標工具，例如 Claude Code 或 Codex，新增一個 Provider 後只設定一組 Base URL、API key 與模型。儲存後完全重啟終端與客戶端，送出一次簡單任務，確認確實由新 Provider 回應。
在此成功前，不要同時開啟代理、同步、多個模型別名與 fallback；變數太多會使排錯失去方向。
接入本機 OpenAI 相容 API
Ollama、LM Studio、vLLM 等服務能否接入，取決於是否提供與客戶端相容的接口，以及 Provider 設定是否允許自訂 Base URL 與模型名。檢查：
- 服務是否監聽在目前電腦可存取的位址；
- 模型名是否與服務實際暴露的名稱一致；
- 本機服務是否需要 key，或只接受本機請求；
- 上下文、併發與顯存是否足以支撐真實任務。
本機 API 的選擇與接入可看 本機大模型 API 給 Codex 使用教學；LM Studio 細節可看 LM Studio OpenAI 相容接口。
多 Provider 切換的實用策略
- 日常編碼：優先穩定、成本可預期的 Provider。
- 長任務或關鍵審查：手動切換到較強模型，不依賴隱式自動替換。
- 本機模型：用於隱私敏感、離線或低風險的固定步驟。
- 故障時：先看 Provider 健康狀態與配額，再切換，不要連續重試消耗額度。
若要將多個上游優先級與 fallback 統一到一個 endpoint，可把 CC Switch 與 9Router組合：CC Switch 管理客戶端，9Router 管理請求路由。
總結
Provider 切換的重點不是「能填多少位址」，而是每次切換都能確認生效。保留單一可驗證設定、重啟客戶端、核對模型名，再擴展到本機模型與多 Provider，最不容易出錯。
Provider 條目應包含什麼
為每個 Provider 建立清楚條目，至少標明用途、endpoint、模型名稱規則、驗證方式與驗證日期。不要只用「備用」「新 API」等名稱；幾週後你無法判斷它是否適合程式碼審查、是否支援工具呼叫，或是否仍有配額。
| 欄位 | 作用 |
|---|---|
| 顯示名稱 | 區分官方、團隊、本機與測試 Provider |
| Base URL | 記錄相容接口的根位址 |
| 模型名 | 避免客戶端別名與服務端名稱混淆 |
| 金鑰來源 | 只記存放位置或帳號，不寫進儲存庫 |
| 適用任務 | 日常開發、長任務、離線測試等 |
切換前後都要驗證什麼
切換前記錄目前 Provider 與模型，並保存一條不會修改檔案的測試任務。切換後檢查：回應是否來自預期模型、工具呼叫是否仍可用、專案目錄是否仍有正確權限、失敗時是否能讀到清楚錯誤。新 Provider 不相容時，就能立即回到已知正常設定。
對本機 OpenAI 相容服務，除了 Base URL 還要確認監聽網路位址。只在本機使用時，應優先繫結回環位址，避免意外暴露到區域網；需要其他裝置存取時，再另行考慮驗證與防火牆。
模型名和能力不相符的風險
接口相容不代表能力完全相同。有些服務可接受聊天請求，卻不支援工具呼叫、圖像、長上下文或客戶端所需的串流回應。應測試目標工作流，不要看到「OpenAI compatible」就把全部任務搬過去。
模型輸出異常短、工具呼叫格式錯誤或上下文很快溢出時，檢查模型能力、服務版本與上下文上限；不要只更換 API key。本機 vLLM 出現記憶體與 KV cache 問題時，可參考 vLLM KV Cache 記憶體排查。
費用與可觀測性
Provider 切換也要保留成本邊界。記錄每類任務預設使用哪個 Provider、失敗是否自動重試，以及呼叫日誌保留多久。對本機模型，決策時也應納入執行時間、耗電與人工維護；只比 API 單價並不完整。
FAQ：切換後為什麼仍是舊模型？
常見原因是舊終端尚未結束、專案級環境變數覆蓋、模型別名未更新，或客戶端快取了工作階段。建立新工作階段、重啟客戶端並查看請求日誌，通常能定位。
FAQ：可以匯入所有 API key 嗎？
只匯入實際需要且信任的帳號。管理工具與同步目錄都是高價值目標；開啟同步前先確認加密、存取權限與撤銷方式。