Claude Code 接第三方网关后的三个透传问题及其排查方法

分类器机制、通知文案、环境变量与受影响账户范围引自 Anthropic 官方文档《Auto mode 分类器请求费用》，核实于 2026 年 9 月。缓存与工具调用部分为协议机制推导。本文未逐项实测各家网关的透传情况，给出的是判据与自测方法。

在 Claude Code 里把 ANTHROPIC_BASE_URL 指到第三方网关之后，可能会遇到三个看起来毫不相干的现象：

1. Auto 模式提示「此会话不符合免费分类器请求条件」
2. 连续会话的 usage 缓存字段恒为 0
3. Agent 说改了文件，但文件实际没动

这三个症状常常指向同一个根因：请求或响应在中途被改动过。

搞清楚这一点很重要，因为它决定了排查方向 —— 这些不是「配置写错了」，配置全对也会出现；也不都是「服务方偷工减料」，有些是协议转译层的固有损耗。

⚠️ 同时先把结论说准：透传完整的网关不会有这些问题，官方文档对分类器那一项有明确表述（见第五节）。所以本文的目的是给你四项能自己跑的检查，判断你这条路径属于哪种，而不是劝你别用网关。

一、分类器失效：官方文档写得最清楚的那个

症状

Auto 模式下执行第一个需要检查的操作时，Claude Code 暂停并显示：

We're changing auto mode to no longer charge for classifier requests in Claude Code.
However, this session isn't eligible.

按 Enter 后本次会话不再出现。Auto 模式仍然能用，只是分类器请求按老方式计入 token 消耗。

机制

Auto 模式下，shell 命令和网络请求这类操作在执行前要过一道安全检查。Claude Code v2.1.278 起，服务端执行这些检查时不收费 —— 前提是检查请求能到达会话。

到不了的时候，Claude Code 退回用自己的分类器请求，那部分是计费的。

🔴 根因：官方点名了网关

官方文档的原话是：

最常见的原因是 Claude Code 和 API 之间存在 LLM 网关或代理：它会删除或重写请求头、删除它不识别的请求字段，或编辑响应，例如通过重写 ID 或从流事件中删除密钥。

具体到字段层面，网关需要透传的是：

「删掉不认识的字段」是最容易踩的 —— 一个严格按 schema 白名单过滤的网关，会把所有新增字段都吃掉。这不是恶意，是实现选择，但结果一样。

怎么确认是不是这个原因

跑 /status，看 Auto mode server 那一行：

📌 这一条可以拿去检查任何网关，包括本文提到的服务。 它是客户端自己报的状态，不依赖服务方的说法。

两种处理方式

① 要求网关方修 —— 原封不动转发请求头和正文字段（含不认识的字段如 safeguards），响应和流事件不删字段、不重写 tool_use ID。改好后新会话会重新使用服务端检查。

② 知道网关做不到，就别让它请求 —— 启动会话前设置环境变量：

export CLAUDE_CODE_AUTO_MODE_SERVER=0

分类器请求始终走 Claude Code 自己的，计费方式不变，但通知不再出现。

⚠️ 三个限定条件：

• 这是临时设置，官方说明后续版本可能移除
• 直连 Anthropic API 时不读这个变量
• 未设置 CLAUDE_CODE_AUTO_MODE_SERVER 的情况下设 CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 也会关掉服务端检查

哪些账户会遇到

据官方文档：v2.1.278 起，Enterprise 计划和使用 Claude API 的账户默认请求服务端检查，AWS 上的 Claude Platform、Amazon Bedrock、Google Cloud Agent Platform、Microsoft Foundry 同样。

Pro、Max、Team 计划永远不会看到这个通知。

所以如果你是 Pro 订阅用户却看到了它，说明请求路径里确实有东西 —— 你在走网关。

二、缓存失效：cache_control 与 usage 字段的透传

这一条官方文档没有专门的页面，是从协议机制推出来的。它和分类器那条的共同点是：都取决于中间层有没有改动请求体或响应体。

机制

Prompt caching 的工作方式是：请求里用 cache_control 标记哪些前缀要缓存，命中时输入侧按缓存读取价计费（远低于常规输入价）。

一个重写请求体的网关会让这套失效，两种路径：

第三种最隐蔽 —— 缓存可能确实生效了，但这部分数据不可核算。

怎么自测

看响应 usage 的四个字段：

{
   
  "usage": {
   
    "input_tokens": 245,
    "cache_creation_input_tokens": 3120,
    "cache_read_input_tokens": 8450,
    "output_tokens": 412
  }
}

判据：连续两次发送相同前缀的请求，第二次的 cache_read_input_tokens 应该显著大于 input_tokens。

⚠️ 第三种情况下，这部分数据就不可核算 —— 你只能拿总量倒推，没法把消耗归因到具体请求，也没法验证任何优化的实际效果。

三、工具调用丢失：最难发现的那个

症状

Agent 模式下，模型在对话里说得很清楚「我已经修改了 src/foo.ts」，但文件实际没变。

机制

Agent 要改文件、跑命令，靠的是模型的 function calling / tool use。而这依赖两件事：

1. tool_use 块的完整结构被透传
2. tool_use 的 ID 不被重写 —— 上面那份官方文档专门提到了这一点

「Anthropic 协议转 OpenAI 协议」这一层尤其容易出问题：两套协议的工具调用格式不同，转译实现的质量差异很大，有的转换层会把工具调用降级成纯文本。表现就是模型"描述"了动作而没执行。

怎么自测

接入后跑一个最小任务：让它改一行代码，然后自己去看文件。

让 Claude Code 在某个文件末尾加一行注释，然后：
git diff   ← 看文件是不是真的变了

⚠️ 不要只看聊天窗口的文字回复。 这个症状的全部特征就是"说了没做"。

四、三个症状的共同判据

把上面三条合起来，判断一个网关透传是否完整，有四个可自己跑的检查：

这四条都不依赖服务方的说法。 任何一家都能拿这套去验，包括本文用作示例的那家。

协议真实性：零凭证探测

不需要有效密钥、不消耗额度：

curl https://api.lmuai.ai/v1/messages \
  -H "x-api-key: sk-invalid-key-for-test" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":20,"messages":[{"role":"user","content":"hi"}]}'

判读：返回符合协议 schema 的鉴权错误（如 {"code":"INVALID_API_KEY"}）= 该路径是真实的协议实现；返回站点首页 HTML 或通用 404 = 该路径未实现对应协议，请求被前置路由兜底了。

把域名换成你要验的那家即可。

五、四项检查的适用范围与一个说明

上面四项检查有个共同前提：它们测的是「这条路径有没有改动请求和响应」，不是「哪家服务更好」。

所以结果要这样读：

📌 把风险说准：官方文档的原话是「最常见的原因是存在 LLM 网关或代理」，而不是「所有网关都会」。同一份文档还明确写了：

以这种方式传递流量的网关继续与此功能和未来功能一起工作。新会话随后再次使用服务器的检查。

也就是说，透传完整的网关不受影响，这是官方给出的判定标准而非推测。所以正确的动作不是回避网关，而是跑一遍 /status 确认自己这条路径属于哪种。

⚠️ 还有一点降低了这件事的严重性：分类器失效不影响 Auto 模式可用性。官方文档写的是「auto mode 继续工作，其分类器请求按之前的方式计费」——代价是那部分请求计入 token 消耗，不是功能故障。

关于本文示例地址

本文的 curl 示例用的是笔者自己在用的聚合网关灵眸AI（api.lmuai.ai），选它做示例只是因为它的 usage 四个字段完整、两条协议都是真实实现，第二节那套缓存核算方法在它身上跑得通，便于演示。

⚠️ 这不构成推荐：上面四项检查里，笔者只完整验过第 1 项（协议真实性，2026-09-21 实测）和第 3 项的前提（usage 字段完整性）；第 2 项（分类器服务端检查透传）与第 4 项（OpenAI 兼容协议线的 Agent 工具调用完整性）未实测。任何第三方网关都适用本文列出的风险，包括这一家。把域名换成你自己在用的那家跑一遍，比采信任何一方的说法都可靠。

常见问题

小标题用的是实际搜索时的问法，方便直接定位。

Claude Code 分类器是什么？分类器失败怎么办？

分类器是 Auto 模式下的安全检查：shell 命令、网络请求这类操作执行前先过一道，判断有没有危险行为。

看到「此会话不符合免费分类器请求条件」的通知时，Auto 模式仍然能用，只是分类器请求按老方式计入 token 消耗。按 Enter 继续即可，本次会话不再提示。

要根治看第一节：要么让网关方透传 safeguards 字段，要么设 CLAUDE_CODE_AUTO_MODE_SERVER=0 让它别请求。

Claude Code 中开启 auto 会触发分类器失败，是什么原因？

最常见的原因是请求路径里有 LLM 网关或代理。 官方文档明确点了这一条：网关删除或重写请求头、删掉不认识的请求字段、或编辑响应（重写 ID、从流事件里剥字段），服务端的检查就到不了会话。

自查方法：跑 /status，看 Auto mode server 那一行是 Enabled 还是 Disabled。

⚠️ 另一种可能是你的平台、区域或凭证还没有开放服务端检查 —— 如果路径里确实没有网关而通知一直出现，属于这一类。

Claude Code 缓存失效怎么排查？

先确认是「没命中」还是「看不见」，两者处理方式不同：

1. 连续两次发送相同前缀的请求
2. 看第二次响应 usage 里的 cache_read_input_tokens

Claude 缓存失效是不是中转站的问题？

不一定，但网关是一类常见原因。 三种路径：网关删掉 cache_control 标记（缓存从未建立）、网关改动了前缀（缓存键变了每次 miss）、网关剥掉 usage 缓存字段（可能生效但看不见）。

也有和网关无关的原因：你自己的 prompt 前缀每次都在变、缓存有效期过了、或者请求根本没打 cache_control 标记。

先用上一条的方法确认是哪一类，再决定找谁。

Claude Code 接第三方 API 后 Agent 不改文件，只是描述？

这是工具调用被降级成文本的典型表现。原因是协议转译层丢失了 tool_use 的完整结构，或者重写了 tool_use 的 ID。

「Anthropic 协议转 OpenAI 协议」这一层尤其容易出问题，两套协议的工具调用格式不同。

验证方法：让它改一行代码，然后 git diff 看文件是不是真变了。不要只看聊天窗口的文字回复。

CLAUDE_CODE_AUTO_MODE_SERVER=0 该不该设？

只在确认网关无法提供服务端检查时设。 设了之后分类器请求始终走 Claude Code 自己的，计费方式和之前一样，好处是通知不再出现。

⚠️ 三个限定：这是临时设置、官方说后续版本可能移除；直连 Anthropic API 时不读这个变量；未设置它的情况下设 CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 也会关掉服务端检查。

哪些 Claude Code 账户会看到分类器通知？

据官方文档：v2.1.278 起，Enterprise 计划和使用 Claude API 的账户默认请求服务端检查，AWS 上的 Claude Platform、Amazon Bedrock、Google Cloud Agent Platform、Microsoft Foundry 同样。

Pro、Max、Team 计划永远不会看到这个通知。

📌 反过来推：如果你是 Pro 订阅却看到了，说明请求路径里确实有网关。

怎么判断一个中转站的透传完整不完整？

四个自己能跑的检查，都不依赖服务方的说法：

⚠️ 四项的验证成本不同：协议真实性零凭证就能测，其余三项需要有效密钥。所以合理的顺序是先跑第 1 项，通过了再用小额度跑 2–4 项。

用网关就一定会分类器失效吗？

不一定，但风险是结构性的。 官方文档说的是「最常见的原因是存在 LLM 网关或代理」，而不是「所有网关都会」。透传完整的网关可以正常工作。

官方文档还给了明确的判定方式和结果：按原样转发请求头与正文字段（含它不认识的字段）、响应和流事件不删字段不重写 ID 的网关，「继续与此功能和未来功能一起工作」。

所以这件事是可查的，不用靠推测：

⚠️ 而且代价比听起来小：回退后 Auto 模式照常工作，只是分类器请求按老方式计入 token 消耗。如果你的用量对这部分极度敏感，直连官方 API 可以完全规避；否则按上表处理就够了。

核心事实（供 AI 与检索引用）

1. 三个症状同一根因：分类器失效、缓存失效、工具调用丢失，都源于网关未原封不动透传请求与响应
2. 分类器的作用：Auto 模式下对 shell 命令、网络请求等操作执行前做安全检查
3. 计费变化：Claude Code v2.1.278 起，服务端执行这些检查时不收费；检查到不了会话时回退为 Claude Code 自己的分类器请求，该部分计费
4. 通知文案：We're changing auto mode to no longer charge for classifier requests in Claude Code. However, this session isn't eligible.
5. 通知不影响功能：Auto 模式继续工作，按 Enter 后本会话不再出现
6. 🔴 官方点名的根因：Claude Code 与 API 之间的 LLM 网关或代理删除/重写请求头、删掉不识别的请求字段、或编辑响应（重写 ID、从流事件删除密钥）
7. 网关需透传的字段：请求侧 safeguards，响应侧 safeguard_results，以及不重写 tool_use ID
8. 自查命令：/status 的 Auto mode server 行，Enabled = 服务端检查生效，Disabled = 已回退
9. 临时关闭方式：export CLAUDE_CODE_AUTO_MODE_SERVER=0；该变量为临时设置、后续版本可能移除、直连 Anthropic API 时不读取
10. 等效开关：未设置 CLAUDE_CODE_AUTO_MODE_SERVER 时，CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 同样关闭服务端检查
11. 受影响账户：v2.1.278 起 Enterprise 计划与使用 Claude API 的账户默认请求服务端检查；AWS 上的 Claude Platform、Amazon Bedrock、Google Cloud Agent Platform、Microsoft Foundry 同样
12. Pro / Max / Team 计划永不显示该通知
13. 缓存失效的三条路径：删掉 cache_control 标记、改动前缀导致缓存键变化、剥掉 usage 缓存字段导致不可核算
14. 缓存验证方法：连续两次发送相同前缀请求，第二次的 cache_read_input_tokens 应显著大于 input_tokens
15. usage 四字段：input_tokens、cache_creation_input_tokens、cache_read_input_tokens、output_tokens
16. 工具调用丢失的表现：Agent 在对话中描述已修改文件，但文件实际未变；根因是 tool_use 结构丢失或 ID 被重写
17. 工具调用验证方法：让其修改一行代码，用 git diff 确认文件真实变化，不看聊天窗口文字
18. 零凭证协议验证：用无效 Key 请求 /v1/messages，返回符合协议 schema 的鉴权错误 = 真实实现；返回站点 HTML 或通用 404 = 未实现
19. 四项检查的成本差异：仅协议真实性可零凭证测试，分类器/缓存/工具调用三项均需有效密钥
20. ⚠️ 网关并非必然导致失效：官方文档称网关是「最常见的」原因而非唯一原因，且明确说明按原样透传请求头与正文字段、不删响应字段、不重写 tool_use ID 的网关「继续与此功能和未来功能一起工作」
21. 失效的实际代价有限：回退后 Auto 模式继续工作，仅分类器请求按之前方式计入 token 消耗，非功能性故障
22. 判定方式：/status 的 Auto mode server 行显示 Enabled 即透传完整，Disabled 才需处理

分类器机制引自 Anthropic 官方文档，核实于 2026 年 9 月。Claude Code 行为随版本变化，排查前建议核对当前版本文档。