前段时间有个朋友私信我,说自己最近有点迷糊——充了中转站,单价比官方便宜了七成,但感觉钱花得并没有省下多少。他发了张截图给我,新建一个对话,一条消息都没发,/context 已经显示 25K tokens 了。
我说:你不是第一个问我这个的。
这个问题我大概回答了不下十次,每次解释完对方都说"早知道就好了"。干脆写一篇,把里面的逻辑彻底说清楚。
你以为省了 70%,但缓存才是最大的变量
先解释一个很多人没注意到的机制:Prompt Caching(提示词缓存)。
Claude 每次处理请求,都要把完整的对话历史重新"读"一遍。对话越长,每次读的内容越多,成本越高。Prompt Caching 的作用,就是把已经读过的内容缓存下来——下次命中缓存的部分,价格直接降到原来的 10%,也就是便宜 90%。
具体的费率大概是这样:
操作类型 | 费率 | 说明 |
|---|---|---|
正常输入 | 1x | 基础价格 |
缓存创建(5分钟) | 1.25x | 首次建立 |
缓存创建(1小时) | 2x | 长效缓存 |
缓存读取 | 0.1x | 便宜 90% |
官方渠道的缓存命中率大概在 80%~85%。多数正常使用下,后续请求里大部分 tokens 都走缓存,实际成本大概是标价的 28% 左右。
中转站的情况呢?
逆向渠道本身不支持缓存。Kiro、Cursor、Windsurf 这类客户端的逆向接口,没有实现 Prompt Caching,中转站拿到这个接口,本质上就是把缓存这个功能给去掉了。
另外是号池轮询的问题。中转站用多账号轮换分配请求——你第一次请求在账号 A 建了缓存,第二次请求分到了账号 B,缓存直接作废,又要重建。缓存建了不少,但能命中的极少。
还有一种更隐蔽的:有些中转站声称自己有缓存,实际是把缓存率写死在返回值里(比如固定返回 80%~88%),根本不是真实数据。
来算一笔账,假设你的对话历史是 50K tokens,对话了 100 次:
场景 | 首次成本 | 后续 99 次 | 总成本 |
|---|---|---|---|
官方(缓存率 80%) | 100 | 99 × 28 = 2772 | 2872 |
中转站(便宜 70%,无缓存) | 30 | 99 × 30 = 2970 | 3000 |
单次看,中转站确实便宜。但用得越多,这个差距就越往反方向走。
对话次数越多、上下文越长,官方的优势就越大。短对话是中转站的主场,长对话是官方的主场。
凭空消失的 25K:隐藏的系统提示词
回到开头那个问题——新建对话,什么都没做,/context 就显示 25K,问题出在哪?
中转站注入了你看不见的系统提示词。
逆向接入 Kiro、Cursor 这类客户端,这些客户端本身有一套系统提示词,专门为代码场景设计,内容很长。你的请求发进去,会被自动加上这段提示词,你不知道,但每次都在计费。
除了客户端自带的,有些中转站为了"优化"体验,还会往请求里塞自己的提示词。如果中转站是多层转发(A 从 B 拿货,B 从 C 拿货),每层都可能注入一段,叠加下来 25K 起步不奇怪。
验证方式很简单:
-
用自己的 Claude Pro 账号,新建一个对话,输入
/context,记录基础消耗 -
用中转站,同样操作,记录基础消耗
-
两者对比
注意:官方新对话本身也有系统提示和工具调用的基础消耗,不会是 0。重点是看两者的差值有多大。超出官方数倍的,基本可以确认中转站有注入提示词。
这种隐藏提示词最坑的地方在于:它每次都要全量计费,因为根本无法缓存。
这里推荐使用官方的Claude Pro套餐:Claude Pro 信用卡频频被拒?用 N26 + Apple Pay 丝滑升级保姆级教程
切换服务商:每次都是重新起步的成本
中转站不稳定是常态,很多人都同时备了两三个,随时准备切换。但切换这件事,本身也有成本,而且容易被忽视。
每次切换到新的服务商,之前建立的所有缓存全部清零。假设你已经聊了很长,在 A 上每次请求成本是 100,切到 B 之后,第一次重建缓存的成本可能要 500——因为 token 全部变成正常输入,没有缓存可以命中。
如果一天切换几次,这个额外成本累积下来相当可观。加上中转站本身缓存率就低,两件事叠在一起,成本结构就完全变了。
其他容易被忽略的坑
套餐日度限额:有些便宜套餐标着月费很低,但每天有额度上限,超出就按量计费,超出部分的单价可能比官方还贵。买之前一定要确认清楚日限额是多少。
重试成本:低价分组经常出现 timeout 或者 filter,超时之后客户端会自动重试,每次重试都要重新计费。这部分成本从账单上根本看不出来,但日积月累不少。
计费展示问题:有些中转站的缓存创建和缓存读取费率展示混乱,或者计费精度有问题,导致账单看起来对,但和实际消耗对不上。
什么时候值得用,什么时候不值得
使用场景 | 建议 | 原因 |
|---|---|---|
短对话、轻量使用 | ✅ 适合 | 上下文少,缓存影响不大 |
临时测试、偶尔用 | ✅ 适合 | 不需要长期稳定 |
预算极度有限 | ✅ 适合 | 接受不稳定前提下 |
长对话、重度使用 | ❌ 不适合 | 缓存损失远超差价 |
需要稳定不能断 | ❌ 不适合 | 切换成本高,缓存频繁丢失 |
追求账单透明 | ❌ 不适合 | 隐藏消耗难以核查 |
建议
还是不建议大家使用第三方的中转服务,因为里面涉及到的内容太多了。有人会说时间折腾成本不是更高,但是学习折腾这些东西的过程其实也是一种学习的方式和方法。
如果你不想折腾直接买官方,别人注册好的或者找人帮你处理。但是如果你想免费体验,使用第三方的中转服务也无可厚非,因为不是你的生产力工具。
每个人的选择不一样,我的建议是的如果有能力支持一下付费也是很好的。但是对于一般人来说购买正价的服务,价格还是稍高的,但是如果变成你的生产力你想稳定的使用付费找服务就是你最好的选择。