Codex 只用 Sol、Astra 或 Luna：怎样推算每月 token 容量？
按笔者提供的周额度校准结果，保持近期高缓存任务，31 天等效情景约为 Sol 62 亿、Astra 10.6 亿 token。Luna 缺少单模型额度实测，只能给出 credit 权重下的理论换算，不能当作订阅承诺。
先给结论：Sol、Astra 有周估计，Luna 只有理论换算
以下全部包含缓存读取，以同一个账户、Standard 速度、近期任务结构和反复可用的完整周额度为前提。31÷7 只是等效周数，并不意味着供应商发放月度 token 配额。Luna 数字很大，但尚无证据证明账号能够实际用到。
| 模型 | 31 天等效中心值 | 可以怎样使用这个数字 |
|---|---|---|
| GPT-6.1 Sol | 62.0 亿 | 由作者周估计延伸；规划范围约 44—80 亿 |
| GPT-6 Astra | 10.6 亿 | 由作者周估计延伸；规划范围约 8.9—13.3 亿 |
| GPT-6 Luna | 860.1 亿 | 仅 credit 权重理论情景；实际月容量未知 |
| GPT-5.6 Luna | 420.0 亿 | 旧版本另列的理论情景；不能与 GPT-6 Luna 混写 |
- Sol、Astra 的规划范围沿用作者给出的宽周范围，不是统计置信区间。
- 没有单一模型从满额到耗尽的对照实测，也没有重算该周所有原始事件。
- 本次不重新核对账户档位、其他设备或额外购买；结果只属于作者描述的账户。
Sol 与 Astra：怎样从一周换算到一个月
用户提供的账户周窗口是伦敦时间 10 月 11 日 05:06 至 18 日 05:06，已使用约 90%；可匹配日志约含 Astra 2.03 亿、Sol 7,046 万 token 与少量审核用量。用户此前按官方 credit 权重分配混合消耗，再用 90% 校准，得到 Sol 约 14 亿/周、Astra 约 2.4 亿/周。本文沿用这一校准结果，不把两份模型用量各自除以 90%。
| 时间口径 | Sol 中心值 | Astra 中心值 |
|---|---|---|
| 4 个完整周（28 天） | 56.0 亿 | 9.6 亿 |
| 30 天等效 | 60.0 亿 | 10.3 亿 |
| 31 天等效 | 62.0 亿 | 10.6 亿 |
- 这不是“10 月 12 日起余下十月”的预测；真实剩余月份要计入当前剩余额度与重置时点。
- 每周都能使用完整额度、没有暂停、额度规则与任务结构稳定，才适合使用这样的月均换算。
- 约六倍是该样本的缓存与输出结构下的结果，不能推广成所有任务的固定倍数。
月等效 token = 完整一周估计 × 天数 ÷ 7
31 天 Sol：14 亿 × 31 ÷ 7 ≈ 62 亿
31 天 Astra：2.4 亿 × 31 ÷ 7 ≈ 10.6 亿为什么 Luna 的理论值会跳到数百亿？
当前 GPT-6 Luna 与日志中的 GPT-5.6 Luna 费率不同。下面使用官方 Standard credit 权重，并假设 Luna 处理每个总 token 的非缓存输入、缓存与输出比例，完全等于 12 日 11:32 的 Sol 截面；它还假设订阅内相对消耗遵循这些 credit 权重。这个假设尚未验证，官方也说明 credit 价格本身不能决定订阅内用量。
| 模型 | 非缓存输入 | 缓存读取 | 输出 |
|---|---|---|---|
| gpt-6.1-sol | 50 | 2.5 | 250 |
| gpt-6-astra | 250 | 25 | 1250 |
| gpt-6-luna | 2.5 | 0.25 | 12.5 |
| gpt-5.6-luna | 5 | 0.5 | 30 |
- Sol 当日总量 70,785,311，其中非缓存输入 2,952,003、缓存 67,569,664、输出 263,644。推理已包含在输出中，公式不再加一次。
- 相同结构下，Sol 加权消耗约 5.403 credits/百万总 token；GPT-6 Luna 约 0.389，理论比值约 13.9 倍。
- 这些大数字主要是高缓存上下文反复读取的账面容量，不是数百亿新生成内容，也不代表能完成同样多的功能。
- Luna 的能力、工具调用次数、失败重试和上下文结构可能不同；其他限制或实际工作速度也可能使理论容量无法达到。
上表单位：credits / 100 万 token
加权消耗 = 非缓存输入比例 × 输入权重
+ 缓存比例 × 缓存权重
+ 输出比例 × 输出权重
Luna 理论周量 = Sol 周估计 × Sol 加权消耗 ÷ Luna 加权消耗
再乘 31 ÷ 7 得到 31 天等效量这些数字怎样用于挑选和安排模型？
把 Sol 的约 62 亿/月与 Astra 的约 10.6 亿/月当作该账户、高缓存工作流的规划情景。不要把 Luna 的数百亿当成购买理由。更合理的分工是 Sol 主力实现、Astra 解决具体难点、Luna 接明确且容易检查的摘要、提取和机械改动，再比较实际验收与返工。
- 每天记录已验收产出、耗时、返工和额度中断；token 大不等于生产力高。
- 从 Standard 开始。Fast 按官方说明以 2.5 倍速度消耗套餐内额度，但任务形态和消耗仍会变化，不把月预测机械视为精确固定上限。
- Luna 应先做一个完整额度窗口的对照记录，再决定它是否能替代部分 Sol 工作。
- 模型排名判断质量，用量记录判断你的工作负载；这两类证据需要一起看。
什么情况需要重算？
新增上下文变多、输出更长、推理 effort 或速度改变、模型版本变化、其他设备参与、账户升级或额外购买，都可能改变结果。当前会话的 Standard 检查不能证明整个校准周都采用同一速度。两篇文章分别保留每日 11:32、月累计 11:35，以及用户提供的周额度校准，不将不同截面合成一个实测结果。