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 项目做对比配置方案完成同一组任务的总费用返工次数实际耗时全程顶级模型约 12 美元1 次45 分钟全程中等模型约 4 美元5 次2 小时 10 分混合路由方案约 5.5 美元1 次50 分钟你看全程中等模型确实省了钱但返工五次、多花了一个半小时这个时间成本换算成人力成本远远超过省下的那几美元。混合方案的费用只比全程中等模型多了 1.5 美元但效率和顶级模型几乎持平。2.2 模型分层策略基于上面的逻辑我把模型分成三层第一层主力推理模型。承担架构设计、复杂 bug 分析、多文件重构、代码审查这类任务。这一层我建议用当前你能 access 到的最强模型不要在这里省钱。具体选哪个取决于你的接入渠道但原则是推理能力优先价格其次。第二层日常执行模型。承担单文件修改、写测试、补注释、简单重构、格式化这类任务。这一层可以用性价比高的模型比如一些国产大模型或者中等价位的国际模型质量足够应付这些场景。第三层本地/免费模型。承担代码搜索、文件摘要、简单问答、批量重命名这类几乎不需要推理的任务。这一层用本地跑的模型就行零成本速度也快。关键问题是Claude Code 怎么知道该用哪一层这就涉及到配置机制了。2.3 Claude Code 的模型配置入口Claude Code 的模型配置主要通过几个途径生效我按优先级从高到低排环境变量ANTHROPIC_MODEL和ANTHROPIC_SMALL_FAST_MODEL这两个环境变量分别控制主模型和快速模型配置文件~/.claude/settings.json或者项目级的.claude/settings.json命令行参数启动时通过--model指定中间层路由通过自定义 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:7b7B 参数的模型在 16GB 内存的机器上跑起来没什么压力响应速度也还可以。如果你机器配置更好可以上 14B 甚至 32B 的版本质量会明显提升。然后在中间层配置里把本地模型的端点指向http://localhost:11434Ollama 默认监听这个端口。提示本地模型首次加载会比较慢因为需要把模型权重读进内存。建议在开始工作前先手动跑一次让它预热后面响应就快了。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-code5.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如果你只配了主模型没配smallFastModelClaude 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记录了每个配置项的作用和调整历史过几个月回头看也能快速想起来当时为什么这么配。