你的价格表多久会过期？四家的合同给了四个答案

先说结论，再说为什么。OpenAI 承诺 14 天，Anthropic 承诺 30 天或收到通知取先到者， Google 默认 30 天但新增付费服务可立即生效，DeepSeek 不承诺任何通知期、并明确建议你自己 定期查看价目页。 四家的条款分别写在四份不同文档的四个不同章节里，其中没有一条在你 收藏的那个价目页上。

这四个数字不是厂商风格的注脚。它决定了一件很具体的事：你手里那份价格表，最长可以多久 不刷新而不出错。

先看这周实际发生了什么

8 月 13 日，DeepSeek 官方 changelog 公告价目调整；8 月 16 日 16:00 UTC 生效。三天。

调整的不是数字，是结构——引入峰谷定价，谷时价为峰时价的一半。官方价目页写明峰时段为 工作日 UTC 01:00–04:00 与 06:00–10:00。换算成北京时间，是 09:00–12:00 与 14:00–18:00。

这个换算值得单独一行：峰时段几乎完整覆盖了中国的上班时间。 对英文市场的读者， 峰时段落在深夜；对我们，它就是工作日本身。

现行价目（deepseek-v4-flash，单位美元 / 百万 token）：

如果你的成本模型是 8 月 16 日之前建的，它在每个价格位上都只有一个数，而现在每个位置有两个。 问题不是估得偏了多少，是这张表少了一个维度。

同一周还有一件方向完全相反的事。Anthropic 撤销了一次已经公告过的涨价：Claude Sonnet 5 发布时的 $2/$10 标为「8 月 31 日前的引导价」，9 月 1 日起转 $3/$15。现在官方价目页写的是：

The $2/$10 per million input/output token pricing for Claude Sonnet 5, announced at launch as introductory pricing through August 31, 2026, is now the standard price. The previously scheduled increase to $3/$15 per million input/output tokens on September 1, 2026 will not occur.

引导价转为标准价，原定涨价不再发生。

这里要说清楚一件事：DeepSeek 的三天完全合规。 它的条款里没写通知期，给三天是它的 自由，没有任何违约或不当。把这两件事放在一起看，得到的结论不是「谁家厚道」——而是同一周里， 一家的条款下限被用满了，另一家往相反方向走。能不能提前知道，取决于你读没读过那条款。

四条条款，以及它们藏在哪

三条的措辞比数字更要紧。

OpenAI 的原文是：价目页上的价格变更在发布 14 天后生效；且 OpenAI 有权更正定价 错误——即使已经开具发票或已收到付款。两句在同一条 §6.6 里，而这条的标题是「更正」。 14 天是四家里最短的承诺期，第二句意味着一张你已经付过的账单不必然是最终的。

顺带一个容易踩的坑：同一份协议的 §16.13(a) 写着，实质影响客户权利义务的协议更新 提前 30 天通知。那条管的是「改协议」，不是「改价格」。价格走 §6.6 的 14 天，把 30 天 读串了会让你的复核周期直接翻倍。

Anthropic 的原文关键在 the earlier of：30 天与「客户收到通知」取先到者。 这个措辞对客户是收紧不是放宽——通知第三天到你手上，第三天就生效。30 天是等待时间的上限， 不是你规划期的下限。

Google 一句话里有两个 unless otherwise specified，外加一个括号：新增付费服务的定价 可立即生效。所以 30 天是默认值，默认值和承诺是两回事。

DeepSeek 写的是：价格可能变动，DeepSeek 保留调整权利；建议按实际用量充值，并定期 查看本页获取最新价格。没有期限，并且把监控义务明确交给了你。这在四家里其实是最坦白的 ——它描述的就是它实际会做的事。

还有一个和数字无关的发现：找到条款比读懂条款难。 OpenAI 的在「更正」项下而不是 「费用」项下，Google 的在附加条款而不是主服务条款里。如果你替公司做过一次供应商条款梳理， 你知道那二十分钟花在定位段落上，不是花在理解段落上。

幅度自己算，别信转述

关于这次 DeepSeek 调整的涨幅，二手报道给出的百分比区间流传很广。我们不引用，原因很简单： 那些百分比无法从现行价目页复现，基准是什么、比的是哪两个价，读者核不了。

能核的做法是这样：打开官方价目页，把你真实工作负载的三项配比（缓存命中输入 / 未命中输入 / 输出）乘上现价，再乘一遍你实际调用时段落在峰谷的比例。这个数才是你的涨幅，和别人算出来的 百分比没关系——峰谷结构下，涨幅取决于你什么时候发请求，两个用量完全相同的团队可以得到 完全不同的答案。

峰谷占比不用估：把最近一周的请求时间戳按 UTC 小时分个桶就有了，一条查询的事。 如果你现在答不出这个比例，那它本身就是第一个发现——这次调价之后，它是所有后续判断的输入。

给每家单独设一个复核频率

把条款翻译成一句运维语言：这家的价格表，最长可以多久不刷新而不出错？

其中两行其实不是频率问题。Anthropic 那行说的是通知渠道比日历重要——30 天可能被一封 没人看的邮件缩短。Google 那行说的是风险集中在接入时刻，因为立即生效的例外针对的是 新增服务，不是既有服务的调价。

DeepSeek 那行最值得多看一眼：没有承诺期的地方，你的复核频率就是通知期。 除此之外 没有别的东西在保护你。

所以「所有供应商的价格表统一每周刷新一次」这种设定，按构造就是错的——对一家太勤，对另一家 太慢，而对不承诺通知期的那家，永远太慢。这件事应该是配置，不该靠自觉。PiRouter 的价格层 设计为按供应商分别持有价格快照与各自的复核周期，让不承诺通知期的供应商走它自己的 轮询节奏，而不是继承一个为 30 天下限设计的间隔。这是设计取向，不是已上线承诺， 当前能力以文档为准。

不过要用上面那张表，你不需要等任何东西——一个日历提醒加一次页面 diff，能抓住同一类意外。

一句话

四家写了四个不同的承诺，而且这四个数字和厂商的规模、口碑、价格都对不上；最短的那个 14 天 还藏在「更正」条款下面。 这个月证明了这些下限不是摆设：一家在公告三天后重构了整张价目表，且完全在自己的条款之内。 把你依赖的每一家的这个数字查出来，写在成本模型里那家的旁边，然后用这个数字定复核周期， 而不是用习惯。

延伸阅读：你的 LLM 账单里有多少是看不见的（同样是计量 不可见性，从账单侧切入）。