计费元数据检测

发一段已知长度的文本，检查响应里官方必有的计费字段是否存在、类型是否正确、数值是否与你实际输入的内容量级大致相称。三家协议字段名不同：Claude 是 usage.input_tokens / usage.output_tokens；OpenAI 是 usage.prompt_tokens / usage.completion_tokens，外加 total_tokens 是否等于两者之和；Gemini 是 usageMetadata.promptTokenCount / totalTokenCount，外加分项加总是否与 total 一致（开启 thinking 的正规站 total 会因为思考 token 上浮，这部分会被识别并放行）。

官方计费字段是协议规定必有的，且理应和你实际发送的内容量大致成正比。字段整体缺失，或者计费数字和你输入的内容量级明显对不上，都是这条通道计费不透明、协议实现不完整的信号。

• 通过：计费字段齐全、类型正确，且数值与输入内容量级相称（OpenAI 还要求加总一致，Gemini 还要求分项与 total 相符）。
• 存疑：字段存在但数值和输入量级明显不符，或者 OpenAI 的 total_tokens 与分项加总对不上，或者 Gemini 的 totalTokenCount 与分项矛盾，或者 Claude 的缓存计费字段类型异常。
• 未通过：关键计费字段整体缺失（Claude 缺 input_tokens/output_tokens、OpenAI 缺 usage 对象、Gemini 缺 usageMetadata），协议实现不完整。
• 信息不足：请求失败或超时，没拿到有效响应。

这一项只做「量级是否大致相称」的粗判断，不是逐 token 精确审计，通过不代表完全没有计费膨胀——真正的「扣除固定前置后，内容本身计费是否翻倍虚高」由权重为 0、不进真假分的注入指纹项单独测，两者是两回事。Claude/OpenAI 的「量级不符」存疑在正式报告里还会额外跟注入指纹测出的固定前置开销做一次对账：如果确认前置落在官方信封量级、且内容部分本身计费正常，这个存疑会被改判为通过，避免把正常的客户端信封前置误判成计费异常（这条对账只适用于 Claude/OpenAI，Gemini 的 usageMetadata 不参与）。

本站送检单区块「不信本站？自己在终端测一遍」旁生成的命令就是测这个字段，你也可以照下面的样例自己跑一次。

curl -s https://YOUR_RELAY_BASE_URL/v1/messages \
  -H "x-api-key: YOUR_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-opus-5","max_tokens":4,"messages":[{"role":"user","content":"hi"}]}' \
  | grep -o '"input_tokens":[0-9]*'

OpenAI 换成 /v1/chat/completions + Bearer 头，grep "prompt_tokens"；Gemini 把 key 拼进 URL 的 key= 参数，grep "promptTokenCount"。极短的 "hi" 请求，计费应该是个位数到十几；数字明显偏大，说明这条通道在计费前塞了别的东西。