--- title: "GLM-5.1 接入 Claude Code 三件事:能不能切、值不值得切、什么时候别切" author: deletexiumu pubDatetime: 2026-04-10T08:40:00+08:00 featured: false draft: false tags: - Claude Code - 国内模型 - 模型对比 description: "GLM-5.1 原生支持 Anthropic 协议,只改一份 settings.json 就能把 Claude Code 的底层切到 GLM-5.1。本文基于 Z.AI 官方博客、HuggingFace README 和 anthropic.com 等一手来源,把接入配置、四模型 benchmark 对照、三档工作负载成本账一次算清,帮你决策能不能切、值不值得切、什么时候别切。" --- ![GLM-5.1 接入 Claude Code 三件事 · 时效时间轴](/blog/glm-5-1-claude-code-integration/cover.jpg) ## 1. 三条硬事实，一份没人看完的官方 README 2026-04-08，智谱 Z.AI 发布 GLM-5.1——754B 参数的 MoE 模型，MIT 协议完全开源，官方提供原生 Anthropic 协议（Claude Code 官方兼容接口）接入。中文技术圈当天刷屏的版本是"国产终于追平 Opus"。 先把三条硬事实钉在时间轴上： - **2026-04-08**：GLM-5.1 正式发布。SWE-Bench Pro 58.4 取得榜单 SOTA，比 Claude Opus 4.6 的 57.3 高 1.1 分。官方博客：`z.ai/blog/glm-5.1`。 - **2026-04-20**：Claude Haiku 3（`claude-3-haiku-20240307`）正式退役。仍在依赖这个模型的工作流必须迁移，官方来源：`platform.claude.com/docs/en/about-claude/model-deprecations`。 - **2026-04-30**：智谱 Coding Plan（智谱为 Claude Code 等编码工具提供的订阅额度）"非高峰期 1× 抵扣" 限时福利截止。过了这一天，GLM-5.1 的非高峰期消耗系数恢复到 2×，本文后面算的节省比例要相应打折。 锚点问题是：GLM-5.1 真的追平了 Opus 4.6 吗？把 HuggingFace `zai-org/GLM-5.1` 的完整 README 一条条翻完——答案比那条刷屏的结论复杂得多。GLM-5.1 只在 SWE-Bench Pro（+1.1）和 CyberGym（+2.1）微胜，而在 NL2Repo（自然语言转完整代码库的综合任务）上落后 Opus 4.6 整整 7.1 分，HLE（Humanity's Last Exam，综合推理基准）无工具版比 Gemini 3.1 Pro 少 14 分，KernelBench（GPU Kernel 优化基准）Level 3 的 GPU Kernel 优化也落后 Opus 约 17%。官方自己的用词是 "overall aligned with Claude Opus 4.6"——**对齐**，不是超越。 这篇文章聚焦三件事：把接入配置细到读者照抄就能跑，把 Benchmark 差距写清楚（含 GLM-5.1 输的那些指标），把"切 or 不切"的成本账算到一元为止。数据来自 Z.AI 官方博客、HuggingFace 权重页、`docs.bigmodel.cn`、`anthropic.com` 定价页和 Anthropic 模型退役页（截至 2026-04-10），作者未做个人运行验证。 --- ## 2. GLM-5.1 是什么：一张技术卡 先把技术规格摆清楚，只写 HuggingFace README 和官方博客明文确认的数字： - **总参数量**：754B - **架构**：`glm_moe_dsa`——MoE 结合 Dual Sparse Attention（来自官方博客） - **上下文窗口**：200K - **最大输出**：128K tokens - **License**：MIT（完全开源） - **训练**：异步 RL 基础设施，将 generation 与 training 解耦 - **本地推理支持**：vLLM（v0.19.0+）、SGLang（v0.5.10+）、xLLM、Transformers、KTransformers——**官方未提及 Ollama**。HuggingFace README 也没提 Ollama。如果某篇博客声称"ollama 一条命令跑 GLM-5.1"，请核对它是不是引用了某个第三方社区镜像。 - **权重**：`huggingface.co/zai-org/GLM-5.1`，BF16/FP8 双格式，同步上架 ModelScope - **API 渠道**：`api.z.ai` 和 `open.bigmodel.cn` - **发布时间**：2026-04-08 官方给的定位原话是 "next-generation flagship model for agentic engineering, with significantly stronger coding capabilities"——**为长链路的自主工程任务优化**，而不是为单次 benchmark 分数优化。 **"SWE-Bench Pro 58.4" 的含义要讲清楚**。这是当前 Agentic Coding 领域最受关注的 benchmark，GLM-5.1 以 58.4 vs Opus 4.6 57.3 取得 SOTA。关键词是 **SOTA**，但差距只有 1.1 分。在任何 benchmark 上，1-2 分的差距都不足以得出"碾压"结论——只能说 GLM-5.1 和 Opus 4.6 在这条赛道上并排。 **"原生 Anthropic 协议" 的工程意义**。这不是 LiteLLM 这类第三方代理层的协议翻译，而是 Z.AI 直接提供一个符合 Anthropic API 规范的 endpoint：`https://open.bigmodel.cn/api/anthropic`。前几代国产模型想接 Claude Code 都要走第三方代理层踩协议翻译的坑——GLM-5.1 第一次让"切底层模型"回落到"改一份配置文件"的重量级。读者不需要重装任何工具、不需要改一行业务代码，只要改一份 `settings.json`，把 `ANTHROPIC_BASE_URL` 指过去、再配好 API Key，Claude Code 就能无缝切到 GLM-5.1 的底层。 --- ## 3. 完整接入配置：从 0 到跑通 这一节是全文可执行性的核心，细到读者照抄就能跑通，不留任何配置坑。 ### 3.1 首次接入的完整配置 **第一步**：在 `bigmodel.cn` 注册账号 → 个人中心 → API Keys → 创建新 Key。新用户自带免费额度，先跑通流程再决定要不要订阅 Coding Plan。 **第二步**：编辑 `~/.claude/settings.json`，没有这个文件就新建一个： ```json { "env": { "ANTHROPIC_AUTH_TOKEN": "替换为你的智谱 API Key", "ANTHROPIC_BASE_URL": "https://open.bigmodel.cn/api/anthropic", "API_TIMEOUT_MS": "3000000", "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": 1, "ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-5.1", "ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-4.7", "ANTHROPIC_DEFAULT_HAIKU_MODEL": "glm-4.5-air" } } ``` 字段逐项解释： - `ANTHROPIC_AUTH_TOKEN`：填智谱 API Key。注意是 `AUTH_TOKEN`，不是 `API_KEY`，这是 Claude Code 的惯例字段名。 - `ANTHROPIC_BASE_URL`：**必须是** `https://open.bigmodel.cn/api/anthropic`。配错会触发 `1113 余额不足` 报错，这是 Z.AI 官方 FAQ 明文给的典型故障原因。也见过有文章写 `/api/coding/paas/v4` 的——那是错的，别抄。 - `API_TIMEOUT_MS`：`3000000` 毫秒 = 50 分钟。给长任务留够时间，避免 Claude Code 默认超时打断 8 小时级别的自主执行。 - `CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC`：关掉向 Anthropic 官方上报的 telemetry。你已经切到 Z.AI 了，没必要再往 Anthropic 发遥测。 - 三档模型映射：把 Claude Code 内部的 Opus / Sonnet / Haiku 等级路由到 GLM 系列对应档位。详见 §3.2。 **第三步**：确保 `~/.claude.json` 里有这一项，没有就新建： ```json { "hasCompletedOnboarding": true } ``` 这一项来自 Z.AI 官方配置文档。**不加它，首次运行 `claude` 会卡在 onboarding 页面**——因为 Claude Code 检测到 Base URL 不是官方的 `api.anthropic.com` 时，onboarding 流程里的某些校验会失败。显式置为 `true` 就能跳过。 **第四步**：终端运行 `claude`，发一句 `echo "Hello GLM-5.1"`，看是否能正常返回。能走完就是通了。 ### 3.2 模型映射策略：A 分层映射 vs B 全切映射 | 策略 | 配置 | 适用场景 | 成本特征 | |------|------|---------|---------| | **A. 分层映射（推荐）** | OPUS → `glm-5.1`
SONNET → `glm-4.7`
HAIKU → `glm-4.5-air` | 日常开发。让 Claude Code 自身的内部路由决定什么任务用 GLM-5.1、什么任务用 GLM-4.7、什么任务用 Air | 高峰期自动避开 GLM-5.1 的 3× 消耗 | | **B. 全切映射** | OPUS / SONNET / HAIKU 全部 → `glm-5.1` | 追求"GLM-5.1 体感"一致性，或在非高峰时段集中跑高难任务 | 只有福利期内的非高峰期划算（1× 抵扣） | Z.AI 官方 FAQ 最新版推荐的是**策略 A 分层映射**，理由是 GLM-4.7 对标 Sonnet 级、日常任务性价比最优。为保守起见（避免低估 Opus 对照），§6 的所有成本测算一律按 GLM-5.1 单价估算。真实分层映射下 Sonnet / Haiku 级任务会路由到更便宜的 GLM-4.7 和 GLM-4.5-air，实际成本会进一步低于本文示例。 注意：官方两份文档（`docs.bigmodel.cn/cn/coding-plan/tool/claude` 和 `docs.bigmodel.cn/cn/coding-plan/faq`）对 SONNET 映射默认值给的是不同答案——前者给 `glm-4.7`（默认）或 `glm-5-turbo`（高阶），后者给 `glm-4.7`。两种都能跑，本文按更新更近的 FAQ 推荐走 `glm-4.7`。 ### 3.3 Claude Code v2.1.69 的已知 BUG 与绕过方案 Z.AI 官方文档明确记录：**Claude Code v2.1.69 接入非 Anthropic 官方 endpoint 时存在 BUG**，表现为 tool search 相关的 experimental beta 特性异常。绕过方法是在启动 `claude` 之前设置两个环境变量： ```bash export ENABLE_TOOL_SEARCH=0 export CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 ``` 或者直接把这两项塞到 §3.1 的 `settings.json` 的 `env` 段里，合并后的完整版是这样： ```json { "env": { "ANTHROPIC_AUTH_TOKEN": "替换为你的智谱 API Key", "ANTHROPIC_BASE_URL": "https://open.bigmodel.cn/api/anthropic", "API_TIMEOUT_MS": "3000000", "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": 1, "ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-5.1", "ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-4.7", "ANTHROPIC_DEFAULT_HAIKU_MODEL": "glm-4.5-air", "ENABLE_TOOL_SEARCH": "0", "CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS": "1" } } ``` 推荐版本是 **v2.1.42**（Z.AI 官方标注已验证稳定），或者 `claude update` 到最新版后自行验证一下基础路径。 ### 3.4 常见报错快速排查 | 报错/现象 | 原因 | 解决 | |---------|------|------| | `1113 余额不足` | Base URL 配错（最常见），或在不受支持的工具里用 Coding Plan 套餐 | 确认 Base URL 为 `https://open.bigmodel.cn/api/anthropic`；确认你用的是 Claude Code、Cline、Roo Code、OpenCode 等官方支持列表里的工具 | | 首次启动卡在 onboarding 页 | 缺 `hasCompletedOnboarding` | 手动编辑 `~/.claude.json` 加上 `"hasCompletedOnboarding": true` | | 长任务中断、超时 | 默认 timeout 太短 | 确认 `API_TIMEOUT_MS` 为 `"3000000"`（毫秒，即 50 分钟） | | v2.1.69 tool search 异常 | Claude Code 版本 BUG | 设置 `ENABLE_TOOL_SEARCH=0` 和 `CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1` | 这四条是配置阶段 90% 的坑。把它们处理完，Claude Code 就能稳定跑在 GLM-5.1 的底层上了。 --- ![四模型 Benchmark 对照(数据来源:HuggingFace zai-org/GLM-5.1 README)](/blog/glm-5-1-claude-code-integration/benchmark.jpg) ## 4. 官方 Benchmark 全貌：四模型六项对照 中文技术圈很少有人把 HuggingFace `zai-org/GLM-5.1` 的完整 README 表从头到尾翻一遍——因为翻完之后那句"吊打 Opus"就成立不了。这一节的价值就是把原表摆出来，包括 GLM-5.1 输的那些指标。 ### 4.1 完整对照表（来源：HuggingFace `zai-org/GLM-5.1` README） **第一组：统一口径（跨模型可直接比较）** | Benchmark | GLM-5.1 | Claude Opus 4.6 | Gemini 3.1 Pro | GPT-5.4 | 备注 | |-----------|---------|-----------------|----------------|---------|------| | **SWE-Bench Pro** | **58.4** | 57.3 | 54.2 | 57.7 | GLM-5.1 SOTA，+1.1 vs Opus | | **CyberGym** | **68.7** | 66.6 | — | — | GLM-5.1 +2.1 vs Opus | | NL2Repo | 42.7 | **49.8** | 33.4 | 41.3 | **Opus 领先 GLM +7.1** | | HLE（无工具） | 31.0 | 36.7 | **45.0** | 39.8 | Gemini 领先 GLM +14.0 | | HLE（w/ Tools） | 52.3 | **53.1** | 51.4 | 52.1 | 四家接近，Opus 微胜 0.8 | | **Terminal-Bench 2.0（Terminus-2 裸口径）** | 63.5 | 65.4 | **68.5** | — | Gemini > Opus > GLM | | KernelBench Level 3（GPU Kernel，几何均值） | 3.6× | **4.2×** | — | — | Opus 领先约 17% | **第二组：agent harness（agent 执行环境/工具链壳）自报口径（跨 harness 不可直接比较）** | Benchmark | 模型 | 分数 | harness 说明 | |-----------|------|------|-------------| | Terminal-Bench 2.0 | GLM-5.1 | **69.0** | Claude Code harness | | Terminal-Bench 2.0 | GPT-5.4 | **75.1** | Codex harness | **一条关键的读表规则**：只有第一组的数字可以跨模型直接减法比较。第二组的 69.0 和 75.1 是在各自 agent harness 下自报的成绩——就像一场比赛一个选手穿跑鞋、另一个穿钉鞋，数字放在同一列里直接相减就是误导。中文圈最近几天有几篇稿子把 69.0 直接对比 75.1，算出"GPT-5.4 领先 6.1 分"——这是典型的跨 harness 误读。 ### 4.2 诚实解读 **GLM-5.1 真实胜出的场景**：SWE-Bench Pro（+1.1）、CyberGym（+2.1）。两条都是微胜，不是碾压。 **Opus 4.6 仍然领先的场景**：NL2Repo（+7.1）、HLE w/ Tools（+0.8）、KernelBench Level 3 的 GPU Kernel 优化（4.2× vs 3.6×，领先约 17%）。其中 NL2Repo 的 7.1 分差距非常大——这个 benchmark 考察的是"自然语言需求 → 真实代码仓库级别实现"的综合能力，直接对应"大型代码库综合重构"这类场景。**如果你的主要任务就是带着完整仓库上下文做大重构，Opus 4.6 仍然明显更强**。 **Gemini 3.1 Pro 是这张表里容易被忽略的位置**。Terminus-2 裸口径上 Gemini 是 68.5，比 Opus 的 65.4 高 3.1 分、比 GLM 的 63.5 高 5 分。HLE 无工具版上 Gemini 45.0 领先 GLM-5.1 整整 14 分。想做"裸脑力的纯推理任务"，Gemini 3.1 Pro 在一手数据上是前沿。 **HLE 的双口径是最有意思的一组**。GLM-5.1 的 HLE 无工具版只有 31.0，明显落后。但 HLE w/ Tools 版跳到 52.3，追平 GPT-5.4（52.1），只落后 Opus 4.6（53.1）0.8 分。这个对比告诉我们：**GLM-5.1 的"裸脑力"偏弱，但工具链协同能力很强**。对 Claude Code 用户而言这是正面信号——Claude Code 本身就是个工具密集的 agent harness，GLM-5.1 在这类环境下的表现会更接近它的 HLE w/ Tools 数据，而不是 HLE 无工具数据。 ### 4.3 三句话总结 不要因为 "SWE-Bench Pro SOTA" 就以为 GLM-5.1 全面超越 Opus 4.6——它没有，差距只有 1.1 分，而且在 NL2Repo、KernelBench、Terminus-2 上仍然落后。 不要因为 HLE 无工具版落后就否定 GLM-5.1 的工程价值——它在工具链密集的 agent harness 下能追平前沿。 **官方原话是"overall aligned with Claude Opus 4.6"——对齐，而不是超越。**这句话比任何中文标题都更精准。 --- ![8 小时自主执行的三大官方场景对比](/blog/glm-5-1-claude-code-integration/scenarios.jpg) ## 5. 8 小时自主执行：官方三大长任务场景 Benchmark 是单次任务加固定上下文，而真实开发是长链路加不断增长的上下文。长链路会暴露一组 benchmark 分数根本反映不出来的问题：上下文漂移、策略早期枯竭、工具调用堆积、错误传播。Z.AI 把 GLM-5.1 的核心定位放在解决前代模型的 **"Plateau Problem"**——模型跑几十轮后策略就停滞，没法继续优化。官方博客给出了三个长任务场景，每一个都比 benchmark 分数更能说明"能不能干活"。 ### 5.1 场景 1：向量数据库优化，600+ 轮迭代，6× QPS 提升 - 任务：持续优化某向量数据库的查询性能 - 基线：50 轮短任务的最佳 QPS 约 **3,547** - GLM-5.1 执行：**600+ 轮自主迭代 + 6,000+ 工具调用** - 最终结果：**21,500 QPS，约 6× 提升** - 一手来源：Z.AI 官方博客 `z.ai/blog/glm-5.1` 官方描述的关键能力是"在关键节点切换策略"——当一条优化路径收益递减时，GLM-5.1 会主动识别结构性瓶颈并换方向，而不是在同一条路径上反复微调到天荒地老。这是 Plateau Problem 的直接解法：50 轮任务的短窗口让前代模型只能在局部极值附近打转，600+ 轮窗口下模型有空间退回去重写索引结构、换量化方案、调整召回策略。这种"跨阶段切换"的能力，正是 benchmark 分数表达不出来的那一层。 这个场景也是中文圈转发得最多的一条，但很多二手报道把数字写成了"178 轮 1.5×"（典型如 MarkTechPost），和官方数据相差近一个数量级。**以官方博客的 600+ 轮 6× 为准**。 ### 5.2 场景 2：GPU Kernels 优化，1,000+ 轮迭代，Opus 4.6 领先 这是官方博客里少有的"Opus 仍然赢"的场景，必须原样呈现。 - 任务：KernelBench Level 3 上的 GPU kernel 优化 - GLM-5.1：3.6× 加速（50 个问题的几何均值） - Claude Opus 4.6：**4.2× 加速**（比 GLM-5.1 高约 17%） - 官方原话：`GLM-5.1 sustains useful optimization for substantially longer than GLM-5` 注意官方这句话里对比的是前代 **GLM-5**，不是对比 Opus。GLM-5.1 相对前代解决了 Plateau Problem，但在专业领域的 kernel 优化上，Opus 4.6 仍然是那个更强的选手。这对读者的决策含义很具体：**如果你的日常工作涉及 CUDA kernel、自定义算子、性能调优内核代码，别切 GLM-5.1**。 ### 5.3 场景 3：从零构建 Linux 桌面 Web App，8 小时连续执行 - 输入：一句自然语言 prompt，无起始代码 - 运行方式：8 小时连续循环，每轮之间模型自我审查 - 最终产出：一套完整的浏览器内 Linux 桌面环境，包含文件浏览器、终端、文本编辑器、系统监视器、计算器、几个小游戏 这个场景展示的是"从零到一的持续工程化能力"。没有 scaffolding、没有中途人工干预、没有任务分解模板——一句话进、一个可用产品出。这一条在 benchmark 表里找不到对应项。 ### 5.4 三个场景给出的决策信号 这三个场景不是 benchmark 的冗余数据，而是 benchmark 的补集——向量 DB 场景考察"跨 600 轮的策略切换"、GPU Kernel 考察"专业领域的极限工程精度"、Linux 桌面考察"零上下文的从零到一"。三者对应的恰好是三种 benchmark 无法覆盖的维度：**长程稳定性、专业深度、零冷启动**。 - **适合切换到 GLM-5.1**：需要长时间迭代的优化任务、探索性开发、长链路任务 + 成本敏感 - **继续用 Opus 4.6**：GPU kernel 和内核优化、NL2Repo 类大型代码库综合重构、对"裸脑力推理"要求极高的场景 - **两个都能胜任**：日常 bug 修复、中等复杂度的 feature 开发、文档/注释生成、CI 脚本等常规工作 这三类的分工建议是后面 §6 混合路由成本模型的基础。 --- ![三档工作负载月度成本对照(基于 5/25 美元 Opus 定价 + 6/24 元 GLM 定价)](/blog/glm-5-1-claude-code-integration/cost.jpg) ## 6. 成本决策模型：基于一手定价的三档示例测算 这一节完全用 Anthropic 官网给的 Opus 4.6 一手定价和 bigmodel.cn 的 GLM-5.1 定价页重算。之前中文圈流传的那组"Opus 一个月 4 万元"的数字是基于错误的 $15/$75 单价——这是凭记忆猜的错数，正确定价是 $5/$25，低了 3 倍。 ### 6.1 单位成本对照 | 维度 | Claude Opus 4.6 | GLM-5.1（0-32K） | GLM-5.1（32K+） | |------|-----------------|------------------|-----------------| | 输入（每百万 tokens，USD） | **$5** | — | — | | 输出（每百万 tokens，USD） | **$25** | — | — | | 输入（CNY，按 ~7.25 汇率示例） | ~36.25 元 | **6 元** | 8 元 | | 输出（CNY） | ~181.25 元 | **24 元** | 28 元 | | 200K+ 上下文溢价（Opus 1M beta） | $10 输入 / $37.50 输出 | — | — | **定价一手来源**： - Claude Opus 4.6：`anthropic.com/news/claude-opus-4-6`，原文 "Pricing remains the same at $5/$25 per million tokens"。超 200K 上下文的 1M beta 区段适用 $10/$37.50 溢价。 - GLM-5.1：`bigmodel.cn/pricing`。 - 汇率按 ~7.25 CNY/USD 示例换算，实际以当前汇率为准。 GLM-5.1 输入约为 Opus 的 1/6，输出约为 1/7.5——这是节省比例的硬底。 ### 6.2 Coding Plan 订阅配额 对于订阅制的读者，Z.AI Coding Plan 的配额来自官方 FAQ： | 套餐 | 每 5h 限额 | 每周限额 | MCP 月度配额 | |------|----------|---------|-------------| | Lite | ~80 prompts | ~400 prompts | 100 次 | | Pro | ~400 prompts | ~2,000 prompts | 1,000 次 | | Max | ~1,600 prompts | ~8,000 prompts | 4,000 次 | 一次 prompt 大约触发 15-20 次模型调用。官方 FAQ 原话形容 Coding Plan "相当于月订阅费用的 15-30 倍 token 额度"——这是一种大幅折扣，不是加价。三档月度订阅价格官方定价页未直接列出，需要登录 `bigmodel.cn` 后台查看当前报价。 ### 6.3 三档示例工作负载的月度测算 **假设前提（显式声明，避免读者误以为是官方统计）**： - 工作日约 22 天/月 - Opus 4.6 与 GLM-5.1 tokens 消耗相同（忽略模型差异导致的 token 密度差） - GLM-5.1 用 0-32K 档定价（6 元 / 24 元） - **本示例一律按 GLM-5.1 单价估算，不区分分层映射**（真实分层路由下 Sonnet / Haiku 级任务走更便宜的 GLM-4.7 / GLM-4.5-air，实际成本会更低，保守估算不影响"切 or 不切"的结论） - 所有数字仅作**示例测算**，不代表任何读者的真实账单 **示例 A：轻度工作负载**（每日 2M input + 0.5M output） - Opus 4.6：22 × (2 × 36.25 + 0.5 × 181.25) ≈ **3,588 元 / 月** - GLM-5.1：22 × (2 × 6 + 0.5 × 24) ≈ **528 元 / 月** - 节省约 **85%** **示例 B：中度工作负载**（每日 8M input + 2M output） - Opus 4.6：22 × (8 × 36.25 + 2 × 181.25) ≈ **14,355 元 / 月** - GLM-5.1：22 × (8 × 6 + 2 × 24) ≈ **2,112 元 / 月** - 节省约 **85%** **示例 C：重度工作负载**（每日 20M input + 5M output） - Opus 4.6：22 × (20 × 36.25 + 5 × 181.25) ≈ **35,888 元 / 月** - GLM-5.1：22 × (20 × 6 + 5 × 24) ≈ **5,280 元 / 月** - 节省约 **85%** 三档的节省比例都是 85%，因为 GLM-5.1 对 Opus 4.6 的单位成本比例基本不随调用量变化。差别只在绝对金额——轻度每月差约 3,060 元，重度每月差超过 3 万元（精确值约 30,608 元）。 ### 6.4 混合路由示例：比"全切"更明智的方案 全切 GLM-5.1 不是最优解。把关键场景（NL2Repo 类大型重构、GPU Kernel、需要最好裸脑力的推理）留给 Opus 4.6，日常切给 GLM-5.1——这种混合路由在多数场景下是更好的选择。 **以示例 B 中度工作负载为例，80% GLM-5.1 + 20% Opus 4.6**： - 成本：0.8 × 2,112 + 0.2 × 14,355 = 4,560.6 ≈ **4,561 元 / 月** - vs 纯 Opus 基线 14,355 元：节省约 **68%** - vs 纯 GLM 方案 2,112 元：月均多花 ~2,449 元换取 Opus 的质量兜底 4,561 元是混合路由的平衡点：关键场景保留 Opus 的质量兜底，占 80% 时间的日常任务压到 GLM-5.1 的成本线上。对大多数 Claude Code 用户来说，这比"情绪化全切"更划算。 ### 6.5 消耗系数与时段策略 Coding Plan 订阅制的读者需要额外注意消耗系数——它会直接改变决策。 - **高峰期**（每日 14:00–18:00 UTC+8）：GLM-5.1 / GLM-5-Turbo 按 **3× 消耗** - **非高峰期**：按 **2× 消耗** - **限时福利**（截至 **2026-04-30**）：非高峰期 GLM-5.1 / GLM-5-Turbo 恢复到 **1× 消耗** 换算到 Max 套餐的 8,000 prompts/周： - 非高峰期福利期全用 GLM-5.1：等效 8,000 prompts 额度 - 高峰期全用 GLM-5.1：只能跑约 2,666 prompts（除以 3） 具体策略：高峰期让 Claude Code 路由到 GLM-4.7（分层映射会自动做这件事），非高峰期才跑 GLM-5.1 的重任务。4 月 30 日之前是性价比最高的窗口——过了这个日期，非高峰系数恢复到 2×，上面测算的成本优势要相应打折。 --- ## 7. 诚实的局限：GLM-5.1 不建议切换的场景 这一节不写主观猜测，只写有一手证据的局限。 ### 7.1 Benchmark 上 GLM-5.1 明确落后的指标 - **NL2Repo 落后 Opus 4.6 共 7.1 分**：这是"自然语言 → 代码库"的综合任务，直接对应大型代码库综合重构场景。差 7 分是结构性差距，不是数据抖动。 - **Terminus-2 裸口径落后 Gemini 3.1 Pro 5 分、落后 Opus 1.9 分**：纯 terminal 交互能力上 GLM-5.1 是对照组的末位。 - **HLE 无工具版落后 Gemini 3.1 Pro 14 分**：说明 GLM-5.1 的"裸脑力"明显弱于 Gemini 前沿。 - **KernelBench Level 3 落后 Opus 4.6 约 17%**（3.6× vs 4.2×）：专业 GPU Kernel 优化 Opus 仍然更强。 ### 7.2 工具链与版本兼容（来自 Z.AI 官方 FAQ） - Claude Code v2.1.69 存在 BUG，必须通过 `ENABLE_TOOL_SEARCH=0` 和 `CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1` 绕过。 - Coding Plan 套餐仅限 Claude Code、Cline、Roo Code、OpenCode、TRAE、Kilo Code、CodeBuddy、OpenClaw 等官方支持列表里的工具。在上述工具外直接调 API，套餐额度不抵扣，走按量计费。 - "1113 余额不足"报错通常是 Base URL 配错或工具不在支持列表。 - 套餐不支持退款。额度耗尽后 5 小时周期内不会自动扣账户余额。 ### 7.3 时段与时效 - 高峰期 14:00-18:00 UTC+8 跑 GLM-5.1 按 3× 消耗，会快速烧光订阅额度。 - 非高峰期 1× 抵扣福利截至 2026-04-30。过期后非高峰系数恢复到 2×，本文 §6 的成本测算要相应打折。 - 本文所有配置、定价、模型 ID 基于 2026-04-10 状态，后续以 `docs.bigmodel.cn` 和 `anthropic.com` 官方页为准。 ### 7.4 明确不建议切换的场景清单 - 每天的主要任务是大型代码库综合重构（NL2Repo 落后 7.1 分） - GPU Kernel、CUDA、自定义算子、内核优化（KernelBench 落后 17%） - 纯推理类、对"无工具裸脑力"要求最高的任务（HLE 无工具落后 14 分，Gemini 3.1 Pro 更合适） - 每天必须在 14:00-18:00 高峰时段集中工作（订阅制下 3× 消耗不划算） - 长期项目里依赖 Opus 4.6 的风格稳定性，不愿承担模型行为差异的场景 对有 Opus 忠诚度的读者还有一条安抚信息：Anthropic 官方模型退役页给出的 Opus 4.6 最早退役保障日期是 **2027-02-05**，至少还有 10 个月的稳定期，不用急着做二选一的抉择。 --- ## 8. 行动清单：10 分钟 / 1 小时 / 真切换 ### 8.1 10 分钟级：跑通 Hello World 1. 注册 `bigmodel.cn` 账号，创建 API Key 2. 按 §3.1 配置 `~/.claude/settings.json` 和 `~/.claude.json` 3. 终端运行 `claude`，发送一句 `echo "Hello GLM-5.1"` **成功判定**：在 Claude Code 中运行 `/status` 命令，能看到当前模型映射为 `glm-5.1` / `glm-4.7` / `glm-4.5-air`，首次发送的测试消息收到正常返回。 **失败排查**：`1113` 报错 → 检查 Base URL 是否为 `https://open.bigmodel.cn/api/anthropic`。卡在 onboarding 页 → 检查 `~/.claude.json` 是否含 `hasCompletedOnboarding: true`。v2.1.69 工具异常 → 设置 `ENABLE_TOOL_SEARCH=0` 和 `CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1`。 ### 8.2 1 小时级：做一个配置验证任务 1. 选一个 Claude Code 最擅长的轻量场景：读取几个源文件、生成一段 TypeScript 类型定义、跑一次简单 refactor 2. 观察 GLM-5.1 的输出风格、工具调用节奏、代码质量 3. 用 3-5 轮连续对话，看它的上下文保持能力 **成功判定**：能完成 1-3 轮连续对话无 timeout，生成的代码能跑、工具调用行为合理、和 Claude Code 原生 Opus 的体感没有显著断层。 **失败排查**：长对话 timeout → 检查 `API_TIMEOUT_MS` 为 `"3000000"`。工具调用行为异常 → 确认已加 `ENABLE_TOOL_SEARCH=0`。输出明显劣化 → 切一次 §3.2 的策略 B 全切映射，确认是不是 GLM-4.7 本身的问题。 ### 8.3 真切换级：建立分层路由 + 监控成本 1. 按 §3.2 策略 A 配置分层映射（OPUS → `glm-5.1`，SONNET → `glm-4.7`，HAIKU → `glm-4.5-air`） 2. 用一周时间观察：每日 token 消耗、Coding Plan 额度消耗速度、任务成功率 3. 把 §5.4 和 §7.4 里的"不建议切换场景"保留给原 Opus 4.6——即 §6.4 的混合路由策略 4. 在 14:00-18:00 高峰期尽量把重任务推迟到非高峰时段（福利期内） **成功判定**：一周结束时对比之前的 Opus 账单，节省至少 50%；任务成功率下降不超过 10%；没有遇到无法通过配置修复的硬故障。 **失败排查**：成本没降下来 → 检查是否在高峰期集中用了 GLM-5.1（3× 消耗）。成功率下降过多 → 把关键任务回切 Opus 4.6，重新校准混合比例。遇到特定任务反复失败 → 回看 §4 和 §7，确认这个任务是否落在了 GLM-5.1 的弱势指标上。 --- 2026-04-30 是最后的福利窗口。过了这一天，非高峰期系数从 1× 恢复到 2×，上面算的所有节省比例要相应打折。2026-04-20 是 Claude Haiku 3 的正式退役日，仍在依赖那个模型的工作流必须迁。Opus 4.6 至少保障到 2027-02-05，所以切 GLM-5.1 的决策不是"要不要抛弃 Opus"，而是"哪些场景值得换、哪些场景继续留"——本文已经把那张决策表的四个象限都填好了，剩下的就看你手上的日常任务长什么样。 如果你手头正有 Claude Code 环境，最直接的行动是**现在就按 §8.1 跑一遍 10 分钟级的 Hello World**——哪怕只确认"能跑通"这一件事，也能在下一次账单决策时比什么都不做更接近答案。退一步，至少把这篇收藏起来，等到账单到的时候再翻一遍。 --- **参考资料** - Z.AI 官方 GLM-5.1 发布博客：https://z.ai/blog/glm-5.1 - HuggingFace GLM-5.1 权重与 README：https://huggingface.co/zai-org/GLM-5.1 - Z.AI Claude Code 官方配置文档：https://docs.bigmodel.cn/cn/coding-plan/tool/claude - Z.AI Coding Plan FAQ：https://docs.bigmodel.cn/cn/coding-plan/faq - Z.AI 定价页：https://bigmodel.cn/pricing - Anthropic Claude Opus 4.6 发布与定价：https://www.anthropic.com/news/claude-opus-4-6 - Anthropic 模型退役页：https://platform.claude.com/docs/en/about-claude/model-deprecations