[科普向]claude 中转站为什么这么费钱？明明便宜 70%，余额却消耗得飞快

最近在 V2 和 LinuxDo 看到不少人吐槽：中转站价格明明便宜，但余额消耗速度比官方还快。

有人说"自己什么都没做，上下文就已经用了 25K"，有人说"扣费扣得有点快，但看日志每次请求又正常"。

今天算一笔账，看看钱到底花在哪了。

一、缓存率：被忽视的吃钱黑洞

什么是 Prompt Caching ？

大模型每次对话都要重新读一遍完整历史。就像翻译文件，每次都要从头读一遍之前的内容。

Prompt Caching 就是把读过的内容缓存起来，下次直接用。**缓存命中的部分，价格降低 90%**。

Prompt Caching 价格表：

缓存率对成本的影响

核心原理：缓存命中的部分，成本只有原来的 10%（节省 90%）。

举个例子：

假设你和 Claude 聊了很久，对话历史有 50K tokens 。

官方渠道（有缓存）：

• 第 1 次请求：50K tokens 全部计费，建立缓存
• 第 2 次请求：50K tokens 中 80% 从缓存读取（便宜 90%），只有 20% 重新计算
• 第 3 次、第 4 次...都是这样

中转站（无缓存）：

• 第 1 次请求：50K tokens 全部计费（虽然便宜 70%）
• 第 2 次请求：50K tokens 又全部计费
• 第 3 次、第 4 次...每次都全部计费

算一笔账（ 10 次对话）：

看起来中转站便宜？但如果对话次数更多：

算一笔账（ 100 次对话）：

结论：对话次数越多，官方越划算。

为什么中转站缓存率低？

原因一：逆向渠道本身不支持缓存

Kiro 、Cursor 、Windsurf 等客户端的逆向接口，本身就不支持 Prompt Caching 。中转站即使想提供也做不到。

原因二：号池轮询导致缓存失效

中转站用号池轮询分配请求：

• 第一次请求用账号 A ，缓存建在 A 上
• 第二次请求分配到账号 B ，缓存全部失效
• 第三次请求又分配到账号 C ，又要重新建缓存

结果就是：缓存创建多，但命中的少。

原因三：虚标缓存率

有些中转站声称有缓存，实际是站长写死的假数据（比如写死 80%~88%）。

实际情况：缓存率差 10%，长期成本可能更高。

二、隐藏的系统提示词：上下文黑洞

一个真实案例

有人测试发现：

• 用自己的 Claude Pro 账号，新对话 /context 显示正常
• 用中转站，新对话 /context 显示已经用了 25K

问客服，客服说"就是官网，不可能是假的"，然后就不解释了。

为什么会有隐藏的系统提示词？

原因一：反代客户端自带的提示词

逆向 Kiro 、Cursor 等客户端的接口，这些客户端有自己的系统提示词（专为代码场景优化）。你的请求会被自动注入这些提示词。你看不到，但它在消耗你的 tokens 。

原因二：中转站自己注入的提示词

有些中转站为了"优化"体验，会注入自己的提示词。这些提示词每次对话都要计算，而且无法缓存。

原因三：多层代理叠加

中转站 A 从中转站 B 拿货，中转站 B 又从中转站 C 拿货。每一层都可能注入自己的提示词。最终到你手上，上下文已经被塞满了。

如何验证？

方法：用 /context 命令对比

1. 用官方账号新建对话，输入 /context，记录基础消耗
2. 用中转站新建对话，输入 /context，记录基础消耗
3. 对比两者差异

判断标准：

• 如果中转站的基础消耗明显高于官方（差距超过 50%），说明中转站注入了额外的系统提示词
• 这些额外的提示词每次对话都要计算，而且无法缓存

注意：即使是官方账号，新建对话后也会有系统提示和工具的基础消耗，不会是 0

三、切换服务商 + 无缓存 = 双重打击

为什么需要频繁切换？

中转站经常不可用，很多人需要准备多个备用中转站。甚至有人问"怎么快速切换，不用每次都复制 url 和 api-key"——切换频繁到需要专门的工具。

切换的成本

每次切换，缓存全部丢失

举个例子：

你在服务商 A 上聊了很久，已经建立了缓存。现在每次对话成本很低（假设 100 元）。

突然服务商 A 挂了，你切换到服务商 B：

• 服务商 B 没有你之前的缓存
• 需要重新建立缓存
• 首次请求成本：500 元（是有缓存时的 5 倍）

如果一天切换 3 次：

• 第 1 次切换：多花 400 元（ 500 - 100 ）
• 第 2 次切换：又多花 400 元
• 第 3 次切换：又多花 400 元
• 一天多花 1200 元

切换 + 无缓存 = 双重打击：

• 切换导致缓存丢失（每次切换都要重新建缓存）
• 中转站本身缓存率低（即使不切换，缓存命中率也低）
• 双重打击，成本爆炸

四、其他吃钱的坑

扣费 bug

有些中转站存在扣费 bug：

• 缓存创建和缓存读取计费混乱
• 重复计费
• 计费精度问题

套餐陷阱

便宜的套餐往往有日度预算限制，比如 11.90$ 的套餐每天只有 25$ 额度，根本不够用。超出部分按量计费，可能比官方还贵。

贵的套餐又用不完，不用就等于亏了。

不稳定导致的重试成本

有些低价分组很不稳定，不是 api timeout 就是 filter 。timeout 后重试，每次重试都要重新计费。不稳定导致的重试成本，可能比正常使用还高。

五、如何避免被坑

选择中转站的核心原则

原则一：问清楚缓存率

• 不支持缓存的中转站，再便宜也贵
• 虚标缓存率的中转站，更坑
• 要求提供真实的缓存命中数据

原则二：测试上下文消耗

• 新建对话，用 /context 检查
• 看上下文是否有隐藏的系统提示词
• 如果有，立即退款

原则三：算清楚长期成本

• 不要只看单价
• 要看缓存率
• 要看长期使用的总成本

官方 vs 中转站：全面对比

结论：短期看中转站便宜，长期看官方更划算。

什么时候可以用中转站？

总结

1. 中转站价格便宜 70%，但缓存率低或没有缓存
2. 缓存率差 10%，长期成本可能更高
3. 隐藏的系统提示词，每次对话都在吃钱
4. 频繁切换 + 无缓存 = 双重打击，成本爆炸

最后建议：问清楚缓存率、测试上下文消耗、算清楚长期成本。别让"便宜"蒙蔽了双眼，最后发现钱花得比官方还多。

数据来源：基于官方以及参考真实用户使用信息，仅供参考