Claude Code混合模型配置：智能路由实现省钱又高效

1. 这套配置到底在解决什么问题

先把结论摆在前面：所谓"既聪明又省钱"的 Claude Code 模型配置，核心思路就一句话——把重活交给强模型，把杂活甩给便宜模型，中间用一层路由把请求分对地方。听起来像废话，但真正落地的时候，90% 的人要么全程用最贵的模型烧钱，要么为了省钱切到弱模型结果代码写得一塌糊涂，最后返工的时间成本比省下的 token 费还高。

我自己从 Claude Code 刚出来那阵就开始折腾，中间踩过的坑包括但不限于：在 Windows 上装完发现终端命令执行不了、配置了本地模型结果响应慢到怀疑人生、切换模型的时候把整个配置文件搞崩导致 CLI 直接罢工。所以这篇东西不是搬运官方文档，而是把我实际跑通并且稳定用了一段时间的一套方案拆开讲清楚，包括为什么这么配、每一步怎么操作、哪些地方容易翻车。

Claude Code 本质上是一个跑在终端里的 AI 编程代理，它能读你的项目文件、执行终端命令、修改代码、跑测试，甚至帮你提交 git。它的能力上限很大程度上取决于背后接的是什么模型。官方默认走的是 Anthropic 自家的模型，质量没得说，但价格也确实让人肉疼——尤其是你让它读一个大项目、反复迭代的时候，token 消耗速度非常快。

所以"聪明又省钱"的配置逻辑，不是找一个又便宜又强的模型（这种东西目前不存在），而是根据任务类型动态分配模型。具体来说：

• 架构设计、复杂重构、疑难 bug 排查：用最强的模型，这种任务省不得，一次做对比什么都重要
• 日常代码补全、简单修改、格式化、写注释：用便宜甚至免费的模型，质量够用就行
• 批量文件处理、代码搜索、简单问答：用本地模型或者低价 API，完全不心疼

这套思路落地需要三个东西配合：Claude Code 本身的配置机制、一个能做模型路由的中间层、以及你对不同模型能力的准确判断。下面逐个拆。

2. 模型选型的底层逻辑与成本账

2.1 为什么不能只用一个模型

很多人第一反应是"我就用一个中等价位的模型不就行了"。理论上可以，但实际操作中你会发现两个问题。

第一个问题是能力断层。中等价位的模型在处理简单任务时和顶级模型差距不大，但一旦遇到需要深度推理的场景——比如让你分析一个跨了五个文件的 bug、或者设计一个模块的接口——它就开始胡言乱语了。你花在纠正它错误上的时间，远超你直接用顶级模型一次做对的成本。

第二个问题是成本结构。API 计费是按输入 token 和输出 token 分别算的，而且输入 token 通常比输出便宜。Claude Code 的工作模式决定了它会频繁地把大量上下文（你的项目文件、之前的对话历史）塞进输入里。这意味着即使你用的是便宜模型，如果上下文管理不当，费用也会悄悄涨上去。

我实测过一组数据，拿一个中等规模的 TypeScript 项目做对比：

你看，全程中等模型确实省了钱，但返工五次、多花了一个半小时，这个时间成本换算成人力成本远远超过省下的那几美元。混合方案的费用只比全程中等模型多了 1.5 美元，但效率和顶级模型几乎持平。

2.2 模型分层策略

基于上面的逻辑，我把模型分成三层：

第一层：主力推理模型。承担架构设计、复杂 bug 分析、多文件重构、代码审查这类任务。这一层我建议用当前你能 access 到的最强模型，不要在这里省钱。具体选哪个取决于你的接入渠道，但原则是"推理能力优先，价格其次"。

第二层：日常执行模型。承担单文件修改、写测试、补注释、简单重构、格式化这类任务。这一层可以用性价比高的模型，比如一些国产大模型或者中等价位的国际模型，质量足够应付这些场景。

第三层：本地/免费模型。承担代码搜索、文件摘要、简单问答、批量重命名这类几乎不需要推理的任务。这一层用本地跑的模型就行，零成本，速度也快。

关键问题是：Claude Code 怎么知道该用哪一层？这就涉及到配置机制了。

2.3 Claude Code 的模型配置入口

Claude Code 的模型配置主要通过几个途径生效，我按优先级从高到低排：

1. 环境变量：ANTHROPIC_MODEL和ANTHROPIC_SMALL_FAST_MODEL这两个环境变量分别控制主模型和快速模型
2. 配置文件：~/.claude/settings.json或者项目级的.claude/settings.json
3. 命令行参数：启动时通过--model指定
4. 中间层路由：通过自定义 API 端点，让中间层决定实际调用哪个模型

前三种方式适合简单的单模型切换，但要做到"聪明又省钱"的动态路由，必须用第四种。这也是为什么很多人会提到 cc switch 这类工具——它的本质就是一个模型路由中间层。

3. 实操：从零搭一套混合模型配置

3.1 环境准备与安装

先确认你的基础环境。Claude Code 支持 macOS、Linux 和 Windows，但 Windows 上的体验明显不如前两者，主要问题是终端命令执行和路径处理经常出幺蛾子。如果你在 Windows 上，强烈建议用 WSL2，能省掉大量兼容性麻烦。

安装 Claude Code 本身很简单，Node.js 18 以上环境，然后：

npm install -g @anthropic-ai/claude-code

装完之后在终端输入claude就能启动。第一次启动会让你登录或者配置 API key。如果你用的是官方订阅，直接登录就行；如果你打算接第三方 API 或者本地模型，就需要配置自定义端点。

Ubuntu 上的安装基本一样，但要注意权限问题。如果你用sudo npm install -g装的，后面可能会遇到权限报错，建议用 nvm 管理 Node 版本，避免全局安装的权限问题。

macOS 上如果用 Homebrew 装的 Node，直接 npm 全局安装即可，一般不会有权限问题。

注意：安装完成后如果提示 "claude code might not be available in your country"，这通常是网络层面的问题，检查你的网络环境是否能正常访问所需服务。

3.2 配置中间层实现模型路由

这是整套方案的核心。中间层的作用是：接收 Claude Code 发来的请求，根据请求的特征（比如 token 数量、是否包含特定关键词、当前对话轮次）决定转发给哪个模型。

我用的方案是基于一个轻量的 API 网关来做路由。核心配置逻辑是这样的：

{ "routes": [ { "name": "heavy-reasoning", "match": { "max_tokens_gt": 4000, "contains_tools": true }, "target": { "provider": "anthropic", "model": "claude-sonnet-4-20250514" } }, { "name": "daily-coding", "match": { "max_tokens_lt": 4000, "contains_tools": true }, "target": { "provider": "deepseek", "model": "deepseek-coder" } }, { "name": "lightweight", "match": { "contains_tools": false }, "target": { "provider": "local", "model": "qwen2.5-coder:7b", "endpoint": "http://localhost:11434" } } ] }

这个配置的意思是：带工具调用且上下文超过 4000 token 的请求走顶级模型；带工具调用但上下文较小的走性价比模型；不带工具调用的纯文本请求走本地模型。

实际使用中你会发现，Claude Code 大部分请求都是带工具调用的（因为它要读文件、执行命令），所以本地模型那一层主要处理的是你直接问它问题的场景。

3.3 接入本地模型

本地模型这一层我用的是 Ollama 来跑。选 Ollama 而不是 LM Studio 的原因很简单：Ollama 的命令行接口更适合和 Claude Code 这种 CLI 工具配合，而且它在 Linux 上的稳定性明显更好。

安装 Ollama 之后，拉一个代码能力还行的轻量模型：

ollama pull qwen2.5-coder:7b

7B 参数的模型在 16GB 内存的机器上跑起来没什么压力，响应速度也还可以。如果你机器配置更好，可以上 14B 甚至 32B 的版本，质量会明显提升。

然后在中间层配置里把本地模型的端点指向http://localhost:11434，Ollama 默认监听这个端口。

提示：本地模型首次加载会比较慢，因为需要把模型权重读进内存。建议在开始工作前先手动跑一次让它预热，后面响应就快了。

3.4 VS Code 集成配置

如果你习惯在 VS Code 里用 Claude Code，配置方式略有不同。VS Code 插件版的 Claude Code 会读取工作区的.claude/settings.json，所以你可以在项目根目录放一个配置文件，让不同项目用不同的模型策略。

比如你有一个前端项目和一个后端项目，前端项目主要写 UI 组件，对推理要求不高，可以配便宜模型；后端项目涉及复杂业务逻辑，配强模型。这样切换项目的时候模型策略自动跟着变，不用手动改。

VS Code 里的配置大概长这样：

{ "model": "claude-sonnet-4-20250514", "smallFastModel": "deepseek-coder", "apiEndpoint": "http://localhost:8080/v1", "maxTokens": 8192, "temperature": 0.3 }

smallFastModel这个字段就是用来指定"快速模型"的，Claude Code 在处理一些轻量任务时会自动切换到它。把这里指向便宜模型，就能实现自动分流。

4. 不同场景下的模型切换策略

4.1 什么时候该切模型

配置搭好之后，实际使用中最关键的判断是：当前这个任务，值不值得用强模型？

我的经验判断标准是这样的：

• 需要跨文件理解的任务：用强模型。比如"帮我看看为什么这个 API 返回 500"，它需要读路由文件、控制器、服务层、数据库模型，这种跨文件推理弱模型很容易漏掉关键信息。
• 单文件内的修改：用中等模型。比如"把这个函数改成 async 的"，上下文就一个文件，中等模型完全够用。
• 纯文本生成：用本地模型。比如"给这个文件写个 README"，不需要理解代码逻辑，本地模型写得也不差。
• 批量操作：用本地模型。比如"把所有 console.log 删掉"，这种任务用强模型纯属浪费。

4.2 手动切换的快捷方式

虽然中间层能自动路由，但有时候你就是想强制用某个模型。Claude Code 支持在对话中通过命令切换：

/model claude-sonnet-4-20250514

或者

/model deepseek-coder

这个命令在调试的时候特别有用。比如你发现自动路由把某个任务分到了弱模型，结果质量不行，就可以手动切到强模型重试。

4.3 成本监控与调优

配好之后别就不管了，建议跑一周之后看看实际的花费分布。大部分中间层工具都带请求日志，你可以分析一下：

• 哪些请求走了强模型？这些请求真的需要强模型吗？
• 弱模型处理的请求里，有多少出现了质量问题需要重试？
• 本地模型的处理速度是否可接受？

根据这些数据调整路由规则。比如你发现某个类型的请求走弱模型经常出问题，就把它的匹配条件改到强模型那一组；反过来，如果某类请求走强模型但从来没触发过复杂推理，就把它降到弱模型。

我自己的调优结果是：大约 30% 的请求走了强模型，50% 走中等模型，20% 走本地模型。这个比例下，月费用比全程强模型省了大概 60%，而代码质量几乎没有下降。

5. 常见问题与排查实录

5.1 安装与启动问题

问题：Windows 上提示"由于与64位版本的 Windows 不兼容"

这个通常是因为 Node.js 版本或者架构不对。检查一下你装的是不是 32 位的 Node，卸载重装 64 位版本。另外确认你的 Windows 是 64 位的，32 位系统现在基本跑不了这些工具。

问题：执行终端命令时报 "internetopenurl() failed"

这是网络层面的问题，通常是代理配置或者防火墙拦截。检查你的系统代理设置，确保终端能正常访问外部服务。如果你在公司网络环境下，可能需要找 IT 确认防火墙规则。

问题：Ubuntu 上安装后提示权限不足

如果你用sudo npm install -g装的，普通用户可能没有执行权限。解决方案是用 nvm 重新装 Node，或者手动改 npm 全局目录的权限：

mkdir -p ~/.npm-global npm config set prefix '~/.npm-global' export PATH=~/.npm-global/bin:$PATH npm install -g @anthropic-ai/claude-code

5.2 模型配置问题

问题：配置了自定义端点但 Claude Code 还是走官方 API

检查环境变量是否生效。ANTHROPIC_BASE_URL这个变量控制 API 端点，如果它没被正确设置，Claude Code 会忽略你的配置文件直接走官方。在终端里echo $ANTHROPIC_BASE_URL确认一下。

问题：本地模型响应特别慢

几个可能的原因：模型太大内存不够（会触发 swap，速度暴跌）、Ollama 没有用 GPU 加速、并发请求太多。先确认你的机器内存是否足够，7B 模型至少需要 8GB 可用内存，14B 需要 16GB。如果有独立显卡，确认 Ollama 是否正确识别并使用了 GPU。

问题：切换模型后对话上下文丢失

这是正常行为。不同模型的上下文格式可能不兼容，切换时 Claude Code 会重置对话。所以尽量在一个任务开始时就确定好用什么模型，不要中途频繁切换。

5.3 使用中的坑

坑一：让弱模型做代码审查

我试过用中等模型做代码审查，结果它只看了语法层面的问题，完全没发现一个逻辑上的竞态条件。代码审查这种任务必须用强模型，因为它需要理解代码的意图和潜在的执行路径。

坑二：本地模型处理中文注释

大部分本地代码模型对中文的支持不如国际模型，写出来的中文注释经常有语法错误或者表达不自然。如果你需要生成中文文档，建议还是用强模型或者中等模型。

坑三：忽略 token 计费的输入部分

很多人只关注输出 token 的价格，忽略了输入 token。Claude Code 每次请求都会带上大量上下文，输入 token 的消耗量可能是输出的好几倍。优化上下文管理（比如及时清理不需要的对话历史、避免让它读无关文件）比换模型更能省钱。

坑四：配置文件格式错误导致 CLI 崩溃

JSON 配置文件对格式要求很严格，多一个逗号少一个引号都会导致解析失败。改完配置后先用cat ~/.claude/settings.json | python -m json.tool验证一下格式，确认没问题再启动 Claude Code。

坑五：忘记设置 smallFastModel

如果你只配了主模型没配smallFastModel，Claude Code 会用主模型处理所有任务，包括那些本来可以交给便宜模型的轻量任务。这个字段一定要配，能省不少钱。

6. 进阶：让配置更聪明的几个技巧

6.1 基于项目类型自动切换配置

如果你同时维护多个项目，可以在每个项目的.claude/settings.json里配不同的模型策略。Claude Code 会优先读取项目级配置，这样你cd到不同项目目录时，模型策略自动跟着变。

比如前端项目配便宜模型，因为大部分任务是写组件和样式；算法项目配强模型，因为需要深度推理。这个技巧能让你不用手动切换就实现"因地制宜"。

6.2 用提示词引导模型选择

中间层的路由规则除了看 token 数量和工具调用，还可以看提示词内容。比如你在提问时带上特定前缀，中间层识别到之后就走对应的模型。

我自己的习惯是：如果这个问题我知道需要深度思考，就在开头加[deep]，中间层看到这个标记就路由到强模型。不需要深度思考的就不加，走默认路由。这样比手动敲/model命令快得多。

6.3 定期更新模型列表

模型迭代速度很快，今天性价比最高的模型可能两个月后就被新的替代了。建议每个月花十分钟看看有没有新模型发布，测试一下它在你的典型任务上的表现，如果更好就更新配置。

我一般会关注几个维度：同等任务质量下的价格、响应速度、对代码的理解能力、工具调用的准确率。这四个维度综合下来，选出当前最优的组合。

6.4 缓存策略

Claude Code 支持 prompt caching，对于重复的上下文（比如你的项目结构说明、编码规范），可以缓存起来避免每次都重新计算。这个功能在官方 API 上是自动的，但如果你走第三方 API，需要确认中间层是否支持缓存透传。

开启缓存之后，重复上下文的输入 token 费用能降低不少，对于长期在同一个项目上工作的场景特别有用。

7. 我实际用下来的几点体会

这套配置我跑了大概三个月，中间调整过好几次路由规则。最大的感受是：省钱的关键不在于找到最便宜的模型，而在于让每个请求都用到刚好够用的模型。

一开始我总想把更多任务甩给便宜模型，结果频繁返工，反而更费时间和钱。后来把路由规则调保守了一点，让强模型处理的比例从 20% 提高到 30%，整体效率反而提升了，总费用也没涨多少。

另一个体会是本地模型的价值被低估了。虽然它处理复杂任务不行，但对于代码搜索、文件摘要、简单问答这些场景，它的表现完全够用，而且零成本、零延迟（本地跑没有网络往返）。我现在大概 20% 的请求走本地模型，这部分如果走 API 每个月也要花不少钱。

最后说一个容易忽略的点：配置文件要版本管理。你的模型路由配置、中间层配置、环境变量设置，这些都应该纳入 git 管理。换机器或者重装系统的时候，直接拉下来就能恢复，不用重新折腾一遍。我在.claude/目录下放了一个 README，记录了每个配置项的作用和调整历史，过几个月回头看也能快速想起来当时为什么这么配。