CC Switch 4.0 於 2026 年 10 月 4 日發布，19 天內推進至 v4.0.19，可管理的 AI 編程工具增至 12 款。專案累積 148,111 顆星標與 9,745 個分支，最近 75 個版本下載量約 2,163 萬次，4.0 版把配置寫入改為關鍵欄位替換。
CC Switch 4.0 是什麼？
CC Switch 是以 Rust 開發的桌面工具，集中切換 Claude Code、Codex 等工具的供應商，並管理 MCP 與 Skills。
儲存庫由開發者 farion1231 於 2025 年 8 月建立，採 MIT 授權，提供 Windows、macOS 與 Linux 三個平台的原生安裝檔。它的定位並非另一個編程代理，而是代理之上的配置層，處理供應商選擇、金鑰替換、協議轉換與用量統計這四件重複勞動。
專案主題標籤涵蓋 ai-tools、claude-code、codex、openclaw、opencode、mcp 與 skills，說明其範圍已從單一工具的外掛擴展到跨工具的中介層。設定資料集中存放在使用者家目錄的 .cc-switch 資料夾，主體為 SQLite 資料庫 cc-switch.db，另有 settings.json 記錄裝置層設定，以及預設每 24 小時執行一次、保留最近 10 份的備份目錄。
為何 AI 編程工具需要一層配置管理器？
三款工具分別以 JSON、TOML、YAML 描述供應商，換端點須手動改檔；MCP 與提示詞又分屬各工具，重複維護容易出現設定漂移。
問題的規模來自工具數量。同一名開發者往往同時使用命令行代理、桌面客戶端與多個供應商，每換一次模型或方案，就要在數個格式不同的檔案中同步端點、金鑰與模型名稱。手動編輯的風險不在於寫錯一次，而在於每次都要重新確認哪些欄位被覆寫、哪些自訂內容被清掉。
第二層問題是協議不相容。Claude Code 送出 Anthropic Messages 格式，Codex 使用 OpenAI Responses 或 Chat Completions 格式，供應商未必同時支援全部規格。若缺少一層轉換，能用的模型就被客戶端支援的協議限定，選擇空間因此被壓縮。
4.0 版的聚合模式解決什麼問題？
聚合模式把多家供應商的模型併入同一份模型清單，開發者選中哪個模型，請求就送往該供應商，不必離開客戶端回切換供應商，適用於單一工作階段內混用多家模型。
舊版的操作路徑是切換再工作：想用另一家的模型，必須回到 CC Switch 換供應商，再回到客戶端繼續。聚合模式把這個順序倒轉，模型清單直接出現在 Claude Code 或 Codex 的選擇器裡，每個模型名後標示來源供應商，說明欄列出上游真實模型識別碼與上下文視窗長度。
代價寫在官方文件裡。聚合模式本身不提供故障轉移，Claude Code 需 2.1.243 或更新版本，Codex 在模型清單變動後必須完整重啟。更關鍵的是工作階段中途換模型時，新模型要重建提示詞快取，切換後的第一輪費用會明顯上升，這個成本在長對話中尤其明顯。
配置寫入機制改動有何實際影響？
4.0 把切換供應商時的全量配置重寫改為關鍵欄位替換，只覆蓋端點、金鑰與模型，使用者自行加入的插件、鉤子、MCP 設定與註解得以保留，並在首次改寫前自動備份。
全量重寫的邏輯是「以新檔取代舊檔」，好處是實作簡單，代價是任何未經工具識別的欄位都會消失。當工具只在單一供應商之間輪替時，這個代價不明顯；但開發者在配置檔加入自訂鉤子、專案層級覆寫或註解時，每次切換都等於一次小型資料丟失。
關鍵欄位替換把影響面收窄到三個欄位，並在編輯器中預覽切換後的配置樣貌。備份策略同時提供兩層保障：改寫前的即時備份，以及每 24 小時一次、保留 10 份的週期備份。對長期在多個供應商之間切換的團隊，這個改動比任何新增功能都更直接地降低維護成本。
十二款工具的支援程度有何差異？
Claude Code、Codex 與 Gemini CLI 支援路由及托盤切換；OpenCode、Hermes 採共存模式，多家供應商同時寫入。
README 以「One App, Eleven Tools」列出十一款工具，而版本說明把 v4.0.18 加入的 Antigravity CLI 與 v4.0.19 加入的 Kimi Code 分別標為第十一與第十二個應用，兩處計數因此相差一項。這個細節反映專案的擴張速度：文件更新落後於版本發布，已成常態。
支援深度分兩層。第一層是可切換供應商的工具，切換會直接改寫配置，Claude Code 支援熱切換而無須重啟，Codex、Gemini CLI 與 Grok Build 需重啟終端或應用。第二層是共存模式，工具允許把多家供應商同時寫入自身配置，CC Switch 只負責新增、移除與設定預設，實際選擇在客戶端完成。
用量與額度統計如何運作？
用量頁在未開路由時掃描各工具的本機日誌，統計請求數、Token、快取命中率與花費；開啟路由後，相關請求一併計入。
統計分為三類。第一類是消耗量，涵蓋輸入、輸出、快取讀寫與首字延遲；第二類是額度，卡片與托盤直接顯示官方訂閱或編程方案的剩餘比例與重置倒數，例如「5 小時剩餘 94%」；第三類是帳戶餘額，適用於按量計費的供應商。
自訂價格是這套統計的必要條件。官方僅內建部分模型的價目，其餘可手動設定或從 models.dev 匯入；若不校準單價，花費欄位只能反映相對比例，無法用於預算控制。對以專案為單位計價的團隊，這一步不能省略。
十九天二十版與 2,163 萬次下載反映什麼？
從 v4.0.0 到 v4.0.19 共二十個版本，集中於十九天內發布，平均每日超過一版，反映更新頻率已跟上上游工具與供應商的變動速度。
這個節奏可以從版本內容讀出原因。v4.0.17 修復 4.0.16 帶來的托盤與記憶體問題，v4.0.18 加入 Antigravity CLI 支援並處理 macOS 金鑰圈讀取錯誤，v4.0.19 加入 Kimi Code 與多帳號登入。改版主軸並非新功能堆疊，而是追著上游工具與供應商的變動修正配置格式。
對使用者的實際含義是升級成本。桌面應用具備自動更新，但資料庫結構與設定檔格式會隨版本演進；官方文件明言命令列版本與桌面版共用資料目錄，若資料庫版本較新，命令列工具會提示需要升級或等待相容。跨版本降級因此不是可靠選項。
本地路由與故障轉移有什麼風險？
本地路由在本機轉發請求並轉換協議格式，可設定故障轉移佇列、斷路器與供應商健康檢查；風險在於金鑰與請求內容經過第三方程式處理，且多數官方供應商不支援此模式。
路由模式的價值在協議相容。它讓 Claude Code 使用 OpenAI 或 Gemini 格式的供應商，也讓 Codex 使用 Chat Completions 或 Anthropic Messages 的供應商，並在請求失敗時依佇列切換到下一家。這個能力解決了「模型可用但客戶端不支援」的斷層。
限制同樣明確。官方供應商多數不能經過本地路由，Codex 的 OpenAI 官方帳號是例外；路由服務需常駐執行，退出應用時會先寫回直連配置。此外，帳號功能處於測試階段，把 GitHub Copilot、ChatGPT 或 xAI 訂閱當作供應商使用，可能違反供應商條款，風險由使用者自行承擔。
如何快速開始使用 CC Switch？
macOS 用 Homebrew 安裝，Windows 取 MSI，Linux 需 WebKitGTK 4.1；首次啟動選供應商並填金鑰即可。
brew install --cask cc-switch
brew upgrade --cask cc-switch
先確認平台條件。Linux 需 x86_64 或 ARM64、glibc 2.35 以上與 WebKitGTK 4.1，對應 Ubuntu 22.04、Debian 12 與較新的 Fedora；RHEL、Rocky 與 AlmaLinux 8 至 9 尚未支援。Windows 支援 Windows 10 以上，macOS 支援 12 Monterey 以上，並通過簽章與公證。
首次啟動的順序建議由小到大。先新增一個供應商並填入金鑰，確認工具能正常回應；再開啟路由模式，驗證協議轉換是否符合預期；最後才設定故障轉移與聚合，並在每個階段確認備份目錄已生成。這個順序能把問題侷限在單一環節，避免一次導入全部功能後難以定位。
出處連結有哪些？
本文資料來源為 CC Switch 儲存庫、v4.0 與 v4.0.19 版本說明、官方網站文件，以及 GitHub API 取得的星標、下載與提交統計。
- GitHub 儲存庫：https://github.com/farion1231/cc-switch
- 官方網站：https://ccswitch.io
- v4.0 版本說明：https://github.com/farion1231/cc-switch/blob/main/docs/release-notes/v4.0.0-en.md
總結：CC Switch 適合哪些開發者？
適合同時使用多款 AI 編程工具、且經常更換供應商或方案的開發者與小團隊；若只固定使用單一工具與單一供應商，手動編輯配置檔仍是最低成本方案。
148,111 顆星標與十九天二十版的節奏，說明這個專案已站在 AI 編程工具生態的交會點。它解決的不是模型能力問題，而是工具碎片化帶來的配置成本；當生態中的工具數量繼續增加，這層中介的價值會同步上升。
需要留意的風險集中在兩處。其一是版本節奏快於文件，升級前應先確認資料庫相容性與備份狀態；其二是路由與帳號功能涉及金鑰與訂閱條款，採用前須評估合規與信任邊界。
對正在評估的團隊，務實做法是先以直連模式導入，觀察一個版本週期內的穩定性，再決定是否開啟路由與聚合。MIT 授權降低了試用成本，但長期成本取決於團隊能否跟上它的更新速度。
