LinkyMonitor / 黑话词典
中转站黑话词典：社区术语与协议字段对照
社区里骂街用的词，和你能在响应里验证的东西，是两套语言。这份表把它们对上—— 左边是别人怎么说，右边是你怎么查。
一、现象类：用户感受到的
| 词 | 指什么 | 怎么验证 |
|---|---|---|
| 降智 | 感觉模型变笨了。它是一个感受词，不是一个诊断——底下至少有三种完全不同的成因。 | 先分类再行动，见 Claude 降智怎么判断 |
| 掺假 | 渠道给你的东西和它声称的不一致，是所有具体手法的统称。 | 没有单一验证方法，看下面的具体手法 |
| 掉包 / 模型掉包 | 你请求模型 A，请求被转发到更便宜的模型 B，响应里的 model 字段仍然写着 A。 |
能力探针 + 延迟分布，不能靠问「你是什么模型」 |
| 上下文截断 | 请求在转发前被裁短，长对话表现为「失忆」。 | 发一段已知长度的输入，比对返回的输入 token 数 |
| 参数过滤 | 请求里的部分字段在转发时被丢弃，声明的能力静默失效。 | 逐个字段发探针，看响应结构是否符合协议 |
| 跑路 | 站点关停，余额归零。 | 无法预测。唯一有效的防御是只充小额、不囤余额 |
二、计费类：钱相关的
| 词 | 指什么 |
|---|---|
| 倍率 | 中转站在官方价格基础上乘的系数，用来定价和结算。它是后台配置项，可以按用户、按模型、按时段分别设置，随时可改。 |
| 虚标 / 偷 token | 报给你的用量高于实际消耗。因为 usage 只是响应体里的一个字段，中转站可以在返回给你之前改写它。 |
| 缓存套利 | 命中了 prompt 缓存、按缓存价结算给上游，却按完整 token 数向你收费，赚中间的差价。 |
| 输出缩水 | 按官方费率收钱，但实际输出更短。同样一笔钱拿到的内容更少、重试次数更多，实际单价高于标价。 |
展开与自查步骤见 Token 虚标与倍率对账。
三、渠道类：站点性质
| 词 | 指什么 |
|---|---|
| 中转站 | 第三方 AI API 代理。你把请求发给它，它转发给上游，再把响应回给你。也叫「中转」「API 中转」。 |
| 官转 | 声称走官方链路的渠道。 |
| 逆向 | 不走官方 API，而是逆向某个消费端产品的接口来提供服务。通常更便宜，也更不稳定。 |
| 号池 | 一批账号轮流承接请求。不同账号的配额、限流和能力可能不一致，表现为「时好时坏」。 |
| new-api / one-api | 常见的开源中转站自建程序。这类系统的计费逻辑由站长部署，也出过计费相关的漏洞。 |
| CCMax / Kiro | 渠道用来标注自己资源来源的标签。同一个渠道声明为一种、实际表现出另一种特征时，就是「资源声明与行为不一致」。 |
四、协议字段：真正能验证的东西
上面所有词都是描述，下面这些是协议里客观存在的字段。这是你从口水仗转向证据的分界线。
Anthropic Messages API 的 usage
| 字段 | 含义 |
|---|---|
input_tokens | 只是未命中缓存的那部分输入，不是输入总量 |
output_tokens | 输出 token 数 |
cache_creation_input_tokens | 本次写入缓存的 token 数 |
cache_read_input_tokens | 本次从缓存读取的 token 数 |
input_tokens + cache_creation_input_tokens + cache_read_input_tokens。
只看 input_tokens 会严重低估实际输入规模——一次跑了很久的任务显示 input_tokens 只有几千，
往往是因为其余部分走了缓存。对账时三项都要看。
OpenAI Responses API 的 usage
字段名不同：input_tokens、input_tokens_details.cached_tokens、
input_tokens_details.cache_write_tokens、output_tokens、
output_tokens_details.reasoning_tokens、total_tokens。
Chat Completions 的 usage 结构又和这两个都不一样。这正是自己对账时不要照抄字段名的原因—— 以你自己那次响应里实际返回的结构为准。对账脚本就是按这个思路写的： 它不硬编码字段名，而是把整个 usage 对象拍平后逐项比对。
停止原因
Anthropic 的 stop_reason 取值：end_turn(正常结束）、max_tokens(达到输出上限）、
stop_sequence(命中停止序列）、tool_use(要调工具）、pause_turn(服务端工具暂停）、
refusal(安全拒绝）。较新的模型还有 model_context_window_exceeded(超出上下文窗口，
与 max_tokens 是两回事）。
refusal 时才会带 stop_details，其他情况下这个字段是 null——
所以判断要看 stop_reason，不要看 stop_details 是否存在。
Prompt 缓存
- 前缀匹配。渲染顺序是 tools → system → messages，前缀里任何一个字节变了，后面全部失效。
- 有最小长度门槛，而且不同模型不一样——从 512 到 4096 token 都有，并且不是越新越低。低于门槛不会报错，只是静默不缓存，
cache_creation_input_tokens保持 0。 - 缓存读取约为基础输入价的 0.1×；写入是 1.25×(5 分钟 TTL)或 2×(1 小时 TTL)。
- 换模型会让缓存失效——缓存是按模型隔离的。
这几条对判断很有用：如果重复发送前缀完全相同的请求，cache_read_input_tokens 却一直是 0，
中间一定有东西在改写你的请求（也可能是你自己的 prompt 里混进了时间戳之类每次都变的内容）。
Thinking / 推理 token
一个常被误解的点：thinking 的显示设置只影响你能不能看见，不影响是否发生、也不影响计费。
把显示关掉不会让它变便宜。另外 max_tokens 是 thinking 加正文的总上限，
不是只管正文——按老模型经验掐得很紧的 max_tokens，在默认开启 thinking 的新模型上会导致回答被截断。
五、其他
| 词 | 指什么 |
|---|---|
| TTFT | Time To First Token，首字延迟。不同规格的模型分布不同，单次没意义，看分布才有意义。 |
| 拨测 / 探测 | 主动发一个已知请求去检查链路状态，而不是等真实业务出问题才发现。 |
| 基线 | 一段时间内的正常表现范围。没有基线就没有「偏离」，也就没法说什么叫异常。 |
usage 能。
LinkyMonitor 用固定请求持续探测同一条链路，把这些字段的变化留成可回溯的历史。