说实话，我最初接触 Claude Code 时，心里的想法跟大多数人一样：这就是我理想中的编程搭档。它能直接驻留在终端里，读代码、改 diff、执行命令，还能帮你把整个重构流程跑完，这种体验是普通聊天界面给不了的。但用了大概两周后，我看到账单的时候整个人都不好了——按 token 计费，一次稍微大点的重构，会话还没聊完，几美元就没了。订阅方案也不是不行，但高频使用下来照样肉疼。
于是我开始研究社区里的省钱玩法，最后发现了一条实操性极强的路：用开源模型 Qwen3-Coder 把 Claude Code 的后端替换掉。注意，这里不是换一个套壳工具，而是让 Claude Code 这个客户端继续用，只是把请求转到本地模型上，这样一来既保留了 Claude Code 的交互方式和终端能力，又完全绕开了官方按量收费。折腾了一周，我把桌面端和 Ubuntu 服务器的方案都跑通了，下面把整个思路和踩过的坑完整写出来。
1. 先算一笔账：Claude Code 为什么“好用但烧钱”
1.1 官方定价逻辑：订阅与 API 各有什么坑
Claude Code 的定价模型并不复杂，但很多人一开始没意识到它有多“吃”钱。官方主要提供两种正规路径：一种是 Claude Pro 或 Max 订阅，绑定账号后直接使用 Claude Code；另一种是使用 Anthropic API，按 token 计费。订阅方式看似“包月”，但实际限额很微妙，高强度使用后会被限流，体验断崖式下跌。API 方式则完全是另一套逻辑，模型输入输出是持续计费的，尤其是当你把整个代码库都交给它读取上下文时，token 消耗非常惊人。
我做了一次简单统计：一个中等规模的 TypeScript 项目，每天大约 50 次对话式操作，包含代码阅读、重构、跑测试和修 bug，按我的习惯几乎全程让 Claude Code 自主执行，一天下来 API 费用在 3 到 8 美元之间浮动。这个数字看起来不多，但乘以一个月就是一笔很可观的支出。更关键的是，Claude Code 的工作方式决定了它特别能“烧上下文”——每次你让它查一个文件、改一个函数，它都会把相关代码片段拉进来，token 累积速度远高于普通聊天。
1.2 社区的答案：换模型服务，不换客户端
在搜解决方案的过程中，我发现社区里其实早有共识：Claude Code 本身只是一个壳，它调用的模型服务是可以被替换的。Claude Code 走的是 Anthropic 兼容的 API 协议，这意味着只要有一个服务能按照同样协议响应请求，Claude Code 就能正常工作。而开源社区早就有一批工具在做这件事，比如 cc-switch 就是专门用来切换 Claude Code 后端的工具，可以指向第三方模型服务，也可以指向本地的模型运行时。
这里要说明一下，我说的“换后端”不涉及任何违规操作，Claude Code 官方也预留了自定义接口的能力，允许开发者通过环境变量把请求指向其他端点。我们只是把这个能力用在了本地开源模型上。最终效果是：你还是在终端里使用 Claude Code 的命令、权限系统和对话体验，但真正生成代码的已经变成了你本地的 Qwen3-Coder 模型，流量根本不经过官方 API，自然也就没有按 token 计费这回事。
2. Qwen3-Coder 凭什么能顶上去
2.1 模型素质：代码专项能力不虚
Qwen3-Coder 是通义千问团队推出的代码专项模型，开源且支持商业使用，这一点非常重要——你不会被任何闭源协议卡脖子。目前常用版本包括 0.6B、4B、30B-A3B 和 235B-A22B 几个档位，其中 30B-A3B 是当前性价比最平衡的选择：它虽然总参数量是 30B，但采用了 MoE 结构，每次推理只激活其中的 3B 参数，所以实际运行速度比同尺寸稠密模型快很多，而代码理解能力、工具调用能力和多语言支持都保持了相当高的水准。
我自己实测的感受是，Qwen3-Coder 在代码补全、生成测试用例、解释陌生代码、做小型重构这些任务上表现非常自然，已经不是在“勉强能用”的及格线上，而是真的能作为日常主力使用。尤其是它对中国程序员常用技术栈的理解，比如 Spring Boot、Vue、Python FastAPI 这些组合，生成代码的风格很贴合本地习惯，几乎没有那种“翻译腔”。
2.2 硬件门槛：不同配置各取所需
不过本地运行模型是有硬件门槛的，这里要先泼一盆冷水：如果你指望在普通办公笔记本上跑 30B 级别的模型，体验不会太理想。我的建议是视自己的硬件条件选择模型档位：
| 模型版本 | 显存建议 | 内存建议 | 适合的使用场景 |
|---|---|---|---|
| Qwen3-Coder-0.6B | 2GB 以上 | 8GB | 极轻量代码补全、练手跑通流程 |
| Qwen3-Coder-4B | 4GB 以上 | 16GB | 日常小任务、单文件修改、写测试 |
| Qwen3-Coder-30B-A3B | 12GB 以上 | 32GB | 多文件重构、仓库级任务、主力开发 |
| Qwen3-Coder-235B-A22B | 48GB 以上 | 64GB | 高难度代码生成、接近商业模型体验 |
我的主力机器是一张 24GB 显存的显卡，跑 30B-A3B 版本非常流畅，生成速度可以接受，配合 Claude Code 的交互模式，整体体验已经非常接近原来用闭源 API 的感觉。如果你的机器只有 8GB 显存，那 4B 版本依然能完成为日常服务，只是大型重构的能力会弱一些。
3. 请求路径拆解：Claude Code 怎么才能不认识 Anthropic 服务器
3.1 环境变量是关键的“方向盘”
要让 Claude Code 把请求发到本地，核心是三个环境变量：ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN和ANTHROPIC_MODEL。这三个变量的作用可以用一个比喻说清楚：Claude Code 是个快递员，原本它每次都把包裹送到官方的仓库（Anthropic API），而ANTHROPIC_BASE_URL可以直接改写快递单上的地址；ANTHROPIC_AUTH_TOKEN是包裹的签收码，本地服务其实不校验真实身份，填什么都能签收；ANTHROPIC_MODEL决定你希望快递员把包裹交给哪条分拣线，也就是具体模型。
这个机制最妙的地方在于，Claude Code 的整个交互能力——比如它的命令、权限系统、diff 确认界面、自动执行工具——都是客户端功能，和模型服务完全解耦。所以当你把地址改到本地后，那些原本依赖官方订阅的登录校验也不再成为阻碍。换句话说，你不需要有 Anthropic 的付费账号，只要本地服务起来了，Claude Code 就能正常启动和工作。
3.2 协议兼容：Anthropic 协议和 OpenAI 协议之间有道坎
这里要提醒一个重点：很多本地模型工具默认只提供 OpenAI 兼容接口，比如 Ollama 和多数推理框架都是如此，但 Claude Code 说到底是 Anthropic 协议的客户端。两边协议虽然思想相近，请求和响应的结构却不同。如果直接把 Claude Code 指向一个只讲 OpenAI 协议的服务，就会碰到“语言不通”的问题。
解决方式有两种。一种是选用自带 Anthropic 兼容接口的本地服务，比如 LM Studio 比较新的版本，在开发者模式里就提供了一套 Anthropic 风格端点，Claude Code 可以直接连，不需要额外转化。另一种是使用开源社区写的协议转换层，比如 cc-switch 这类工具，它会在本地占用一个端口，对外模拟 Anthropic 协议，对内再把请求翻译成 OpenAI 协议转发给 Ollama 或其他后端。无论哪条路，本质都是解决“两种协议之间的翻译问题”，理解了这一点，后面配置起来就心里有数了。
4. 桌面端实操：LM Studio 一条龙跑通 Qwen3-Coder
4.1 第一步：装好 Claude Code 本体
我默认你已经在系统里安装了 Node.js，版本别太老，建议 18 以上。然后一条命令把 Claude Code 装到全局：
npm install -g @anthropic-ai/claude-code装完以后，在终端里敲claude应该能进入初始交互界面。第一次启动时它会要求身份验证，这很正常，因为我们还没有设置环境变量。这时候先不用管它，直接关掉，接着配置本地模型服务。
4.2 第二步：LM Studio 加载 Qwen3-Coder
打开 LM Studio，先在左侧导航进入模型市场，搜索qwen3-coder，你会看到几个版本。选哪个按第一节的硬件对照表来，我选的是Qwen3-Coder-30B-A3B-Instruct。点击下载后，等它拉到本地，然后进入 Chat 界面加载这个模型，先简单问一句“写一个 Python 快速排序函数”，确认响应正常。
关键步骤来了：LM Studio 切换到开发者视图，找到服务端设置。里面有个开关是用来启用本地 API 服务的，你要确保它处于打开状态，端口默认是1234。如果你的 LM Studio 版本较新，还能找到 Anthropic API 兼容选项，把它也打开，这会直接暴露一个 Claude Code 能听懂协议的服务端点。服务启动后，LM Studio 界面会显示服务的地址，一般是http://localhost:1234或者类似路径，把这段地址记下来，它就是我们需要填给ANTHROPIC_BASE_URL的值。
4.3 第三步：设置环境变量并启动
在 macOS 或 Linux 上，我习惯把这些环境变量写进当前终端会话。可以临时跑一下，也可以写进~/.zshrc或~/.bashrc里长期生效。Windows 用户的话，在 PowerShell 里用$env:语法设置。
export ANTHROPIC_BASE_URL="http://localhost:1234" export ANTHROPIC_AUTH_TOKEN="lm-studio" export ANTHROPIC_MODEL="qwen3-coder-30b-a3b-instruct" export ANTHROPIC_SMALL_FAST_MODEL="qwen3-coder-4b-instruct"Windows PowerShell 对应写法是：
$env:ANTHROPIC_BASE_URL = "http://localhost:1234" $env:ANTHROPIC_AUTH_TOKEN = "lm-studio" $env:ANTHROPIC_MODEL = "qwen3-coder-30b-a3b-instruct" $env:ANTHROPIC_SMALL_FAST_MODEL = "qwen3-coder-4b-instruct"这里有个细节：ANTHROPIC_SMALL_FAST_MODEL可以单独指定一个小模型。Claude Code 有些轻量任务（比如总结文件名、生成提交信息）会使用一个更快的模型，专门传一个 4B 版本给它是非常划算的选择。如果你不填这个变量，Claude Code 会默认使用主模型做所有事，反而拖慢速度。
设置完环境变量后，再次输入claude，这次它就不会再纠缠让你登录官方账号了，会直接进入工作界面。你可以在对话框里输入/status查看当前连接状态，如果显示连接到本地端点，并且模型名称正确，就说明整条链路已经通了。接着随便让它做一个实际操作，比如“帮我把当前目录下的某个函数改成异步写法”，看它是否正确读取文件并生成 diff。
4.4 一个验证连接是否正常的小技巧
有些人第一次配完，进入 Claude Code 之后发现模型只会说“我无法连接”，不要急着怀疑步骤，先用/doctor查环境。这个命令会列出当前 Claude Code 捕获到的环境变量，你一眼就能确认ANTHROPIC_BASE_URL有没有被正确读到。如果变量存在但报 404，那就去 LM Studio 里确认服务真的在运行且端口正确。如果报 401，就是ANTHROPIC_AUTH_TOKEN没设置或者写成了空的。排查顺序从环境变量开始，再到服务状态，基本不会卡太久。
5. Ubuntu 服务器方案：Ollama 起服务 + cc-switch 统一控制
5.1 无桌面环境下选 Ollama
如果你和我一样，主力开发环境是 Ubuntu 服务器，没有图形界面，那 LM Studio 就不合适了。我这边用的是 Ollama，它是个非常简洁的命令行推理服务，资源占用低，适合部署在 24 小时运行的机器上。安装就一行：
curl -fsSL https://ollama.com/install.sh | sh然后拉取模型：
ollama pull qwen3-coder:30b启动服务后，Ollama 默认监听11434端口，但它是 OpenAI 兼容协议。为了让 Claude Code 能连上，需要一个协议转换层。我实际操作时使用的是社区里比较成熟的工具 cc-switch，它的作用就是在本地开一个 CLI 层，专门接收 Claude Code 的请求，然后把请求转发给 Ollama，并且把响应再翻译回 Claude Code 能解析的格式。
5.2 cc-switch 配置流程
cc-switch 这类工具通常提供交互式命令来添加供应商。我把它当成一个“服务注册中心”，往里面添加一条本地 Ollama 记录，地址填http://localhost:11434，模型名填qwen3-coder:30b，然后选择启用。工具会告诉你它自己监听的端口，一般也是本地localhost上的某个端口。
接下来跟桌面端一样的思路，把ANTHROPIC_BASE_URL指向 cc-switch 的本地端口，ANTHROPIC_AUTH_TOKEN随便填一个非空值，然后启动claude。这套方案的好处是，以后你想换一个后端模型，不需要重新折腾环境变量，直接在 cc-switch 里切换供应商就行，特别适合那种“本地 30B 模型处理日常任务，偶尔切回远程供应商搞大重构”的混合工作流。
这里要插一句：cc-switch 并不只支持本地 Ollama，它也支持很多远程模型供应商，你可以把它理解成一个统一入口。但我的核心建议是，既然目标是省钱，只要本地模型能胜任的任务，就尽量留在本地；远程供应商可以作为备用，不要作为日常主力。
5.3 踩坑：Ollama 上下文长度对 Claude Code 体验的影响
在 Ubuntu 上跑 OLLama 方案的第一个坑，就是默认上下文长度。Claude Code 操作真实项目时，会发送大量代码片段作为上下文，如果 Ollama 的上下文窗口太小，模型很容易“失忆”，表现为前面刚讨论的结论后面就忘了，甚至生成的代码和需求对不上。我建议在启动 Ollama 时显式设置环境变量，比如OLLAMA_CONTEXT_LENGTH=32768，再重启服务，体感会好很多。
第二个坑是并发请求。Claude Code 经常会对模型发起连续请求，如果 Ollama 服务默认单请求排队，体验会比较卡。可以在启动命令里把并发数调高一些，但注意这同时会占用更多显存，要按显卡实际容量来控制。我的配置是同时运行 30B 模型和 4B 模型，显存总量 24GB 时有点吃紧，所以后来我把 4B 小模型也放到同一块显存里用低优先级缓存，效果还可以。
6. 真实体验：能匹配日常开发吗？以及我踩过的坑
6.1 和官方 API 的差距：没有想象中那么大
先说结论：用 Qwen3-Coder 替代官方后端之后，Claude Code 的核心体验是保留住的，包括命令面板、diff 确认、权限系统、工具调用这些都正常工作。日常开发里最常用的操作——读代码、写测试、补充注释、修复 lint 报错、生成提交信息——本地模型完成度很高，几乎没有让我觉得“换了模型就残废了”的感觉。
但差距是确实存在的。最明显的一点是：对于高度复杂、跨多个文件的架构级重构，Qwen3-Coder 的规划和推理深度不如官方旗舰模型。它更倾向于给出“看起来能跑、但不够优雅”的方案，需要你自己把关。另一个差距体现在长会话的稳定性上，官方模型在几十轮对话后还能保持对整体目标的理解，而本地模型如果上下文被稀释，会出现偏离原始需求的情况，这时候我一般会用/clear重置会话，再用简短的话把任务重新描述一遍。
6.2 权限系统与自动执行的正确打开方式
Claude Code 为了安全性，默认对终端命令、文件写入等操作有严格的权限控制，这在你接入本地模型后依然生效。我的建议是：不要因为追求自动化就把所有权限调成无脑放行。本地模型自己运行环境，安全性可以由你掌控，但代码被撤掉的风险依然存在——模型偶尔会生成错误的删除命令。我用的配置是保留文件编辑的确认权限，只对git status、ls、cat这类只读命令开启自动执行。
具体可以在 Claude Code 会话里输入/permissions，按提示设置哪些命令允许自动执行、哪些需要手动确认。经过一个月的磨合，这个状态是我个人觉得效率和安全平衡最好的。
6.3 常见报错与解决方案速查
我在折腾过程中整理了几个最常踩的报错，你如果也遇到同样情况，可以直接对照排查：
| 现象 | 可能原因 | 解决方式 |
|---|---|---|
| 启动后提示无法连接模型 | ANTHROPIC_BASE_URL没生效 | 检查环境变量是否在当前终端会话中已导出，用/doctor查看 |
| 返回 404 | 本地服务地址写错或端口没开 | 确认 LM Studio 或 Ollama 服务端真的在监听，客户端地址验证一次 |
| 返回 401 | ANTHROPIC_AUTH_TOKEN为空 | 随便填一个非空字符串，比如local |
| 模型响应很快但内容驴唇不对马嘴 | 上下文太短 | 调大 Ollama 的OLLAMA_CONTEXT_LENGTH；LM Studio 则在模型设置里增大上下文 |
| 速度慢到无法使用 | 模型档位偏高或内存不足 | 换小一号模型，或改用 MoE 架构版本 |
6.4 我的最终工作流
现在我的工作流基本固定下来了：日常开发、写测试、做小型重构，全走本地 Qwen3-Coder；遇到特别复杂的架构设计或代码迁移，我才会临时把供应商切回云端。桌面端用 LM Studio，Ubuntu 服务器用 Ollama 和 cc-switch，两边互不干扰。
最后说一个我实际使用中摸索出来的小技巧：如果本地模型在某次任务里始终不理想，不要急着换模型或调参数，先把任务拆小。Claude Code 最适合的方式不是让它一次完成“从零写一个完整模块”，而是让它连续处理多个小步骤——你先让它读某个文件并总结结构，再让它基于总结改某一个函数，最后让它补测试。这种循序渐进的使用方式，不仅大幅降低了本地模型的上下文压力，而且每一步都能及时止损，生成质量反而比一次性为难模型高很多。省钱的最终目标，其实不只是省下 API 账单，更是逼你理解工具的工作习惯，从而把它用到最顺手的样子。
