Claude Code 分类器改走服务端不计费，自建网关请先看 /status

小土豆技术创作者 2026-09-21 105 阅读

结论先行

这是一次实打实的省钱改动。 Claude Code v2.1.278（2026-09-19）把 auto mode 的安全分类器改成默认由服务端执行，官方 changelog 的原话是「server-side classifier, which does not charge for classifier overhead」——即分类器这部分开销不再计费。(Claude Code changelog)
但「不计费」是有条件的，条件是你的会话真的走到了服务端。 官方专门写了一页文档讲这件事：服务端的检查够不到你的会话时，Claude Code 会退回自己发分类器请求，而这些请求「billed as they were before」——按老规矩照常计费。(Auto mode classifier request charges)
官方点名的三类高危网关行为，恰好是自建网关的常见写法。 文档说服务端检查够不到会话，最常见的原因就是中间的 LLM 网关：剥离或改写请求头、丢掉它不认识的请求体字段、改写响应（比如重写 ID 或从流式事件里删 key）。需要说清楚：这是官方对机制与风险条件的描述，不是踩坑率。 我按这份文档一路查下去，没能找到任何一例被证实的「因网关回退而继续计费」，也没能在本机复现；下面第三节把这次核查的过程和结果都摊开，不拿因果推断顶替证据。
好消息是不会坏，只会多花钱。 官方明确说 nothing breaks：auto mode 照常工作，只是分类器请求继续计费。第一次会拦下一个动作弹提示，按 Enter 后本会话不再弹。
一条命令就能自检：/status 里新增了 Auto mode server 行。 显示 Enabled 说明服务端在判定；显示 Disabled 说明该会话已经回退，正在按老方式计费。

证据与过程

变的是什么，没变的是什么

v2.1.278 的 changelog 只有两条，都跟这件事有关：

auto mode 对 Claude API 与 Enterprise 用户，以及 Bedrock、Vertex、Foundry 和网关，默认改为服务端分类器，不收分类器开销的费用；在 Bedrock、Vertex、Foundry 和网关上可以用 CLAUDE_CODE_AUTO_MODE_SERVER=0 退出这个默认；回退到计费模式时会给出警告。
/status 里新增一行 Auto mode server，显示本会话的分类器跑在不在服务端。

要注意这个默认不是所有账号都生效。官方文档写得很清楚：v2.1.278 及以后的版本，在 Enterprise 计划和用 Claude API 的账号、以及 Claude Platform on AWS、Amazon Bedrock、Google Cloud’s Agent Platform、Microsoft Foundry 上默认请求服务端检查；Pro、Max、Team 计划永远不会看到这个提示。同时文档强调，具体某个平台或区域做不做服务端检查，「depends on that platform’s rollout」——是灰度，不是开关一开全都有。

环境变量文档里的口径更精确一点：CLAUDE_CODE_AUTO_MODE_SERVER 在未设置时，会在 Bedrock、Google Cloud’s Agent Platform、Microsoft Foundry、Claude Platform on AWS 上请求服务端，以及当 ANTHROPIC_BASE_URL 指向某个 LLM 网关或代理时；直连 Anthropic API 时这个变量不会被读取。该变量本身要 v2.1.271+，默认请求服务端要 v2.1.278+。(Environment variables)

所以严格讲，这次改动对两类人意义不同：

直连 API 的 Enterprise 用户：分类器开销直接归零，什么都不用做。
走自建网关的团队：这个机制默认覆盖到你们，但能不能真的享受到，取决于你们的网关有没有踩上面那三类行为。踩了才回到计费，而不是「有网关就回不去」。

网关做了什么，才会掉进回退分支

把官方两份文档拼起来看，回退链条是这样的：

Claude Code ──请求(含 safeguards 字段)──▶ 网关 ──▶ 上游
                    ▲                        │
                    │  ① 网关剥掉/改写了请求头或它不认识的请求体字段
                    │  ② 网关改写了响应：删掉 safeguard_results、
                    │     重写 tool-use ID、从流式事件里丢 key
                    └── 服务端拿不到请求，或 Claude Code 收不到结果
                                  ↓
                  服务端检查够不到会话 → 退回本地分类器请求
                                  ↓
                        按老规矩继续计费 + 弹一次提示

官方原文里点名要原样转发的两个字段：请求侧的 safeguards，响应侧的 safeguard_results；并且要求不要重写 tool-use ID。同一页接着给了兜底方案——确认网关做不到就设 CLAUDE_CODE_AUTO_MODE_SERVER=0：

# 在你确认网关无法提供服务端检查时，提前关掉「请求服务端」这条路
export CLAUDE_CODE_AUTO_MODE_SERVER=0

官方对这条变量的定性要一起记住：它是临时设置（temporary setting），后续版本可能被移除。也就是说「关掉请求」只是止血，把网关改对才是解法。

这次核查：我没能证实「网关 → 回退 → 继续计费」

审稿人指出全篇没有一例被证实「因网关回退而继续计费」，我打开原文逐条核对后，结论是这个批评成立，而且比我原先以为的更彻底：

ollama#18544 与分类器计费无关，是明确的。 打开原文看：发帖人在 2026-09-19 设了 CLAUDE_CODE_AUTO_MODE_SERVER=1，确实收到了那条「isn’t eligible」提示，但整条工单是发给 ollama 仓库的 feature request——标题就叫「Support CLAUDE_CODE_AUTO_MODE_SERVER=1」，正文要求 ollama 的服务端支持这个特性。它证明的是「某个自建推理服务端还没实现服务端分类」，不是「网关改写了请求」，也没有任何计费证据。(ollama#18544) 顺带说明：原文提到的关联工单 ollama#18293，我打开后实际是「Frequent model unavailable errors」，与 input/output token 口径无关，所以那条关联也不构成证据。
new-api#5598 也不是。 打开原文看：这是「自定义渠道 + 完整透传」模式下，new-api 把上游的 content_block_start/delta/stop 全部吞掉、客户端只剩 message_start/delta/stop 骨架的抓包记录；换 Anthropic 兼容模式就正常。它证明网关确实会重构响应，但记录里没有 safeguard_results、没有分类器请求，与分类器计费没有建立任何关系。(new-api#5598)
一次外部检索也没有找到别的候选案例。 我用 GitHub 搜索接口查了两组关键词：AUTO_MODE_SERVER 全站只有 2 条结果（一条是 2.1.273 的更新日志，另一条是 2026-09-20 的个人博客，属二手转述）；anthropics/claude-code 仓库里按 AUTO_MODE_SERVER 与「isn’t eligible」检索均为 0 条。到今天为止，公开渠道没有一例「网关回退 + 继续计费」的实测记录。
本机也无法作为旁证。 我查了本机 ~/.claude/projects 下的 148 个会话日志（2026-09-08 至 2026-09-20 写入，版本全部是 v2.1.258）：既没有那条提示，也搜不到 AUTO_MODE_SERVER。但这不说明问题——v2.1.258 早于 v2.1.271 与 v2.1.278，这个功能在本机根本没上线；而且本机唯一的 ANTHROPIC_BASE_URL 记录指向第三方托管端点，并不是自建网关。所以「本机没有」既不能证伪也不能证实这条链路。

因此我把「自建网关踩坑概率不低」这条推断删掉了。 能被核实的只有机制与风险条件：官方文档把这几类网关行为列为回退的最常见原因（同一页也承认，在没有网关的路径上，平台/区域/凭据的灰度同样会触发回退）。至于这笔钱在你家到底有没有省下来，只能靠下面那套自检在自己的环境里验，不能靠「我们有网关」推出来。

同类擦伤还有官方自己记录过的一次：v2.1.276 修的就是「ANTHROPIC_BASE_URL 指向代理或网关时每个请求都 400 Input tag 'advisor_20260301'」（2.1.275 的回归）。新字段先行、网关跟不上——这个节奏是官方 changelog 自己记下来的。

我自己的判断：一张网关自检清单

官方给的排查入口是 /status，但那只告诉你「现在有没有回退」，不告诉你「是谁干的」。我建议把顺序倒过来，先证明网关是干净的，再看计费提示。

第一步，确认版本与状态。 低于 2.1.278 的 CLI 根本不会请求服务端，先升级再看现象。

claude --version          # 需要 >= 2.1.278
claude                    # 进会话后执行 /status
# 看两行：Anthropic base URL（应指向你的网关）
#        Auto mode server（Enabled = 服务端判定；Disabled = 已回退，按老方式计费）

第二步，抓一次请求体做对比。 这是唯一能证伪「网关没动字段」的方法——在网关侧和上游侧各抓一次同一个请求，逐字段 diff。官方给的验证方法就是发一个流式请求看 data: 是不是增量到达（整段一次性返回 = 网关在缓冲，会拖死 Claude Code）：

curl -N -X POST "https://你的网关/v1/messages" 
  -H "Authorization: Bearer <developer-key>" 
  -H "anthropic-version: 2023-06-01" 
  -H "content-type: application/json" 
  -d '{"model":"claude-sonnet-5","max_tokens":16,"stream":true,
       "messages":[{"role":"user","content":"count to 3"}]}'

第三步，按症状定位是哪一类改写。 我把官方文档里的因果整理成一张表，「配置侧」那栏是 Claude Code 的官方要求，最后一栏是我的归类：它是对机制的推演，不是观察到的发生率——本次核查没有拿到任何一例实测。

网关行为	会坏掉的东西（官方口径）	与分类器计费的关系（我的推演，非实测）
按观察到的字段清单做白名单转发	下一个版本新增的 `anthropic-beta` 值或请求体字段被剥掉，在引入它的那一版坏掉	可能：`safeguards` 属于「网关不认识的字段」这一类，白名单式转发会丢掉它；这是我按字段性质归的类，没有实例
剥离/改写请求头	官方列为服务端检查够不到会话的最常见原因之一	高：直接命中官方点名的第一类行为
改写响应、从流式事件删 key、重写 tool-use ID	官方明确点名 `safeguard_results` 不能丢	高：直接命中官方点名的第三类行为
缓冲整个响应、丢掉 keep-alive ping	默认 300 秒静默即判定流中止	中：不一定直接触发回退，但会让会话表现异常、掩盖真因
改写错误响应体	自动恢复靠错误措辞匹配，包一层信封就匹配不上	低：与本计费改动无关，但常和上面几条一起出现

官方在兼容性指南里对第一条的态度值得单独引用：把请求头和请求体字段当开放列表、不要当封闭列表，「A gateway pinned to an observed list strips the next capability’s header or field and breaks it on the release that introduces it」。换句话说，如果你们的网关是「只转发我们测过的字段」，这次的 safeguards 就是下一次踩雷的预演。

第四步，能改就改，不能改就先关。 让网关把请求和响应原样透传（包括它不认识的头和字段、safeguards、safeguard_results、tool-use ID、流式事件的每个 key）；短期做不到，就按官方兜底设 CLAUDE_CODE_AUTO_MODE_SERVER=0，把那一次弹窗和「以为省钱其实没省」的错觉一起消掉，等网关改好再摘掉。

最后一点提醒给管账的人： GitHub issue #43945（closed as not planned）投诉 /cost 少报支出，其中一条是 auto-mode 权限检查走的 sideQuery() 路径不调用 addToTotalSessionCost()，即真实计费请求不进 /cost。这是社区二手、且被官方以 not planned 关闭，但后果值得记：这部分钱客户端面板本来就不一定看得见。核对要去 provider 侧用量面板——也就是说，「回退到计费」的早期症状是账单，不是 /cost。

这次没核实的

「网关回退 → 继续计费」的真实案例：确认拿不到。 公开渠道（GitHub 检索、官方文档、社区转述）没有一例实测记录；ollama#18544 与 new-api#5598 都已被原文证明与分类器无关，我把它们从论证链里摘出来，只当「网关会动请求/响应」的兼容性佐证；本机因版本过低（v2.1.258）也不构成证据。本文关于这条链路的每一句话都停留在官方文档的机制描述上。
回退发生的实际比例：官方那句「most common cause is an LLM gateway or proxy」是文档作者的总体判断，没有给出任何基数或样本。所以「多常见」我无法回答。
safeguards 被网关丢掉的具体实例：官方文档只说网关可能丢掉「它不认识的字段」，并点名 safeguards 必须原样转发；我没有找到任何一条「某网关确实剥掉了 safeguards」的记录，所以表里那一栏只能算按字段性质的推演。
服务端分类器具体跑在哪个端点、请求长什么样：官方只描述为「as part of the session’s own model requests」，没有给出可抓的请求形态，所以我无法给出「服务端检查的额外 token 占比」这类数字。任何具体的百分比我都不会写。
各家的灰度范围：官方只说「depends on that platform’s rollout」。哪些区域、哪些企业账号在 2026-09-21 已经生效，未能核实。
国内常见网关的实测行为：我没有在本机复现（本机既没装 v2.1.278+，ANTHROPIC_BASE_URL 也只指向第三方托管端点，不是自建网关），因此没有拿到任何自测数据。上面关于 new-api / LiteLLM 的描述都是读它们自己的工单与文档得到的第三方说法，属于社区二手，不代表我实测。
分类器开销的量级：官方博客只说「a small number of extra tokens per tool call」，文档页也没给数字（见下方参考来源的官方博客），因此省下多少钱无法估算，我没编。

参考来源

Claude Code changelog v2.1.278（2026-09-19） —— 一手，本次改动原文；2.1.276 的网关 400 回归也在此页
Auto mode classifier request charges —— 一手，回退机制、提示文案、受众范围、safeguards/safeguard_results
Environment variables：CLAUDE_CODE_AUTO_MODE_SERVER —— 一手，生效平台清单与版本门槛（v2.1.271 / v2.1.278）
Claude Code gateway compatibility guide —— 一手，「把头和字段当开放列表」、300 秒静默判流中止、错误响应体需原样转发
Roll out an LLM gateway for your organization —— 一手，网关验收命令与症状对照
Auto mode is now the default in Claude Code（2026-08-07） —— 一手，Pro/Max/Team 免分类器开销的最早说法与安全数据
LiteLLM：Claude Code with Bring Your Own Key —— 第三方文档，「LiteLLM strips x-api-key by default」（BYOK 的 x-api-key 路径需要 forward_llm_provider_auth_headers: true）
ollama#18544 —— 社区二手，但自认是「请 ollama 支持该变量」的 feature request，与分类器计费无关
new-api#5598 —— 社区二手，透传模式下流式事件被吞的抓包记录，与分类器无关
anthropics/claude-code#43945 —— 社区二手且 closed as not planned，/cost 未统计分类器请求

# Claude # 教程 # 知识

评论区

0 条评论

登录后可评论。