博客 / 模型观察

大模型 API 价格变了怎么第一时间知道：更新日志、模型目录与账单三路追踪

2026-10-17cdnping 编辑部约 6 分钟读完

想及时知道大模型 API 价格调整、上新或下架，比较省事的办法是同时盯三类信息源：厂商的官方更新日志和价格页、OpenRouter 这类聚合平台的公开模型目录、你自己账单和请求日志里的异常。前两类可以交给工具自动比对，cdnping 的 官网动态 /changes 和 模型监测 /models 分别覆盖这两块；第三类只能你自己接入。下面说明每类信息源能告诉你什么，怎么订阅，以及想自己写脚本时该怎么搭。

#厂商会通知调价，为什么还要自己追踪

厂商调价或下线旧模型时可能会发邮件，但邮件一般发到账号绑定的邮箱，团队里实际写代码、配路由的人未必收得到。还有几种变化不一定有单独通知：

• 价格页上某一行悄悄改了，或者缓存命中价、长上下文分档价单独调整；
• 第三方推理供应商对同一个模型换了量化精度，例如从 fp8 换成 fp4；
• 某个模型 ID 从聚合平台的目录里消失，或者多了一个带日期后缀的新 ID。

这些变化会影响成本或输出质量。靠人每周翻一遍网页容易漏，适合做成自动比对。

#该盯哪三类信息源，各自能回答什么

几点需要注意：

1. 官方页面是准绳。聚合平台上的标价是它自己的售价，和官方直连价格不一定相同，调价结论以厂商价格页为准。
2. 更新日志和价格页要分开盯。两者不一定同时更新，只盯一个可能晚几天才发现。
3. 结构化数据要先清洗。OpenRouter 目录里有特殊值，直接拿来算最小值会得出错误结论，下面有实例。

#用 cdnping 的 /changes 和 /models 能看到哪些变化

#官网动态 /changes：盯官方网页的逐行增删

cdnping 是面向开发者的免费网络观测站。/changes 监控 DeepSeek、OpenAI、Codex、Claude、Gemini、xAI、Kimi、阿里云百炼等 11 个官方更新日志、价格页和新闻页。它的做法是定期抓取页面正文，与上一次快照逐行比较，把新增和删除的行记录下来。你看到的是原文哪一行被加上或删掉，影响由你自己判断。

这个页面带 RSS，订阅 RSS 比每天打开网页更不容易漏。

#模型监测 /models：盯 OpenRouter 目录和推理供应商

/models 读取 OpenRouter 的公开 API，展示各家最新模型在每个推理供应商上的可用率、延迟、吞吐和量化精度，并自动记录四类事件：上架、下架、调价、量化变化。

下面是 cdnping 在 2026 年 10 月 17 日对 OpenRouter 公开模型目录做的单日快照：

• 目录中共有 376 个模型条目；
• 输入价格字段的最大值是 150；
• 输入价格字段的最小值是 -1000000。这显然不是真实价格，而是特殊条目使用的占位值。

最后一条是自己写脚本时容易踩的坑：不先过滤负数和占位值，“目录最低价”会算成负数，调价告警也会误报。cdnping 从 2026-10-17 才开始采集，这只是单日快照，不代表长期趋势。

同一天的供应商数据里还能看到量化精度的差别：同一个模型在不同推理供应商上，有的标注 fp8，有的标注 fp4、mxfp4 或 int4，也有不少未标注。如果你通过聚合平台调用，输出质量的波动可能来自供应商切换，而不是模型本身变了。/models 会把量化变化记成事件，排查时可以先对一下时间点。

/models 页面还附有几个第三方“模型变笨”评测项目的导航（Livenerf、AI Stupid Level、Is It Nerfed?、BridgeBench Nerf Bench），cdnping 不转载它们的数据，需要时去原站看。

#怎样把调价和上新提醒推到团队群

下面的步骤按先个人、后团队的顺序排列。

#第 1 步：订阅 /changes 的 RSS

打开 /changes，复制页面上的 RSS 地址，加到你常用的阅读器里。只关心部分厂商的话，可以在阅读器里按标题关键词过滤，例如只保留含“DeepSeek”“价格”的条目。

#第 2 步：把 RSS 接进团队群

常见做法有两种：

• 飞书、钉钉、企业微信的群机器人都支持 Webhook。用一个定时任务读取 RSS，把新条目推到 Webhook 即可，具体参数以各平台的官方文档为准。
• 如果团队已经在用支持 RSS 订阅的协作工具，直接在频道里添加订阅。

建议单独建一个“模型变更”频道，不要和告警频道混在一起。调价和上新属于需要阅读的信息，不是需要马上处理的故障。

#第 3 步：把 /models 加入每周例行检查

/models 的事件更适合定期翻看。可以把它放进每周的例行检查清单，和 稳定性周报 /reports 一起看，周报每周一自动生成，也可以订阅。

#第 4 步：约定谁来判断影响

提醒只解决“知道”的问题。团队里最好明确一个人每周过一遍变更，按下面的清单判断：

• 我们在用的模型 ID 是否出现在下架或停用条目里？停用日期是哪天？
• 价格变化涉及输入、输出还是缓存命中？对月度预算的影响按自己的用量估算。
• 新模型是否值得试？先在测试环境用小流量对比，再改生产配置。
• 通过聚合平台调用的模型，供应商的量化精度有没有变化？
• 代码里写死的模型 ID、单价常量是否需要同步修改？

#自己写追踪脚本该怎么搭

如果你需要盯 cdnping 没覆盖的页面，或者想把数据存进自己的系统，可以按下面的思路写。这里用伪代码，语言和调度方式按你的环境选，例如 cron、CI 的定时任务或云函数。

#思路一：比对 OpenRouter 目录

OpenRouter 的模型列表接口是公开的（GET https://openrouter.ai/api/v1/models），返回每个模型的 ID、上下文长度和标价。字段含义和价格单位以 OpenRouter 官方文档为准。

每 6 小时执行一次（频率仅为示例）：
  current = 请求 OpenRouter 模型列表，取 data 数组
  previous = 读取上一次保存的快照（没有则保存后退出）

  清洗：
    对每个模型，把 prompt / completion 价格转成数字
    价格 < 0 或无法解析的，标记为“特殊条目”，不参与调价比较
    统一换算成“每百万 token 的美元价格”，方便人读

  比较：
    新增 = current 里有、previous 里没有的模型 ID      -> 记为“上架”
    消失 = previous 里有、current 里没有的模型 ID      -> 记为“下架”
    对两边都有的 ID：
      若价格变化超过阈值（例如 0.5%，避免浮点误差误报） -> 记为“调价”，写明旧价和新价
      若上下文长度变化                               -> 记为“规格变化”

  输出：
    把事件列表推送到群机器人 Webhook
    保存 current 作为新的 previous

几个细节：

• 只推自己在用的模型。目录有几百个条目，全量推送很快就没人看了。维护一个关注列表，其余变化只写日志。
• 连续两次确认再告警。接口可能返回不完整的数据，某个 ID 临时缺失不一定是下架，可以要求连续两次快照都缺失才发“下架”通知。
• 保存原始响应。出现争议时，原始 JSON 比你的摘要更有说服力。

#思路二：比对官方更新日志和价格页

每天执行一次，对每个关注的 URL：
  html = 抓取页面（带合理的 User-Agent，频率放低，遵守站点的 robots 规则）
  text = 提取正文：去掉导航、页脚、脚本，保留表格文字，每行一条
  previous_text = 读取上次保存的正文

  diff = 按行比较 previous_text 和 text
  若 diff 为空：退出
  过滤噪音：忽略只包含日期、访问量、随机 ID 的行
  若过滤后仍有新增或删除：
    推送“页面 + 新增行 + 删除行 + 原页链接”
  保存 text

这类脚本的维护成本主要在提取正文这一步。页面改版、改用前端渲染，都会让提取结果整页变化，触发一次误报。遇到这种情况，人工确认后更新提取规则即可。如果你只关心 cdnping 已覆盖的那 11 个页面，直接订阅 /changes 的 RSS 更省事。

#思路三：从自己的账单反推

厂商调价最终会体现在账单上。可以每天用请求日志里的 token 数乘以你记录的单价，算出预估费用，再和厂商控制台的实际扣费对比。两者偏差持续超过某个比例（比如 5%，按你的容忍度定），就说明单价可能变了，或者计费规则有调整，需要回头查价格页。

#通过聚合网关调用时，价格以谁为准

如果你通过多供应商网关调用模型，价格和可用模型取决于网关自己的定价和模型清单，官方调价不一定同步传导。以 AGI Plan 为例（cdnping 与 AGI Plan 由同一团队运营），它按月订阅、人民币结算、按 CU 计量，可用模型以 agiplan.dev/models 为准，套餐价格见 agiplan.dev/pricing。这种情况下，除了盯上游厂商，还要关注网关自己的模型页和公告。

#今天就能做的四件事

1. 现在就订阅 /changes 的 RSS，并推到团队的“模型变更”频道。
2. 把代码里写死的模型 ID 和单价整理成一份配置文件，下次调价只改一处。
3. 打开 /models，找到你在用的模型，看一下各推理供应商的量化精度和近 1 天可用率，记下现状作为基线。
4. 想了解各官方 API 入口的连通情况，可以顺带看 API 状态 /status；数据口径见 数据方法 /methodology。