【让成本透明化，卖的安心，买的放心】我应该在0.34元刀的基础上，加价多少给富可敌国？新的一年，我不想再用三色图选中转了
- 内容介绍
- 文章标签
- 相关推荐
TL;DR 买中转三步走
- 去群里/找商家问最近一周他们opus4.6的缓存命中有多少？低于80%直接抬走下一位，双赢的事我不明白除了想躺着挣钱，还有什么理由不研究缓存技术。
- 找状态页/直接在群里问问，看看他们这一周的稳定性，确保你购买的月卡有机会用满。
- 找个能算明白账，知道自己挣得是用户的什么钱的商家。
- 以上都走不通就买小额（固定充值），自己实测一周，不要为了贪月卡那个看起来很低的单价而冲动消费。
- 再次提醒，在没有搞清楚上面几件事前，不要看什么单价，那不是在选购前期该操心的事！！！
- 最后提醒，如果你找到了满足上述条件的几家，这个时候你可以，以 性价比=稳定性/单价 为考虑确定最终的大额充值。
《订阅Claude Max 5×为什么等于用0.34元/刀买中转API》
摘要：本文主要基于 参考文章：Suspiciously precise floats, or, how I got Claude’s real limits，完整推导从"周Credit限额"到"每元人民币能买多少美元API服务"的并给出最终结论为，重度Claude Code用户的实际采购价低至 0.34元/刀。
本文基本为笔者在学习参考文章时的个人理解和实践，由于原文有些晦涩难懂故记录。
一、蠢坏的Anthropic
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
显然，由字面意义可知，其代表的意义大概率是：
\text{usage\_ratio} = \frac{\text{你已消耗的 Credits}}{\text{你的总限额 Credits}}然而奇怪的是，anthropic并没有给出一个百分比整数（例如16%），而是给出了一个看起来十分精确的小数，那么由小学数学得知，当我们抓包到usage_ratio后可以搞出来一个分数（最幸运的是如果我们得到了一个有限小数，我们甚至可以直接写出已消耗的和总限额 Credits的数值，即下例），就可以继续往下计算并记录每次请求的消耗和总额Credits，最终只需估算出Credits与Toekns的关系，我们即可得到订阅的真实tokens额度！
每个窗口有多少额度？
打开浏览器，按下F12后，正常与claude对话，找到带有/completion字样的请求URL，找到响应体，搜索message_limit，分析一下这个数据包。（笔者使用reqable工具，需要的话自行了解）
image-202602161419236401030×801 39.6 KB
可以看到，在笔者复现时（使用的一个claude 普号），截止2026-02-16，claude的响应字段已经发生了变化，utilization为两位小数，不知道是否是anthropic对小数做了截断还是没升级max的原因。但并不影响理解，我们接着向下计算即可。
由于这个请求恰恰是笔者5h windows内的第一个请求，所以我们可以直接得到该请求使用了
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）一个示例如下图，
image-202602161531096023049×1721 274 KB
提取相关字段的所有文本信息，则可以通过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价格，熟悉的感觉是不是一下子就来了？
image-202602161611533571723×925 92.8 KB
那么结论就很简单了，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元/刀上
image-202602161719176861996×1599 200 KB
只需看最后一个公式得到结论，我们需要给自己的场景进行画像，计算缓存读和写入的比例与写入和输出的比例，即可得到最终的采购价！
故而我爬取了自己在某中转使用的一周真实记录，并计算了这两个比例，结论如下：
| 类型 | Token 数 | 占总输入比 |
|---|---|---|
| Cache Read | 111,275,073 | 82.9% |
| Cache Write | 20,948,035 | 15.6% |
| Fresh Input | 2,003,501 | 1.5% |
| 总输入 | 134,226,609 | 100% |
| Output | 1,278,444 | — |
代入公式可得我的cache加成为1.558，故而我如果订阅Max5相当于选择的中转采购价为0.53/1.558=0.34元/刀。
注意，这是使用中转的真实记录，也就是说我的缓存命中完全取决于中转技术如何，如果中转技术好一些+最近cc改成了1h缓存写，这个单价将更低。
五、0.34元/刀仅为理论参考值，我愿意为承担封号风险的中转付多少钱？
在得出上述结论后我当然是马不停蹄的去订阅Max5，然后就得到了如下乐子，促使我思考如果搞一套家宽，折合下来的单价会比0.34元/刀高多少呢？ 这个问题局限于我手头上既没有现成的家宽，也没有更多的claude号，只能留给大家讨论了。
image-202602161745412151504×878 154 KB
网友解答：--【壹】--：
孙佬新年快乐！每一篇我都会认真的看
--【贰】--：
新年快乐，辛苦了孙佬
--【叁】--：
新年快乐佬，这周（2.9-2.15) 刚好用光（用到100%）我的5x订阅，数据如下，不知对大家有没有帮助，来源于ccusage，应该是比较准的。
image2064×866 85.6 KB
--【肆】--：
没事不重要，新年快乐！
--【伍】--： Linus Torvalds:
xun:我纯白嫖啊
但身为白嫖用户，暂时用不上
哈哈哈哈，新年快乐两位佬~
--【陆】--：
大佬，也就是说开max等于在中转站购买0.53元比一刀的额度是吗？唯一的风险是来自于封号？
--【柒】--：
哈哈，手头一共就这么几个项目
--【捌】--：
能学到官方套餐等效限额，非常有用！佬辛苦了捏，新年快乐~
--【玖】--： 锦衣夜行孙大侠:
7.5刀=1MCredits！
我很喜欢这种经过一系列精密计算之后得到一个非常漂亮非常符合直觉的结果的感觉！
--【拾】--：
孙佬新年快乐
写的很详细
但身为白嫖用户，暂时用不上
--【拾壹】--：
看完我也想开MAX5了
--【拾贰】--：
新年快乐孙佬~ 我纯白嫖啊，不考虑这些~
--【拾叁】--：
新年快乐佬~
--【拾肆】--：
这个input感觉应该只算了我自己的输入，没算阅读代码的输入，不然感觉也太低了）
--【拾伍】--：
确实，孙佬总结的好！！
--【拾陆】--：
非常合理，一看就是缓存命中大户
--【拾柒】--：
叽里咕噜说啥呢，新年快乐哇孙佬！
--【拾捌】--：
好家伙，有知乎遗风，这数据列的太漂亮了！
计算过程有理有据。。
这样的话，似乎自己买100刀是最划算的，如果封号了还能拿到退款。。。
--【拾玖】--：
新年快乐佬
TL;DR 买中转三步走
- 去群里/找商家问最近一周他们opus4.6的缓存命中有多少？低于80%直接抬走下一位，双赢的事我不明白除了想躺着挣钱，还有什么理由不研究缓存技术。
- 找状态页/直接在群里问问，看看他们这一周的稳定性，确保你购买的月卡有机会用满。
- 找个能算明白账，知道自己挣得是用户的什么钱的商家。
- 以上都走不通就买小额（固定充值），自己实测一周，不要为了贪月卡那个看起来很低的单价而冲动消费。
- 再次提醒，在没有搞清楚上面几件事前，不要看什么单价，那不是在选购前期该操心的事！！！
- 最后提醒，如果你找到了满足上述条件的几家，这个时候你可以，以 性价比=稳定性/单价 为考虑确定最终的大额充值。
《订阅Claude Max 5×为什么等于用0.34元/刀买中转API》
摘要：本文主要基于 参考文章：Suspiciously precise floats, or, how I got Claude’s real limits，完整推导从"周Credit限额"到"每元人民币能买多少美元API服务"的并给出最终结论为，重度Claude Code用户的实际采购价低至 0.34元/刀。
本文基本为笔者在学习参考文章时的个人理解和实践，由于原文有些晦涩难懂故记录。
一、蠢坏的Anthropic
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
显然，由字面意义可知，其代表的意义大概率是：
\text{usage\_ratio} = \frac{\text{你已消耗的 Credits}}{\text{你的总限额 Credits}}然而奇怪的是，anthropic并没有给出一个百分比整数（例如16%），而是给出了一个看起来十分精确的小数，那么由小学数学得知，当我们抓包到usage_ratio后可以搞出来一个分数（最幸运的是如果我们得到了一个有限小数，我们甚至可以直接写出已消耗的和总限额 Credits的数值，即下例），就可以继续往下计算并记录每次请求的消耗和总额Credits，最终只需估算出Credits与Toekns的关系，我们即可得到订阅的真实tokens额度！
每个窗口有多少额度？
打开浏览器，按下F12后，正常与claude对话，找到带有/completion字样的请求URL，找到响应体，搜索message_limit，分析一下这个数据包。（笔者使用reqable工具，需要的话自行了解）
image-202602161419236401030×801 39.6 KB
可以看到，在笔者复现时（使用的一个claude 普号），截止2026-02-16，claude的响应字段已经发生了变化，utilization为两位小数，不知道是否是anthropic对小数做了截断还是没升级max的原因。但并不影响理解，我们接着向下计算即可。
由于这个请求恰恰是笔者5h windows内的第一个请求，所以我们可以直接得到该请求使用了
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）一个示例如下图，
image-202602161531096023049×1721 274 KB
提取相关字段的所有文本信息，则可以通过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价格，熟悉的感觉是不是一下子就来了？
image-202602161611533571723×925 92.8 KB
那么结论就很简单了，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元/刀上
image-202602161719176861996×1599 200 KB
只需看最后一个公式得到结论，我们需要给自己的场景进行画像，计算缓存读和写入的比例与写入和输出的比例，即可得到最终的采购价！
故而我爬取了自己在某中转使用的一周真实记录，并计算了这两个比例，结论如下：
| 类型 | Token 数 | 占总输入比 |
|---|---|---|
| Cache Read | 111,275,073 | 82.9% |
| Cache Write | 20,948,035 | 15.6% |
| Fresh Input | 2,003,501 | 1.5% |
| 总输入 | 134,226,609 | 100% |
| Output | 1,278,444 | — |
代入公式可得我的cache加成为1.558，故而我如果订阅Max5相当于选择的中转采购价为0.53/1.558=0.34元/刀。
注意，这是使用中转的真实记录，也就是说我的缓存命中完全取决于中转技术如何，如果中转技术好一些+最近cc改成了1h缓存写，这个单价将更低。
五、0.34元/刀仅为理论参考值，我愿意为承担封号风险的中转付多少钱？
在得出上述结论后我当然是马不停蹄的去订阅Max5，然后就得到了如下乐子，促使我思考如果搞一套家宽，折合下来的单价会比0.34元/刀高多少呢？ 这个问题局限于我手头上既没有现成的家宽，也没有更多的claude号，只能留给大家讨论了。
image-202602161745412151504×878 154 KB
网友解答：--【壹】--：
孙佬新年快乐！每一篇我都会认真的看
--【贰】--：
新年快乐，辛苦了孙佬
--【叁】--：
新年快乐佬，这周（2.9-2.15) 刚好用光（用到100%）我的5x订阅，数据如下，不知对大家有没有帮助，来源于ccusage，应该是比较准的。
image2064×866 85.6 KB
--【肆】--：
没事不重要，新年快乐！
--【伍】--： Linus Torvalds:
xun:我纯白嫖啊
但身为白嫖用户，暂时用不上
哈哈哈哈，新年快乐两位佬~
--【陆】--：
大佬，也就是说开max等于在中转站购买0.53元比一刀的额度是吗？唯一的风险是来自于封号？
--【柒】--：
哈哈，手头一共就这么几个项目
--【捌】--：
能学到官方套餐等效限额，非常有用！佬辛苦了捏，新年快乐~
--【玖】--： 锦衣夜行孙大侠:
7.5刀=1MCredits！
我很喜欢这种经过一系列精密计算之后得到一个非常漂亮非常符合直觉的结果的感觉！
--【拾】--：
孙佬新年快乐
写的很详细
但身为白嫖用户，暂时用不上
--【拾壹】--：
看完我也想开MAX5了
--【拾贰】--：
新年快乐孙佬~ 我纯白嫖啊，不考虑这些~
--【拾叁】--：
新年快乐佬~
--【拾肆】--：
这个input感觉应该只算了我自己的输入，没算阅读代码的输入，不然感觉也太低了）
--【拾伍】--：
确实，孙佬总结的好！！
--【拾陆】--：
非常合理，一看就是缓存命中大户
--【拾柒】--：
叽里咕噜说啥呢，新年快乐哇孙佬！
--【拾捌】--：
好家伙，有知乎遗风，这数据列的太漂亮了！
计算过程有理有据。。
这样的话，似乎自己买100刀是最划算的，如果封号了还能拿到退款。。。
--【拾玖】--：
新年快乐佬