claude与deepseek注意事项：先分清两家的坑各在哪一类

搜「claude与deepseek注意事项」的人，多半是已经在两边都开了账号，或者正准备把同一条链路同时接两家。真正卡住的往往不是模型本身，而是账单口径对不上、缓存没命中还以为自己算错了、重试把额度烧掉。这篇不谈哪个更强，只给一份能照着走一遍的核对清单，每一项都说清什么情况下不适用。

搜这个词的人，通常不是刚听说这两家，而是账号已经开了，或者在琢磨把同一条链路同时接两边。卡住的地方往往不在模型聪不聪明，而在一些更琐碎的位置：账单对不上、以为吃了缓存其实没有、重试悄悄把额度跑光。这篇不聊谁更强，只按「哪里容易出错」分成四类，一项一项过。

先说个前提：下面每条都默认你是自己在调接口或用第三方客户端。如果你只是网页版聊天，大部分计费和缓存问题碰不到，但限速和免费额度的边界还是值得看一眼。分清这个，后面的清单才不至于白抄。

第一件事：两家的钱是怎么算的，别用同一套直觉

很多人第一次对账对不上，是因为脑子里只有一个「每百万 token 多少钱」的印象。实际计费口径里，输入、输出、缓存写入、缓存读取是几个不同的单价，混着估必然出偏差。具体每一档怎么算，去 /official-api/providers/anthropic 和 /official-api/providers/deepseek 看当期口径，别拿记忆里的数去套。

更麻烦的是两家的缓存逻辑不是一回事。DeepSeek 那边对重复前缀比较敏感，你把固定内容放前面，命中率会自己上来；Claude 的缓存要显式打标记才生效，不打标记就等于每次都在为同一段内容重新付费。一个偏自动，一个偏手动，做法照搬一定翻车。

还有个容易漏的：如果你走的是中转站，倍率会在官方价上再叠一层。核对前先把这个页面的说法看明白，否则你拿官方价去对账单，怎么算都对不上，还以为是供应商多收了。

上下文和缓存：省钱的开关在哪一格

长文档任务最常见的浪费，是把固定内容和变动内容混着放。正确的顺序是先固定、后变动：系统提示、参考资料、示例放前面，每次真正变化的用户输入放后面。这样前缀稳定，缓存才有机会命中。顺序反了，等于每次都在为整段内容重新付费。

缓存没命中时，先别怀疑计费系统，先查前缀有没有被动过。改了一个标点、换了一个时间戳、在开头插了一句随机的话，前面的缓存就全废了。这种问题很隐蔽，因为代码逻辑看起来没变。

• 同一条链路连跑三次，账单几乎一样，说明大概率没吃到缓存，去看前缀是不是每次都变
• 三次之间费用有明显差异，才说明缓存起作用了，这时候再谈优化命中率
• 固定内容里别塞时间戳、随机 ID、会话标识这类每次都变的东西
• 变动内容尽量往后放，越靠后影响的前缀越少

限速和重试，最容易悄悄烧钱的地方

两家的并发和速率限制口径不一样。一边能扛住的批量任务，换到另一边可能直接被拒。实际用下来，最坑的不是被拒本身，而是被拒之后的重试逻辑——不带上限的死循环重试，既烧钱又拖长任务，日志里还看不出来。

1. 先量延迟基线不确定超时该设多少，就去 /tools/speed-test 跑一遍，拿实测值定超时，别拍脑袋
2. 给重试设上限和退避重试次数封顶，间隔逐次拉长；连续被拒就停下报错，别硬刷
3. 查清重复计费的边界被限速后重发算不算重复计费，看 /retry-billing-limits 的拆法，别自己猜
4. 批量任务先小样跑换一家跑批量前，先用小批量试一轮，确认限速能过再放大

这套做法不适用于一次性、低频的调用——那种场景设个简单超时就行，没必要上退避。但如果你的任务是批量跑、定时跑，或者给用户实时兜底，重试策略就必须提前想清楚。

免费额度和付费额度别混着算账

免费额度通常有模型范围和有效期限制。能免费用，不代表能拿它跑生产——真到量上去，免费额度一断，链路就停。具体规则去对应厂商页面看当时的数字，别拿别人截图里的额度当准。

另一个坑是把免费和付费的用量记在同一本账上。月底复盘时，你算出来的单位成本是混的，既不知道真实付费成本，也看不出免费部分到底省了多少。

• 小团队建议免费和付费分开记两条账，等规模稳定了再合并
• 免费额度测的是功能可行性，不是成本可行性，别拿它推生产预算
• 额度有效期临近时提前准备切换，别等任务跑到一半断掉
• 拿免费额度做压力测试时，注意它本身可能触发速率限制，测出来的数不代表付费档位