前阵子有位读者私信向我求助，他表示自己遇到了一个困惑：明明充值了价格仅为官方七成的 AI 中转站，却感觉并没有真正省下钱。他还发来一张截图，显示在新建立的对话中，一条消息都没发送，/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，记录基础消耗使用中转站，执行相同操作，记录基础消耗
将两者进行对比
这类隐藏提示词最坑人的地方在于：它每次都需要全量计费，因为它们根本无法被缓存。
切换服务商：每次都要重新起步的成本
中转站不稳定是常态，许多用户会同时准备两三个服务商，随时准备切换。然而，切换本身也存在成本，且容易被忽视。
每次切换到新的服务商，之前建立的所有缓存都会清零。假设你已经聊了很长时间，在服务商 A 上每次请求成本为 100，切换到 B 之后，第一次重建缓存的成本可能高达 500——因为所有 tokens 都变成正常输入，没有任何缓存可以命中。
如果一天内切换几次，这部分额外成本累积起来相当可观。再加上中转站本身的缓存率就很低，两个因素叠加后，成本结构就完全变了。
其他容易被忽略的坑
套餐日度限额：有些便宜套餐标着月费很低，但每天都有额度上限，超出部分会按量计费，甚至超出部分的单价可能比官方还贵。购买前务必确认清楚日限额的数值。
重试成本：低价分组经常出现 timeout 或 filter 问题，超时后客户端会自动重试，每次重试都需要重新计费。这部分成本从账单上根本看不出来，但日积月累下来并不少。
计费展示问题：部分中转站的缓存创建和缓存读取费率展示混乱，或者计费精度有问题，导致账单看起来没问题，但实际消耗与显示对不上。
什么时候值得用，什么时候不值得
使用场景 | 建议 | 原因 |
|---|---|---|
短对话、轻量使用 | ✅ 适合 | 上下文少，缓存影响不大 |
临时测试、偶尔用 | ✅ 适合 | 不需要长期稳定 |
预算极度有限 | ✅ 适合 | 在能接受不稳定的前提下 |
长对话、重度使用 | ❌ 不适合 | 缓存损失远超价格差 |
需要稳定不能断 | ❌ 不适合 | 切换成本高，缓存频繁丢失 |
追求账单透明 | ❌ 不适合 | 隐藏消耗难以核查 |
建议
总体而言，我依然不建议大家轻易使用第三方中转服务，因为其中涉及的变量和风险实在太多。有人可能会说，折腾这些花费的时间和精力成本更高，但学习并解决这些问题的过程，本身也是一种不错的学习途径和方法。
如果你不想折腾，直接购买官方服务，或者使用别人已注册好的账号、委托他人协助处理也行。但如果只是想免费体验，那么使用第三方中转服务也无可厚非——毕竟它还不是你的核心生产力工具。
每个人的选择各不相同。条件允许的话，支持一下付费服务当然很好；但对大多数人来说，官方正价服务确实偏贵。不过，一旦它真正成为你的生产力工具，并且你需要稳定使用时，付费找一个靠谱的服务，才是最佳选择。
