月亮从旷野上升起：一次对 Codex Luna Reserve 额度机制的实测

记录 Luna Reserve 使用前后重置时间的变化，分析七天窗口可能何时启动，并区分模型选择、实际执行与备用额度消耗。

Codex

2026 年 9 月 5 日，Codex 的常规 5 小时额度耗尽后，我第一次在客户端看到 Luna Reserve，显示剩余 100%。当天没有使用这份备用额度。等到常规额度恢复、重新可以使用高级模型后，我开始查询账号状态，想确认它的容量和重置周期。

查询结果中有一处异常：Reserve 始终显示已用 0%，重置时间却随着每次查询向后移动。直到次日实际使用后，这个时间才固定下来，用量也随后更新为非零。这组变化为判断七天窗口的启动方式提供了依据，也引出了另一个问题：客户端选择的模型、实际执行模型和消耗的额度，应该如何对应？

本文记录个人 ChatGPT Plus 账号在 2026 年 9 月 5—6 日的观测，并结合公开资料作出解释。发布前于 9 月 9 日重新核对了文中的官方说明与用户报告。涉及窗口长度与启动方式的判断，适用范围限于本次账号和观测时段。

备用额度如何记录

OpenAI 将 Luna Reserve 描述为一种备用机制（fallback）：部分个人 Plus / Pro 账号在常规 Codex / ChatGPT Work 额度耗尽后，可以继续使用 GPT-5.6 Luna。Reserve 有独立限额，开放情况取决于账号和支持的客户端版本。使用它不会恢复常规额度，也不会增加 API credits。Luna Reserve 官方说明

Luna 和 Luna Reserve 对应不同的信息。GPT-5.6 Luna 是执行推理的模型，Luna Reserve 则决定常规额度耗尽后能否继续使用它，以及相关请求从哪份额度中扣除。因此，看到 Luna 的使用记录，还需要结合额度状态才能判断是否用到了 Reserve。

本次账号状态查询同时返回了常规额度与 Reserve。下文保留查询结果中的字段名称，用于解释这份观测记录；这些字段不作为长期稳定的公开 API 约定。常规额度位于 codex 项下，包含 5 小时和七天两个窗口；Reserve 的 limitId 为 base_model_inference，limitName 为 gpt-reserve，单独记录用量与重置时间。

额度项目	窗口长度	接口中的位置
常规短期额度	5 小时	`codex.primary`
常规周额度	7 天	`codex.secondary`
Reserve 额度	7 天	`base_model_inference.primary`

Reserve 开始显示非零用量后，返回的字段如下：

{
  "limitId": "base_model_inference",
  "limitName": "gpt-reserve",
  "primary": {
    "usedPercent": 1,
    "windowDurationMins": 10080,
    "resetsAt": 1789311914
  }
}

usedPercent 表示已使用百分比，所以这里的 1% 对应界面上的剩余 99%。windowDurationMins 以分钟为单位，10080 分钟等于七天。resetsAt 是 Unix 秒时间戳，本例对应北京时间 2026 年 9 月 13 日 23:05:14。

进入备用状态时，接口还返回了 banner_type: "luna_reserve"，并提示当前正在使用 Luna。这一提示与独立额度项同时出现，为识别 Reserve 状态提供了依据。

不过，额度项本身可以在常规额度已经恢复时继续存在。本次最早的查询就发生在高级模型恢复可用之后，当时仍能读到 gpt-reserve。因此，接口中存在备用额度记录，只能说明账号返回了这份额度信息，不能单独证明眼前的请求正在消耗它。gpt-reserve 这一名称也不足以证明它是普通用户可以直接调用的公开模型 ID。

七天窗口从什么时候开始

9 月 5 日约 20:30，客户端首次显示 Reserve 入口。当天没有实际使用，之后的多次查询均显示已用 0%，但重置时间持续变化。以下时间均为北京时间。

查询时刻	Reserve 已用	返回的重置时间
9 月 5 日约 20:51	0%	9 月 12 日 20:50:59
9 月 5 日约 22:17:32	0%	9 月 12 日 22:17:32
9 月 5 日约 22:18:13	0%	9 月 12 日 22:18:13

后两次查询相隔约 41 秒，重置时间也后移了 41 秒。常规周额度的重置时间则保持不变，5 小时窗口只有约一秒的返回差异。Reserve 在这一阶段表现为：

T_{\mathrm{reset}}\approx T_{\mathrm{query}}+7\text{ 天}

这意味着，当时显示的日期还不能作为固定的周期截止时间。查询只能证明返回字段随时间变化，没有证据表明查询行为会延长实际额度周期。

9 月 6 日，我首次实际通过 Luna Reserve 发送消息。第一次读取时，接口已经返回备用状态提示，用量仍显示 0%；随后界面变成剩余 99%，接口对应更新为已用 1%。再往后的查询中，用量增加到 2%。

这些读取的重置时间均为 2026 年 9 月 13 日 23:05:14。将其减去七天，得到 9 月 6 日 23:05:14，与首次实际使用 Reserve 的时间相符。使用前不断移动的时间，在开始使用后保持固定。

一种与观测相符的解释是：账号先获得备用额度资格，计量窗口在首次使用附近才启动；尚未使用时，接口以“查询时刻加七天”计算重置时间。用 $t_0$ 表示推定的窗口起点， $W$ 表示七天，则可以写成：

T_{\mathrm{reset}}\approx \begin{cases} T_{\mathrm{query}}+W, & \text{首次使用之前}\\ t_0+W, & \text{窗口启动之后} \end{cases}

本次数据与“首次使用附近启动窗口”的解释一致。能够直接确认的是字段从动态时间变为固定时间，后台具体在哪个事件上建立窗口仍不清楚。请求接收、首次生成、请求完成和计量入账之间存在时间差，现有记录无法区分。下一个周期是否沿用相同规则，也需要继续观察。

首次使用后短暂显示 0%，同样不能用于判断是否已经消耗额度。整数百分比的显示粒度、统计更新延迟，以及查询发生在请求完成之前，都可能产生这种现象。此次观测不足以确定具体原因，也不能推导取整规则。固定后的重置时间减去七天，可以估计窗口起点；第一次看到 1% 的时刻则只说明统计已经更新到可见的非零值。

模型选择与额度来源

为了观察消耗速度，我随后让 Codex 执行了目录扫描、索引读取和 frontmatter 统计等只读任务。测试期间，客户端出现“模型已从自定义更改为 GPT-6 Astra”的提示，模型选择器也显示 Astra。

回查额度记录后发现，常规 5 小时额度已经从已用 100% 变为 0%，luna_reserve 提示也消失了。这与“常规额度恢复，客户端退出备用状态并重新显示 Astra”的解释一致。但由于没有逐请求执行记录，无法据此确认切换发生在哪条消息或哪次内部推理请求上。

模型选择、实际执行和上下文需要分别理解。客户端选择器表达准备请求的模型与推理档位；服务端执行记录才能说明某次请求最终由谁处理；上下文则包含该次推理读取的历史消息、指令和工具结果。同一个任务可以由不同模型接续完成，新模型仍然能够阅读旧回答。因此，助手根据上下文自述模型身份，不能替代请求记录。文中关于模型接续与历史上下文的区别，也可结合Codex Memories 的分层说明阅读；如果需要分开保留测试路线，可参考任务派生、Git 分支与 worktree 的区别。

官方文档说明了模型选择控件的用途，但所查页面没有明确交代当前桌面版本在任务运行中切换模型时，会在哪个内部请求边界生效。官方模型选择说明对需要控制额度的测试，可以先停止当前运行，确认模型选择，再发送下一轮消息，减少切换时机带来的歧义。

额度统计反映账号在各额度池中的累计状态。即使 Reserve 百分比增加，也可能包含较早请求的统计更新，或同账号其他任务的活动。模型选择器、备用状态提示和额度变化可以相互参照，但仅靠这些信息，仍无法完整还原每一条消息的执行与扣除情况。

我此前还在 Analytics 中看到过没有主动选择 Luna 时产生的使用记录。但缺少对应的产品入口、请求时间和执行信息，无法确认其来源，也无法判断是否消耗了 Reserve。官方帮助页将 Reserve 与普通 ChatGPT Chat 区分，因此不能把所有 Luna 记录都归入备用额度。

使用感受与观测边界

就这几次使用的体感而言，Reserve 消耗得不算慢。接口中的已用比例先后从 0% 增加到 1%、2%，但任务长度、统计更新时间和普通额度恢复都影响了这组记录的解释。因此，这里只保留个人感受，不把它换算成固定的消息容量或任务次数。

公开用户报告也提示了客户端差异。2026 年 8 月 26 日，已有用户记录同账号在 App 中显示 Luna Reserve，而 CLI 在常规额度耗尽后仍无法继续请求。Issue #40939 9 月 4 日的另一份调试报告同时记录了 gpt-reserve、base_model_inference 和 luna_reserve，并描述备用状态对模型选择器的影响。Issue #42830 这些报告可与本次观测对照，但其行为与报告时的环境有关，不能直接推广到所有版本。

如何继续观察

后续若再次使用 Reserve，可以记录新周期首次请求前后的重置时间，并保留切换附近的请求信息，检验窗口启动规律是否重复出现。精确触发事件、下一周期行为和绝对容量仍待验证。

查看额度时，可以先使用客户端提供的使用量入口。如果当前 Codex 环境提供账号额度查询能力，也可以直接问：“请查看当前账号的常规额度和 Luna Reserve，分别列出已用比例、窗口长度与北京时间的重置时间。”本次协作通过这种查询能力取得了数据，无需自己提取凭证或编写请求。具体能返回哪些额度项，仍以当前账号和客户端实际结果为准。

这也让我忍不住开个玩笑：随着 AI 和 Agent 软件不断更新，有些以前还没掌握的操作，等到想学时，软件已经替我做好了。原本要研究凭证和请求，现在问一句就能看到结果，某种意义上的“学得越慢，学得越快”。当然，省下的是操作步骤；数字代表什么、能支持什么判断，还是得自己弄明白。