先说结论
我这边用下来大约五个多月，先给结论：
- 多家模型供应商时，更建议用 CLIProxyAPI。
- CC Switch 更适合供应商少、不想折腾的人：本地多套配置切换，上手快。
- CLIProxyAPI 名义上是做反向代理的，但拿来做多供应商管理同样非常好用——只是需要稍微折腾一下，在本地部署。
⚠️ Anthropic 官方账号反代，极易露头秒号！OpenAI、Grok 一般不管。
（至于谷歌，哈基米现在已经是路边一条了，封不封无所谓了😄）
写这篇的原因
看到有人在争论：用 CC Switch 好，还是用 CLIProxyAPI 好。
争论有道理——CC Switch 本身也带一定的反向代理能力，两边看起来都能「把流量转出去」，于是就容易吵成「二选一」。
目录
1. 表面互补，实际几乎可替代
从表面看，CC Switch 和 CLIProxyAPI 像是互补：一个偏本地切换配置，一个偏统一代理。
又因为 CC Switch 也有一点反代能力，更像「都能干一部分」，于是有人会觉得两者平级。
实际用下来：CLIProxyAPI 几乎可以完全取代 CC Switch。
CC Switch 主打的是多供应商时灵活切换配置；反向代理并不是它主推的能力。
问题在于：多供应商场景下，一旦你忘了在公用配置里把该同步的项写全，各家配置就会慢慢对不齐——可用模型、Codex 的 status line 等都会跟着飘——而且往往用一阵子才察觉。
2. 早期：CC Switch 怎么踩的坑
早期我用 CC Switch 管 Codex、Claude Code 的多家供应商，一家供应商一套配置。
能跑，但配置会越来越乱，尤其是供应商和模型都变多之后。
典型情况是这样：某家更新了模型（比如一家上了新版 GLM，另一家火山也有同类模型），你只改了其中一家在 CC Switch 里的配置，另一家忘了动。
一切换供应商，实际环境就变了：能用什么模型、界面怎么显示，都可能不同。
这种漂移不一定立刻炸给你看，经常是用了一段时间才反应过来——「怎么两套环境对不上」。
少量供应商、模型清单还简单时，CC Switch 完全够用。
供应商多、模型杂之后，维护成本会陡然升高：你以为在「切换供应商」，其实经常是在「切换整套可能已经过期的配置快照」。
3. 更推荐：适配放进 CLIProxyAPI
更稳的做法是把适配工作全部放进 CLIProxyAPI：
- 外面（Codex / Claude Code）只写、只维护一套配置
- 模型从哪家来、有几家供应商、失败怎么换、先走谁后走谁——都在 CLIProxyAPI 里配
对外部工具来说，永远只看见一个入口；供应商增减、模型改名，尽量只改代理层，而不是去同步 N 套客户端配置。
个人用了大约五个多月，两点建议：
- 务必开启粘性路由——同一会话尽量打到同一上游，少来回飘，行为更可预期。
- 用优先级排供应商——想先走谁、后用谁，用优先级调配即可，不必在客户端里来回改配置文件。
3.1 不一定都要「反代」：AI 供应商怎么加
CLIProxyAPI 里常见路径，是通过各厂商的 OAuth 等方式接入，再做反向代理后给外面用。
但如果你的某个供应商本身不需要反代——例如你手里是直接可用的 API Key + Base URL——也可以直接加到 AI 供应商里：
- 填好 API Key 和 Base URL
- 设好该供应商的优先级
- 和其它走 OAuth / 反代的上游一起，由 CLIProxyAPI 统一路由
这样：需要反代的走反代通道，不需要反代的走 API Key 通道，外面仍然只维护一套客户端配置。
这是给允许这种接法的供应商用的；Anthropic 官方账号仍见文首提醒。
4. 边界：高并发时别硬扛
CLIProxyAPI 适合「多供应商、统一入口、本地可控」这条线。
若你有高并发需求，不要硬扛 CLIProxyAPI，改用 Sub2API 这类更偏高并发场景的方案。
5. 收个尾
| 场景 | 更合适的选择 |
|---|---|
| 供应商少，不想部署代理 | CC Switch |
| 供应商多、模型杂，要一套配置管全局 | CLIProxyAPI |
| 高并发 | Sub2API |
| Anthropic 官方账号 | 不要反代 |
CC Switch 不是不能用，而是当配置套数和供应商数量一起涨时，忘同步的代价会被放大。
能接受本地多折腾一步部署 CLIProxyAPI，换来的是：客户端配置变简单，漂移变少，切供应商也不会默默换掉一整套过期设定。
争论「CC Switch 也有反代，是不是够了」时，可以再问一句：你是要偶尔切换几套配置，还是要长期管多家供应商还不想配置漂移？后者，我会选 CLIProxyAPI。