【Claude】到底是选择中转还是官方订阅？

小冯Coding

642人浏览 · 2026-03-18 17:49:31

小冯Coding · 2026-03-18 17:49:31 发布

一、Claude，到底是选择中转还是官方订阅

买中转

去群里/找商家问最近一周他们opus4.6的缓存命中有多少？低于80%直接抬走下一位，双赢的事我不明白除了想躺着挣钱，还有什么理由不研究缓存技术。
找状态页/直接在群里问问，看看他们这一周的稳定性，确保你购买的月卡有机会用满。
找个能算明白账，知道自己挣得是用户的什么钱的商家。
以上都走不通就买小额（固定充值），自己实测一周，不要为了贪月卡那个看起来很低的单价而冲动消费。
再次提醒，在没有搞清楚上面几件事前，不要看什么单价，那不是在选购前期该操心的事！！！
最后提醒，如果你找到了满足上述条件的几家，这个时候你可以，以性价比=稳定性/单价为考虑确定最终的大额充值。

Claude官方定价

Claude Max 5× 订阅价 $100/月（约 720 元人民币）。Anthropic 官网对额度的描述是：

5 小时内约 50-200 个 Claude Code 提示

什么叫做claude code提示？为什么会有50~200这么大的浮动？
一个提示等价于多少tokens？等价于多少刀？
自从周限提出来后，用户每周能用的总量到底是多少？

有用的东西anthropic官方是一概不答，说些废话有个der的参考价值，所以这篇文章的核心目的就是让订阅用户心中有数，同时让购买中转的用户有一个基础参考。

二、一次普通的抓包，一个玄妙的浮点数

发现之始

大佬 she-llac 在抓包到 Claude 的 SSE（Server-Sent Events）响应时，注意到一个字段：

usage_ratio: 0.16327272727272726

显然，由字面意义可知，其代表的意义大概率是：

usage_ratio=你已消耗的Credits你的总限额Credits

然而奇怪的是，anthropic并没有给出一个百分比整数（例如16%），而是给出了一个看起来十分精确的小数，那么由小学数学得知，当我们抓包到usage_ratio后可以搞出来一个分数（最幸运的是如果我们得到了一个有限小数，我们甚至可以直接写出已消耗的和总限额 Credits的数值，即下例），就可以继续往下计算并记录每次请求的消耗和总额Credits，最终只需估算出Credits与Toekns的关系，我们即可得到订阅的真实tokens额度！

每个窗口有多少额度？

打开浏览器，按下F12后，正常与claude对话，找到带有/completion字样的请求URL，找到响应体，搜索message_limit，分析一下这个数据包。（笔者使用reqable工具，需要的话自行了解）

在这里插入图片描述

可以看到，在笔者复现时（使用的一个claude 普号），截止2026-02-16，claude的响应字段已经发生了变化，utilization为两位小数，不知道是否是anthropic对小数做了截断还是没升级max的原因。但并不影响理解，我们接着向下计算即可。
由于这个请求恰恰是笔者5h windows内的第一个请求，所以我们可以直接得到该请求使用了

0.14=750

7 Credits，整个5h窗口的额度为50 Credits，我们就能得出结论“claude普号5h能用的总额为50 Credits，且似乎没有7d周限！“当我们得到的utilization为无理数时，使用Stern-Brocot 树同样可以得到一个分数，总而言之就是想方设法得到一个分数并从分母中总结出周期限额，具体的数学推导这里就不再赘述。经过原文大佬大量的实验最终得到了如下表格：

套餐	5小时 Credit 限额	周 Credit 限额
Pro ($20)	550,000	5,000,000
Max 5× ($100)	3,300,000	41,666,700
Max 20× ($200)	11,000,000	83,333,300

同时，类似上述过程，我们可以通过多次发送请求记录该字段的变化，为之后的Credits-Tokens换算公式估计做准备。

Credits-Tokens换算

接下来我们使用分子7 Credits来推导Credits-Tokens换算公式。首先我们可以从整个消息记录（存放在 https://claude.ai/api/organizations/${orgId}/chat_conversations/${conversationId}?tree=true&rendering_mode=messages&render_all_tools=true）一个示例如下图，

在这里插入图片描述

提取相关字段的所有文本信息，则可以通过GPTTokenizer_o200k_base估算出每个请求以及响应的输入输出tokens，具体算法可以参考 she-llac编写的浏览器扩展。值得一提的是，作者非常严谨的考虑了缓存读取的问题，并在每次记录时对缓存状况也进行了特殊记录（距上次回复 < 5min 为热启动；大于五分钟冷启动，所有输入均视为为input tokens），最终汇总所有记录，可以得到类似于这样的一个表格：

┌─────┬────────┬──────────┬───────────┬──────────┬──────────┐
│  #  │ Model  │ Δcredits │ input_tok │ out_tok  │  cache?  │
├─────┼────────┼──────────┼───────────┼──────────┼──────────┤
│  1  │ Sonnet │  6,000   │   5,000   │  1,200   │  cold    │
│**2**│ Sonnet │  4,200   │   8,000   │  1,200   │  warm    │
│  3  │ Opus   │ 10,667   │   5,000   │  1,200   │  cold    │
│  4  │ Haiku  │  1,467   │   5,000   │  1,200   │  cold    │
│  5  │ Sonnet │  2,600   │   1,000   │  1,000   │  cold    │
│ ... │  ...   │   ...    │    ...    │   ...    │   ...    │
└─────┴────────┴──────────┴───────────┴──────────┴──────────┘

通过大量的数据分析，我们会发现一个有趣的现象，观察上表中的2号记录输入非常多但额度消耗却显著低于1号记录，而且细算下来发现这个额度差异恰好体现在2号请求仅有最后一次用户输入被当做了input tokens，这意味着 cache read 部分不计入 credits！

之后控制变量，提取所有没缓存读的记录，分析不同的模型，设方程为Δcredits = input_tokens × R_in(model) + output_tokens × R_out(model)，则可类似于下例计算(tokens以M为单位)：

## model为sonnet-4.5
实验 A:  Δcredits_A = 0.01M × R_in + 0.01M × R_out
实验 B:  Δcredits_B = 0.10M × R_in + 0.05M × R_out

## 两个方程，两个未知数 → 可解
R_in(Sonnet)  = 0.4         =  6/15
R_out(Sonnet) = 2.0         = 30/15

## 类似的，可以算得opus和haiku的费率
R_in(Opus)    = 0.6666...   = 10/15 
R_out(Opus)   = 3.3333...   = 50/15 

R_in(Haiku)   = 0.1333...   =  2/15
R_out(Haiku)  = 0.6666...   = 10/15

由此可以得到几个明显的规律：

┌─────────────────────────────────────────────────────────┐
│  规律 1:  output_rate = input_rate × 5   (所有模型)       │
│  规律 2:  Opus_rate = Haiku_rate × 5                     │
│  规律 3:  Sonnet_rate = Haiku_rate × 3                   │
│                                                         │
│  统一分母:  所有费率都能写成 N/15 的形式，再次除2得到下表       │
│                                                         │
│       │ Input (×/7.5) │ Output (×/7.5) │                │
│  Haiku│     1        │     5         │                  │
│ Sonnet│     3        │     15        │                  │
│  Opus │     5        │     25        │                  │
└─────────────────────────────────────────────────────────┘

怎么样，再看看API价格，熟悉的感觉是不是一下子就来了？

在这里插入图片描述

那么结论就很简单了，7.5刀=1MCredits！

Pro/ Max 5h/周/月限额

月限额基于， 52周/年 ÷ 12月/年 = 4.333 周/月，等比于周限额算得

注意，该表格得出的前提是完全没有缓存，即表中的刀换算为理论下界值。

套餐	5h Credit 限额	5h $ 限额	7d Credit 限额	7d $ 限额	月 $ 限额
Pro ($20)	550,000	$4.1	5,000,000	$37.5	$163
Max 5× ($100)	3,300,000	$24.8	41,666,700	$312.5	$1,354
Max 20× ($200)	11,000,000	$82.5	83,333,300	$625.0	$2,708

三、性价比之选

再次强调，目前为止所有表格中的数据为保守下界，即 100% 用满额度，且没有任何缓存加成。 当我们假设汇率为7.2元/刀后，我们可以得出下列表格：

套餐	月 Credits	月等效 API 价值	订阅价	性价比	采购价
Pro	21.7M	$163	$20	8.1×	0.88 元/刀
Max 5×	180.6M	$1,354	$100	13.5×	0.53 元/刀
Max 20×	361.1M	$2,708	$200	13.5×	0.53 元/刀

注意：Max 5× 和 20× 的单位性价比完全相同，都是 13.5×。但这还不是全部——缓存机制会拉开真正的差距。

四、中转选购经济学：缓存画像

三、中的结论是把所有 token 当作"从零开始处理"来算。但现实中，每次你和 Claude 对话时，Claude 需要"阅读"整段对话历史，这就导致在写代码场景下后期用户轻轻松松就会有上百K的输入，这样的话底裤都要掏给anthropic了。但聪明的claude code在组织messages时，会通过缓存控制，把一段 10K tokens 的输入在对话时进行缓存，下次用户再有新10K tokens来时，anthropic则可以采用“追加”式推理，并不需要重新处理全部 20 K token。

而我们再次回顾 三、**中的表格，其 **0.53 元/刀的大前提是用户没有一丁点缓存**，这对经常编码的我们来说怎么可能呢？而同时，在**二、**中的**Credits-Tokens换算一节，我们有重大发现是，订阅用户的缓存读是不要钱的！这意味着，我们可以通过提高缓存读来继续降低采购价！但在此之前，我们需要小小的推导一个公式，想一想理论上我们缓存如何增益刀0.53元/刀上

在这里插入图片描述