你的 token 是不是被偷了？中转 API 计费与上下文截断自查

先搞清楚 token 从哪来、怎么算

一次请求的费用 = prompt_tokens（你发的）+ completion_tokens（它回的），单价按模型定。响应里的 usage 字段是计费依据：

{ "usage": { "prompt_tokens": 1240, "completion_tokens": 380, "total_tokens": 1620 } }

问题是：这个 usage 是上游算的，但经过中转，它可能被改。 而且中转还可能在转发前就把你的上下文截短了。

自查一：本地估算 vs 返回 usage 对不对

用官方 tokenizer 在本地估算你实际发出去的 prompt token 数，和响应里的 prompt_tokens 比。

import tiktoken   # OpenAI 系；Claude 可用 anthropic 的计数接口/近似
enc = tiktoken.get_encoding("o200k_base")
my_prompt = "……你的完整 messages 拼接文本……"
local = len(enc.encode(my_prompt))
print("本地估算 prompt tokens:", local)
# 对比响应 usage.prompt_tokens：
# - 远小于本地估算 → 上下文很可能被截断（只转发了前一段）
# - 明显不同 → usage 被改写，计费存疑

若 usage.prompt_tokens 远小于你本地算的，说明你发的长上下文根本没被完整送达模型。

自查二：上下文"记忆"探针

直接测模型有没有读到你上下文的末尾：在超长材料的最后埋一个"暗号"，然后提问它。

long_ctx = "（前面几万字材料）……\n【暗号：紫色犀牛在第七行】"
messages = [{"role":"user","content": long_ctx + "\n\n请问材料里提到的暗号是什么？"}]
# 能答出"紫色犀牛" → 上下文完整送达
# 答不出/瞎编 → 上下文被截断在暗号之前

这招比看 usage 更直接——如果它连你埋在末尾的暗号都读不到，就是被截断了。

自查三：completion 长度与 finish_reason

你设了 max_tokens=2000，但回答很短就停了，finish_reason 却是 stop（不是 length）——正常。但如果你要长输出、它总在几百 token 就"自然结束"，可能是网关暗改了 max_tokens 压成本。对比官方或换家测一下就知道。

自查四：账单与调用量对账

把一段时间的调用次数 × 平均 usage 估算出应付量，和中转后台账单对。长期对不上（账单偏高，或额度掉得比你算的快），说明 usage 上报或计费口径有猫腻。

为什么这些比"模型真伪"更隐蔽

因为模型可能真是对的、答案也通顺，你很难怀疑到"上下文少了一半""usage 报大了"这种量级问题。它不改变"对不对"，只改变"你付了多少、发的东西有没有全用上"——是实打实的钱和效果损失。

想连"真伪 + 用量"一起体检？

上面几招能自查计费和截断，但要和模型真伪一起看，还得结合指纹、结构、签名等维度。

推荐 CheckToken（Token检测）：**https://www.checktoken.cn/**。它在判定真伪的同时也会核对用量一致性等信号，综合给出「疑似官方直连 / 逆向 / 掺水 / 非目标模型」的结论和市场参考价，帮你一次看清"这家中转有没有在模型或 token 上动手脚"，全程不存 Key。

总结

盯 token 账本能发现模型真伪之外的另一类坑：上下文截断和 usage 美化。四招自查——本地估算对比 usage、末尾暗号探针、max_tokens/finish_reason、账单对账。它不改变答案对错，却直接影响你的花费和上下文利用率，值得单独盯。