
最近在使用 claude-code 时,发现现有的路由方案(如 claude-code-router )在处理一些非原生模型时遇到了一些阻碍。
特别是在 DeepSeek 更新后,因为原有的路由方案采用了 Anthropic -> OpenAI -> Anthropic 的双向格式转换逻辑,导致在使用 DeepSeek (现在原生支持 Anthropic 格式)或者 Gemini 时,容易出现字段丢失(比如 easoning blocks )或者 400 错误。
为了解决这个问题,也为了让自己用得更顺手,我写了一个轻量级的替代方案。
项目地址: https://github.com/uzhao/code_switch NPM:npm install -g code-switch
设计思路:做减法 这个项目的核心逻辑是 “能不改就不改”。
原生优先( Pass-through ): 对于原生支持 Anthropic 格式的 Provider (比如 DeepSeek 的新接口,或者官方 API ),直接透传 Request Body 和 Headers 。这意味着不进行内部格式转译,避免了信息丢失,也保留了 claude login 生成的本地鉴权信息( Auth Tokens )。
异构模型交给 LiteLLM: 对于必须转换格式的模型(如 Gemini / OpenAI ),我没有自己造轮子去写转换逻辑,而是集成了 litellm 。这样稳定性更好,支持的模型也更多。
相比于原版 Router ,我去掉了什么?(局限性) 为了保持轻量和“无损”,我刻意砍掉了一些 CCR 具有的高级特性,如果你强依赖这些功能,建议继续使用原版 CCR:
没有 Prompt 强化/注入:CCR 会主动修改 System Prompt ,注入额外的指令来帮助一些较弱的模型更好地进行工具调用( Tool Calling )。我的工具只做透传,不做任何修改。这意味着如果模型本身智力不够,可能会出现不会调用工具的情况(当然,对于 Sonnet 3.5 / DeepSeek V3 / Opus 这个级别的模型通常不是问题)。
没有复杂的自动路由策略:CCR 包含了一些基于上下文长度或任务类型自动区分 Thinking 模型或长文本模型的逻辑。我的项目逻辑比较简单,主要依据你的配置或请求直接选择目标模型,不做过多的“智能”判断。
适合谁用? 苦恼于 DeepSeek / Gemini 兼容性报错的用户。
希望能够利用本地 Claude Pro 订阅凭据( Web Auth )的用户。
如何使用 安装:
Bash
npm install -g code-switch 运行:
Bash
code-switch 然后配置 claude-code 连接到本地端口即可。
1 prunusis OP 最初是作为 ccr 的 debug 工具开发的,只有读取 prompt 和 response 的功能,readme 都还没改. |