同一个模型 18 家托管、6 倍价差：账单看不见的四处
同一周里，Codex 订阅用户在论坛逐小时记录自己的百分比条，DeepSeek 把同一个请求按时钟分成两个价，新上线的视觉模型把图片按尺寸折成 input token。三件事的共同点不是贵，而是你事先算不出、事后对不上。本文把几种计量不可见性放进同一张表，给出四条可核对的底线。
先回答标题。按 Kingy AI 的统计， 16 款 AI 产品的 85 条用量限额里，按 token 卖的 API 有 82% 在公开页面写了具体数字，按月订阅卖的 消费级助手只有 35%。这是行业面的答案。你自己账单里那个比例，本文给不出来——算不出来本身就是 问题。这一周有三件事把它摆到了台面上：OpenAI 论坛上一条关于 Codex 周额度的帖子从 8 月 14 日 盖到 175 楼，有人把两个 $200 的 Pro 账号逐小时记下百分比；DeepSeek 的峰谷计价生效第五天，同一个 prompt 在北京上午和下午是两个价；DeepSeek 新上线的视觉模型把每张图片按尺寸折成 input token 一起计费。
本文不比贵贱，只看能不能核。两个判据：「事先可算」，请求发出前你能按公开价目算出这一笔的价格； 「事后可核」，账单到手后你能用自己的日志逐笔对上。按这两个判据把几件事放进同一张表，最后给 四条底线，以及一个下个月账单到手之前就该做的动作。
第一种不可见：百分比条
先交代术语。Codex 是 OpenAI 的编程 agent，随 ChatGPT 订阅按周额度使用：Plus $20/月，Pro $200/月 （Pro 分 5x / 20x 两档）。额度在界面上显示为一根百分比条。
论坛那条帖子里最有信息量的一楼，是一位用户在 8 月 20 日的记录：两个独立的 Pro 账号在同一个早上 08:47 重置到 100%，各自跑一个长任务，到 17:14 一个剩 2%、另一个剩 18%（他三小时后的更新是 0% 和 6%）。他说同类任务以前一周额度能撑五六天，现在不到一个工作日。重点不是这两个数字本身，而是他 为什么要自己记时间戳：界面上只有一根百分比条，没有别的可以核对。
OpenAI 的回应：Codex 负责人 Thibault Sottiaux 在 8 月 21 日的 X 帖里说，调整用量上限不是公司会 不跟社区沟通就做的事；他的团队查了消耗异常快的账号，其中不少在跑 “sub2api”——把 ChatGPT 订阅 重新封装成按量 API 来调用的工具（Cryptopolitan 转述）。 这是两个月内的第二轮：6 月底那次查出是自动 review 和子 agent 重复跑导致多扣、已全量重置，7 月底 那次官方说新模型 GPT-5.6 Sol 跑得更久、做了调整让常规用量多撑约 18%。
第三方层面，Kingy AI 的调查结论是 supported but unproven：用户消耗异常快是可信的，「OpenAI 悄悄砍了额度」没有被证明。理由只有一句话，值得抄下来：
在一根取整的百分比条上，「额度变小」和「额度不变但消耗变快」看起来一模一样。
延迟刷新、周期重置点移动、子 agent 多跑一轮、客户端反复重发大上下文，每一种都会让那根条掉得 更快，而 OpenAI 没有暴露足够的逐轮历史数据让任何人把这些原因拆开。
用户自己造的尺子
于是有人自己造尺子。NerfTrack 是一个只跑在本地的 桌面工具，读 Codex 的本地日志，把 token 按 API 价目换算成美元，再和百分比条的变化量做比，反推 「100% 等于多少 API 美元」。它的算法文档 核心就是一个除法：
estimated_weekly_usd = cost_delta_usd / (percent_delta / 100)Reddit 与 X 上流传的「Plus 周额度从约 $160 掉到约 $80」就是这把尺子量出来的 （XenoSpectrum 对原帖的分析）。 工具自己的文档先声明了：它估的是 API 等价值，不是 ChatGPT 账单；取整误差和其他客户端的用量 它处理不了，非文本的计费项也不覆盖。百分比是取整的，分母 1 个百分点的误差在估算里被放大一百倍。 尺子量不准，说明的不是谁对，而是尺子本来不该由用户来造。
OpenAI 并不是什么都没公开。订阅额度的内部计量单位叫 credits；Sol / Terra / Luna 是 GPT-5.6 的 三个档位。按 Kingy 转引的 OpenAI 官方定价文档（本文未直接核原页），Sol 每百万 token 消耗 125 credits（未缓存输入）/ 12.5（缓存输入，即命中了 provider 缓存的重复前缀）/ 750（输出）， Terra 是 50 / 5 / 300，Luna 是 5 / 0.5 / 30；Fast mode 快约 1.5 倍、扣 credits 按 2.5 倍。文档 没给的是另一头：一周额度总共多少 credits。换算表有、总量没有，这个除法就做不了。信息在文档页上， 不在你的账单上。
一个旁证：非官方工具卖的也是明细
回到 Sottiaux 点名的 sub2api。它在 GitHub 上是一个开源项目， 掘金 4 月有篇介绍文的标题是《把 $200 的 Claude Max 拼成人均 ¥399》， 当时 15.2K star。做的事是把多个订阅账号接进一个网关，生成 API Key 分发给多人用，按 token 级计费。
先把风险说清楚：这是非官方转发，项目 README 自己就写着可能违反上游条款、封号风险自担；本文 不推荐也不提供部署指引；企业场景下它还意味着你的请求经过第三方网关，合规风险排在封号风险前面。 要看的只有一点：一个围绕「拼订阅」长出来的工具，功能列表里排在前面的是 token 级用量追踪与 成本计算。用户从这条渠道买到的除了便宜，还有官方订阅里没有的那层明细。需求信号在这里。
第二种：时钟——算得出，但容易漏算
这一条严格说不是「不可见」：价目公开，按 token 出账，两个判据都过。它进这张表的理由是漏算 与叠乘。英文刊上周有一篇展开，这里只取两段事实。 DeepSeek 从 8 月 16 日起把所有 V4 价目拆成峰谷两档，峰时是 01:00–04:00 与 06:00–10:00 UTC， 换成北京时间就是上午 9–12 点和下午 2–6 点；谷时价是峰时价的一半 （官方价目页）。V4 Flash 输出 token 谷时 每百万 $0.66、峰时 $1.32。
对中国开发者来说这意味着工作时间内的每一次调用都是峰时价。你的代码不知道现在几点，你的账单 知道。如果你的成本模型里没有「请求发出的 UTC 小时」这个字段，同一批请求落在峰时还是谷时，账单 差一倍，而你解释不了。漏掉的不是价目，是字段。
第三种不可见：像素
deepseek-v4-flash-vision-exp 8 月 21 日上线（官方 Change Log），
价目页上三档价格与 V4 Flash 逐项相同。图片的计费规则写在
Vision 文档的 Token Usage 一节：
每张图先缩放到约 800×800 的像素总量，再按尺寸折成 token，上限 384 token/张。量级很小——
按峰时输入价算，一张图约 0.017 美分。
不可见的不是钱，是两件事。其一，文档给的是规则和上限，你这张图的精确 token 数要到官方计算器上算，
detail 参数不同结果也不同。其二，图片的 token 进了 input token 的总数之后，账单上只剩一个数字，
你分不出哪些是字、哪些是图。再叠上第二种：同一批图在北京上午传和晚上传，又是两个价。
顺带一种：同名不同价
还有一种不可见性不出在计价规则，出在「你调的到底是哪个」。DeepSeek 官方 8 月 16 日提价之后， 第三方托管同一开源权重的价格并没有跟着动。Together 的价目页上 DeepSeek V4 Flash 0731 仍是每百万 $0.14 输入 / $0.28 输出。 OpenRouter 的同一模型页列了 18 家 provider， 输入价从 $0.0679 到 $0.44 不等，最集中的一档是 $0.14（8 家）；官方渠道那一行标 $0.22 / $0.66， 即官方的谷时价——峰谷在这页的列表里不体现，却在同一页的实付统计里体现：官方渠道输出的 listed 价 $0.66，effective 价 $1.012。列表上看不见的时钟，账单上看得见。
6 倍以上的价差是一回事，更麻烦的是版本标签。模型名后面的 0731 这类后缀通常是权重快照的日期； OpenRouter 页面标题写 “V4 Flash 0423”（也可能只是该页的上架日期），Together 写 “0731”，DeepSeek 官方价目页写 “DeepSeek-V4-Flash-0731”。它们是不是同一组权重，页面上看不出来。做价格对比之前先 做一件事：看响应里的 model 字段或版本头，没有就向 provider 要版本声明。代价是半天，比按错价目 签一个季度便宜。
合在一张表里
按同一个标准排一下：请求发出前能不能算出这一笔的价格，账单到手后能不能逐笔核对，以及谁能 看到算法。表中的消息数区间来自 OpenAI 定价页（经 Kingy 与 XenoSpectrum 转述）。
| 不可见性 | 出处 | 事先可算 | 事后可核 | 谁能看到算法 |
|---|---|---|---|---|
| 百分比条 | Codex 周额度 | 单笔 credits 可算，周额度总量未公开，算不出占比 | 无逐笔明细，用户自建 tracker | credits 换算表在文档页，不在账单 |
| 时钟 | DeepSeek 峰谷价 | 价目公开，前提是你记了请求的 UTC 小时 | 按 token 出账 | 官方价目页 |
| 像素 | Vision 图像折 token | 只有缩放规则与 384 上限，精确值需计算器 | 图与字合并进 input token，分不开 | 文档写明规则 |
| 同名不同价 | 第三方托管 | 价目公开，但版本标签不一致 | 各家按 token 出账 | 权重版本不在价目页 |
按 token 计价的三行，「事后可核」至少是 ✓ 或接近 ✓；订阅制那一行事后是 ✗。这不是说订阅制 不该存在——每月固定支出对很多人是优点——而是说它的账单天然少一层可核对性，出问题时用户和 厂商都拿不出对方认的数字。论坛里那 175 楼，本质上是在为一个缺失的明细页争论。
四条底线
不管你是买订阅还是直连 API，还是两者混着用，下面四条是我认为计量面该有的底线。每一条旁边写了 它的代价，因为没有代价的建议通常没人执行。
- 每次响应带 token 计数——输入、缓存命中、输出三项分开。代价：你得把它存下来，一个月几百万 行日志不算少。
- 价目在请求发出前可以查到——包括时段、缓存、模态的系数。代价：你的成本估算代码要多两个 字段，UTC 小时和图片尺寸。
- 账单可以逐笔导出——至少到请求粒度，能和你自己的日志对上。验法是用你日志里的 token 总数和 账单的 token 总数对，对不上的差值要能追到具体原因。代价：对账脚本要写，而且第一次跑通常会 发现你自己的日志也有洞。
- 版本可见——你调的模型名对应哪一组权重、哪个日期的版本，在价目页或响应里能看到。代价： 换 provider 之前多一步核对。
把我们自己放到同一把尺子下面：pirouter 的计量面设计为每次响应带三项 token 计数与按当前价目 换算的金额（第 1 条）；价目页设计为写明时段、缓存与模态系数（第 2 条）；用量明细设计为按请求 粒度可导出（第 3 条）；响应设计为返回实际承接的 provider 与模型版本（第 4 条）。四条都是设计 口径，不是上线承诺，哪条没做到，读者按这张表来问就行。
下个月账单到手之前
做一件事就够：从今天起，把每次请求的 token 三项（从响应的 usage 字段取）、UTC 小时、模型名与 版本、图片尺寸（如果有）落到你自己的日志里。一个月后账单来了，你手上有一份能和它对的东西。 对不上的那部分，就是本文标题里说的看不见的部分——到那时它至少有了一个具体的数字，而不是一根条。